Practice: Product, Project, and Team Review and Adaptive Action

Phase Close

A project close is both a phase and a practice. Organizations have a tendency to spend too much time initiating projects and too little time closing them. During a client engagement, I encountered the "failure to close" problem again. The customers of an IT project considered IT delivery to be less than stellar , partially because they thought the project had been underway for years. In reality, the application in question had been installed for several years , but the initial production and ongoing enhancement releases were not differentiated from each other. So from the client's perspective, the "project" just went on and on.

Since resources are always scarce , people are moved on to the next project quickly, often without taking time to close up the last project and get credit for its completion. There are several activities involved in closing a project, most of which don't take much time but do pay off. First and foremost is a celebration. A celebration serves two primary purposes. One, it shows an appreciation for all those who worked hard on the project. Including key clients in the celebration helps declare that this project is over, done, finalized, thus providing a sense of closure. Projects that go on and on without closure (or a series of projects couched as one) are terrible for morale .

Another less-glamorous closing activity is to clean up open items, finalize documentation and production or manufacturing support material (I know, it should have been done by now, but we know what happens in reality), and prepare required end-of-project administrative and financial reports . [7]

[7] Mike Cohn recommends another activity for software projects that may also be valuable to hardware developers: "One other thing I traditionally do when closing a project is to make sure we archive the development environment. I've seen too many projects where people thought they were covered because they had the code in a configuration management system. But the system was buildable only from inside something like Visual C++, or it required specific versions of software files to build. I always burn CDs of all that stuff at the end."

A final closing activity is conducting a project retrospective. Teams using APM have done mini-retrospectives each iteration. These minis help the project team learn about its own processes and team dynamics as the project progresses and as such are intra -team learning activities. The retrospective at the end is for inter -team learning, for one project team to pass along to others in the organization what went well and what went bump in the night. As referenced earlier, the best source on conducting retrospectives is Norm Kerth's (2001) book Project Retrospectives: A Handbook for Team Reviews .

Companies often confuse products and projects. Products are ongoing, while projects have a finite lifespan (at least the good ones do!). Differentiating between projects and productsending projects and getting recognition and closureis an important but often overlooked aspect of good project management, agile or otherwise .