Why charter a project within the framework of project management?

I have been looking forward to the beginning of this week, to make a series of posts on how project management actually happens in real life. At least an approach that is advocated for and well recognized in most organizations. Last week I spoke about small teams and the challenges they face and how to deal with those. This week’s focus is more on middle size and large companies where teams fit the two pizzas narration.

According to PMI, most companies work with projects without any formal practice in place to organize unification, consolidation, communication or understanding the components of the projects. these components normally include: business case, objectives, scope and boundaries, business impact, project team, and time frame for executing the project. These are normally overseen, in an attemp to quickly get the deliverables on the table and convince the stakeholders that the project is worth the time and budget. Without a project charter, it may however prove to be disastrous. Organizations, even small ones, need this document for project management to help describe the project(s) in their entirety. This means that the objectives are specified, how the project will be carried out, and who the stakeholders are. It is the map of the project, which guides you a good overview to know when you are off the track or are cruising in the right direction. Its’ cruciality in planning out the project roadmap throughout the project lifecycle, cannot be understated. Shortly said, the project charter adresses the following questions:

  • What must be done?
  • Why doing it?
  • What are the benefits of implementing the project?
  • When must it be done?
  • Who does what?

The project charter is developed as part of the project integration management and helps the project manager to understand the link between the project and the strategic objectives of the company. It is actually with this document that the project manager can proceed to use the company resources to execute the project. Most organizations however, do not have project charters. It is normal that a meeting is held without any formal documentation to follow up on the agreement made.While this works for very small teams, it becomes an issue as the company grows. It is not scalable and may not be feasible in the long run, as employees are bound to loose focus on who should receive and who should not receive mails. Another problem with this arrangement is that people are bound to delete their mails or teams can be changed. When a new team member joins, it will be difficult to keep them updated on the project’s status.

On the image shown on the left hand side is a sample project charter and how it can be kept simple but still ive enough details to the sponsor and the project manager. To create the project charter, PMBOK explains that the following input tools should be incorporated: business case and benefits management plan, Agreements, Enterprise environmental factors and organizational process assets. Agreements can be internal (within the organization) or external documents and are used to ensure proper delivery under the contract. If the IT department is to develop a new CRM system for the company, it will need developers, application architects, database managers, sales representatives and so on. The specification of the task when specified and detailed, then the project manager together with the project sponsor make a formal agreement/contract, identifying what they have agreed on. Later on when incorporated in the project charter, together with all the other relevant documents mentioned before, they should then be approved. This normally signal the initiation of the project. It is important to stress thouh that the project charter is not a contract on itself since there is no monetary exchange or consideration made in its creation.

When poorly drafted, with glaring ommissions, lack of the problematic metrics, absence of actual and target performance basis or failure to include the financial loss as a result of performance gap is a receipe for failure in realizing the business realization management. The project charter, besides the input mentioned before, should capture the imminent risks and scope of the project. A team member who is seen going on vacation, maternity leave, quitting or won’t be able to perform should be noted. At times project managers consider some team members’ contribution to be cosmetic, but realize too late that the project fails to live to it’s expectation when these members are not around. A risk assessment matrix should is probably one of the best tools when developing the project charter, to give a true picture of these imminent risks.

I have in my experience seen project charters or business cases where details were very coarse, that anyone who was not part of the team had a hard time understanding them. Taken to a higher level, the management is even bound to find it difficult to understand such documents. On the minimum, it is better to state the roles of the team members and the responsibilities that they will be shouldering. In bigger projects, the charters may include the WBS to make it more detailed and easier for mangement to understand.

In my next post, I will cover how a typical WBS is created, it’s purpose and who needs it.