If you are looking for a fun ice-breaker at your next project management networking event, ask delegates the question “How do you know when a project is completed?”. Most will likely start responding with the tried and true answer to all questions – “It depends”. Keep digging, and you will likely be rewarded with an amusing tale or two of projects that wouldn’t die.
Recognizing that there can be challenges with closing projects, especially when there is an expectation gap between the customer and the project team, are there any universally applicable criteria for closing a project?
Let’s consider the following two plausible exit conditions.
- When the money runs out. One would think that a lack of funding would force work to cease. However, with the exception of agile projects with a fixed funding constraint, or a true time & materials contract, just because the money has run out doesn’t mean project work ends. All large consulting firms can point to at least one case study of a project on which they continued to work long past the time when the customer had stopped being invoiced.
- When scope has been delivered. Completion of deliverables is not the same as acceptance of deliverable. I’m sure we’ve all survived projects on which all deliverables were handed over but work continued because of some lingering requirements or quality gaps.
I’ve found the following two conditions to be reliable when managing external projects.
- All project closure terms have been met. Of course, this does require due diligence early in the life of the project to nail down those terms & conditions to a sufficient level of detail and to get the customer’s and your organization’s acceptance of those.
- You have been formally notified by either your customer or the “right” decision-maker within your organization to stop work. Of course, if the first condition hasn’t been met, you may have to exercise early termination terms in the contract.
But what happens in the case of internal projects where the roles of customer and delivery team are within the same organization?
You could institute formal terms & conditions just as you would for an external project. However if there is dissent over a project’s completion, enforcing those terms could escalate into a case of “cutting off your nose to spite your face” as the inter-departmental conflicts could generate conflict and operational impacts that last well beyond the life of that one project.
So what have YOU found works consistently for internal projects?