How to Define a Project: Planning and completion
This series will cover the definition process for a project. Our last post focused on the definition document. This post takes a deeper dive into two scenarios.
Defining What “Done” Means
One of the keys to avoiding scope creep is to know exactly what completion entails. The definition process is the project manager’s first and most critical opportunity to limit the project scope. The key is clearly articulating completion criteria for the major project deliverables and for the overall project.
A solid completion statement will tie the deliverables and their acceptance together in a logical way.
A sample completion statement might look like the following:
The design task will be complete when the project manager provides the Design Report, as outlined in the deliverables guideline section, and it is accepted by the project sponsor according to the acceptance procedure in Appendix C.
Statements like this should appear in both the completion criteria section of the definition document and the approach section. This will ensure there are no doubts as to exactly what “done” means.
The most difficult part of writing a definition document is setting limits. You need to define up front what the project does include, as well as what it does not include.
For example, a project charter might say, “The goal of this project is to network all facilities in Maryland.” This would leave the project manager vulnerable to a response of, “While you’re at it, why don’t you include the facilities in Virginia?” On the other hand, a project charter that says, “The goal of this project is to network all facilities in Maryland. Facilities in Virginia will be networked in a separate project during the next fiscal year,” provides some defense when people ask for out-of-scope modifications.
Backing into Project End Dates
Project managers are often assigned to a project after the project finish date, budget, and resources have been defined. If an SME have a role in the initial definition of these important parameters, a work plan and schedule may not exist yet. The only way to achieve any degree of certainty in these figures is to lay out a schedule that demonstrates whether or not there is enough money, the right number and kind of people, and enough time to produce the deliverables.
Project managers affectionately call this process backing into the schedule. Most project managers would prefer to build the plan before they commit to any kind of project completion date. The painfulness of this process highlights the importance of involving the project manager early in the definition of a project.