Projects, by definition, have a beginning and an end.
A project starts with an idea. Maybe it’s a step in a strategic plan. Maybe it’s an improvement or enhancement to a system. Perhaps it’s a new building. Or a new line of business.
And once that idea has been brought to reality, the project ends.
Now, that “end” can take varying forms – including a handover of the keys and a set of instructions and operational activities – but the project itself is over at that point.
How do we know what “done” looks like? To know this, we go back to the beginning, to that idea brought forth by a sponsor or executive sponsor.
That idea is the seed for discussions. These discussions, which take place in the Initiate phase of the project lifecycle (qv), culminate in a contract between the project sponsor and the project team. This contract is referred to as the Project Charter.
The Project Charter encapsulates the expectations of the sponsor, and makes the project team accountable for delivering to these expectations. The Charter includes:
- Project Description – As the name suggests – a brief narrative describing the project. This needs to be in sufficient detail that the Project Sponsor (and Executive Sponsor) can look at a glance and say, “Yep.” More detail will follow.
- The Project Scope – the parameters of what is to be delivered and included once the project is complete. This should be detailed and as complete as possible, and is the product of numerous conversations, design sessions, and requirements gathering exercises.
It’s important to mention that, as important as it is to specify what is included in the project, it’s also important to spell out what is NOT included. For example, if the project is to implement a new ERP system, the modules to be implemented need to be listed. As well, if the company doesn’t want to include the Sales Management module at this time, then it needs to be explicitly excluded from the scope.
The features called out in the Scope portion of the Charter should be granular enough that, at the end, each one can be checked off as having been delivered (and tested). - The Project Budget – The enumeration of the amount of money that is to be spent implementing the project. This should include as many of the anticipated costs as possible, and they should be as accurate as possible as well.
Early in the project lifecycle, the budget tends to be “mushy” (that’s a very technical term). It’s difficult to nail down exact costs, especially for longer-term projects, where inflation needs to play a role, and personnel costs can be particularly vague. So it is common for the project manager and team to add a contingency to the budget. This can start as high as 20% of the total expected spend – but should be lowered as more information about costs becomes available. - The Project Timeline – There is usually a deadline proposed by the sponsor of the project. But that’s not the end of the story.
Once the initial scope is determined, the PM needs to work with the project team to get a rough understanding of how long the work might actually take. Now, if that estimate and the deadline coincide, that’s great! However, that is often not what happens. In that case, it will be necessary to go back to the sponsor and negotiate the scope, the budget, and the timeline until they line up to everyone’s satisfaction. Might not be perfect, especially initially – but that’s what contingencies are for. - Risks, Assumptions, Constraints, and Dependencies – Some time should be spent determining these additional items and including them in the Project Charter. These will be fleshed out further in the Plan phase, but if they are known in the beginning, they should be captured and explicated. Briefly:
- Assumptions are those things that we believe will be true during the project. For example, we assume that we will have access to the Sponsor to answer questions; we assume that we will have resources allocated to execute the project, etc.
- Constraints are those things we know will be challenges during the project. For example, everyone on the project must have a secret clearance, or building access for our team will be limited to 8 am to 5 pm, or we cannot work remotely on the project, etc.
- (I’ve written about Risk Management rather extensively here.)
- Key Personnel – This includes the names of the sponsor and the executive sponsor, the PM, and other key people (strategic planning, finance, etc.)
When all of this has been gathered – and this is not a one-meeting-and-done thing – the document is assembled, approved, and accepted by the sponsor and the executive sponsor. At this point, the Initiate phase is complete, and we move onto planning.
Once we get past Initiate, we don’t simply set aside the Charter – it is the basis for the planning process, and deviations from the Charter need to go through the Change Management process.
The Project Charter is an important document, but like many documents, the best part is the process of creating it. The meetings and interactions are golden – both from the content that gets pulled in, and from the relationships that get created. Don’t skimp on developing the Charter!