Allow work to continue until deliverable is complete
Let team members continue working on their task list until a deliverable is complete. Ideally, every team member should be allowed to complete the deliverable that he or she is currently working on; this will go a long way to keeping the motivation up.
You'll have to exercise some judgment to balance the competing pressures of moving to another project and completing a recoverable unit of work on the current project. This is harder to do if you're in the "build" phase of your project lifecycle. You might choose to complete just one prototype, or one version of a specification in order to meet time pressures for the new project.
From my experience, unless the current work is completed to a first draft level, you end up redoing all the work when you restart the project later. It generally makes more sense to get deliverables as complete as reasonably possible before starting another project.
Complete deliverables in a lifecycle phase
Many organisations use a project lifecycle to manage projects. If at all possible, try to complete an entire phase. If you're working in the design phase, try to complete all the deliverables, such as specifications, and test plans that your methodology requires before starting something new. A completed lifecycle phase represents a logical breaking point that signifies a good transition point for the team, and a good place to resume work at a later date.
Bring formal closure
Best practices in project management include formally closing each phase of the project. Most organisations don't think about closure until the entire project is complete. When an organisation must defer a project, consider an early, but important, closure event. The time and effort spent closing a deferred project should be more than recovered when you resume the project at a later date.
Putting closure to projects
Whether for a new project or a deferred project, you need to take specific actions when deliverables are completed. First, capture lessons learned, document the experiences, and distribute the "lessons" to active project teams.
Second, archive those lessons learned and the full project work. All the work products, specifications, designs, meeting minutes, documents, and tools must be catalogued, documented, and archived in a manner that will permit easily resuming work at a later date. Then, approach the project closure activities:
- Ask customers to formally accept the deliverables that have been produced.
- Write employee performance reviews, if necessary.
- Update employee skill databases, if necessary.
- Formally review the project, if required.
Deferring a project the right way is a lot of work. It seems cheaper to just drop the project and move on. But when you factor in the risk of destroying the motivation of team members and the increased cost of cleaning up the mess later, a formal project closure and deferral process is worth the time and effort.
TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to fire walls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.
©2001 TechRepublic, Inc.
7%
3%
