Posted on June 25, 2013 by Grace Okwumabua
In project management, there’s no such thing as perfect. No project goes entirely as planned, stays right on schedule, delivers a flawless product the first time through, meets everyone’s expectations, or costs exactly what was allocated. Even comprehensively planned and tightly controlled projects tend to experience unexpected detours. However, there does need to be a point when a project is closed out. Having too many open ended projects can lead to a number of problems within an organization, such as:
Do you know when it’s time to wrap up a project? Is it when every task has been marked off the checklist? Is it when all customer goals have been achieved, or just the majority of them? Is it when an end product is completely free of flaws or bugs? Is it when the money runs out? When time runs out? Is it when stakeholder groups start expressing interest in moving on to the next project? Let’s take a look at how to determine when to wrap things up depending on the approach used.
The End of the Waterfall Is Pretty Clear. With a well-designed waterfall project, the minimum requirements for calling a project complete should be stipulated during the concept/design stage. This creates a distinct end point so that the project doesn’t simply drag on endlessly. Depending on the industry, this may be the point at which a project shifts into the operations and maintenance (O&M) phase or when it is deployed in a workable format and is subsequently handled by the O&M team. The end of the project comes at one of three times depending on the circumstances:
Agile Boundaries Remain Fuzzy. An Agile project is, by its very nature, going to morph over time. This is considered a benefit and not a problem when using this methodology. However, Agile’s constant transitions can make it difficult to tell when the project is truly finished. The oft-quoted rule of a project being over once funding runs out; is not a true limit since it is sometimes possible to seek a new round of funding. That doesn’t mean continuously seek funding as long as there are outstanding tasks to be done on a project. Instead, requests for additional funds should be restricted to cases where:
It’s also not necessary to use up all available funding for a project just because it’s in the budget. In some cases, it’s best to stop while you’re ahead and leverage that success to help jumpstart the next project.
What if there isn’t a clear end point and the success level of the project is somewhere near the middle of the road? This is when you may need to negotiate with stakeholder groups to find a way to draw things to a close gracefully and without undue dissension. For example, giving QA additional manpower in lieu of extra time to do product testing and review might alleviate their fears about deployment. The end customer’s opinion is, of course, the most important factor in closing out a project. They may be the ones who are eager to close the project because they feel the results are good enough or they may want the project team to keep working because they are not yet satisfied.
Either way, it is important to clarify the customer’s true goals. These may have changed over time since the beginning of the project. Use this new goal set to create several scenarios with timelines, budget requirements, and outcomes for results that are:
This way, the customer feels that they still have control and they can choose the scenario that works best for them. This guidance is paramount to defining victory in project management!
Grace Okwumabua
Mythics Consulting
Comments