Do we have enough time to prepare a project charter?

Working on multiple projects, initiatives and assignments usually takes a lot of time, and the switching costs of multitasking could be huge. In a fast changing environment, a lot of projects are coming in and out, sprint scopes are changing, and reprioritization has become an almost a daily routine. 

In this turbulent business environment, internal stakeholders are urged to accommodate the requirements of existing clients, as well as to attract new clients with new/existing products or features. In the spirit of competitiveness, organizations are aiming to shorten the “Time-to-market” as much as possible. To react appropriately and timely, delivery and development teams need to be agile and more flexible. In other words, the team needs to have a lightweight plan that could be easily updated, that could assist them in the organization and coordination of work that needs to be done. Also, this lightweight plan should keep the team focused on the scope of the project, and on the problem they are trying to solve.

“Plans are nothing, planning is everything.” - Dwight D. Eisenhower (1890-1969)

Describing the project using the project charter

A project charter is usually a short and formal document that is used for describing a project in a comprehensive way. It includes the scope of the project, problem(s) that need to be solved, objectives, limitations and statements about what will not be included, explanation how the project will be carried out, stakeholders, milestones, risks, budget, etc. There are many templates and formats of the project charter that are available online and that could be used. What is important to stress out is that project charter represents a crucial ingredient in project planning, and considering the elements that are included in it, project charter should be used on a regular basis throughout the project lifecycle. As nicely said in one of the papers from the PMI conference (Brown, 2005), the project charter is a project's best marketing tool which is created at the very start of the project, when the selling of the project's goals and ideas needs to begin.

“Develop Project Charter is the process of developing a document that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.” - The PMBOK® Guide, 6thEdition 

Project charter should be a simple and straightforward document. It could be short, but it must contain certain key elements. As per the PMBOK® Guide, those key elements should be provided either directly or by reference and are: (1) Requirements, (2) Business needs, (3) Summary schedule, (4) Assumptions and constraints, and (5) A business case, including return on investment. A lot of information and data, recorded and collected during the pre-initiation phase of the project (or research phase), could be used for drafting a project charter.

A project charter should be the document that is accepted amongst stakeholders, and for which a consensus has been made around what needs to be done, definition of success, and why the project is being undertaken. If reaching the consensus fails, it is more likely that the project will not succeed and the resources will be wasted. Another action that could improve the odds of project success could be the project’s alignment towards its charter. The project charter should not be something that has been created, went through approval/formalization process and never seen again. Instead, it should be regularly accessed and referenced by project team members. By doing this, the team is actually ensuring that their efforts on the project are aligned to the project objectives.

Changes are a normal part of life. Most of us are familiar with the famous quote from Heraclitus: “The Only Constant in Life Is Change”. Or the one from Benjamin Franklin: “When you are finished changing, you are finished”. Like all things in our life, this is also true for projects, especially because projects adhere to the law of entropy and tend towards chaos. People who are managing projects (e.g. project managers) have seen budget cuts, team members fluctuation, changes in customer needs, shifts in market dynamics, and other factors that are occurring at some stages of the project lifecycle.

Project managers experienced many situations in which they found out in the mid-project phase that scope of the project has changed and/or the reason why the project was undertaken has been changed. Response to that would be to gather the stakeholders back together, review and update the project charter to reflect these changes. If this is not done, the project will go in one direction, and the charter will remain the same, representing some initial scope and objectives that the team is not chasing anymore due to the changes in market/customer circumstances. 

When is a good time to create a project charter?

From the agility point of view and when it comes to the time-to-market metric, it shouldn’t be of a crucial importance who will be creating a project charter. It could be either created by the project initiator, sponsor, or a project manager following a delegation from them. The time spent on creating this document and “making it official” will still be the same, or quite similar. More concerning question should be when the charter is supposed to be created. 

As per definitions, project charter should be created in the project initiation phase. Although it is indicating that this is the beginning of a work on the project, there are definitely some significant efforts that are invested in the research and discovery, which is representing the pre-initiation phase. From that point of view, it could be more beneficial, and could save a significant amount of time, if the project charter is started to be drafted at the end of the research and discovery phase. That way, when the project reaches out the initiation and planning phase, the project manager will already have something in front of him that could be used, shaped and updated into the project charter. Also, the consensus and approval process (if the organization has that in place) would be easier, since some of the stakeholders participated in the research and discovery phase. 

Looking towards agility

Looking back to the definition and purpose of a project charter, as well as the market characteristics and the urging need of organization to respond to change quickly and be agile, there are few questions that are arising: 

1. How much time do we need to prepare a project charter if we want to take action promptly, and initiate the project on time? (in addition: Do we have that time?)
2. Do we have time to spare for going through the approval process?
3. Will some of the elements of the project charter change along the way of project execution?
4. Are we sure that we can get appropriate and right information to prepare a project charter that will reflect the true elements of the project that we are going to undertake?

In most of the situations, there is not enough time, and the answer to these questions is usually, NO. Observing through the example of software development, Project Manager will spend some time drafting a project charter, probably consulting with some other roles such as Product Manager, Product Owner, or other Project Managers who undergo similar projects. And maybe that one week that has been spent drafting a charter is not so important in that initial phase, since the whole project is yet to start and there are several months in front of the project team to work on the scope. And maybe the approval process will take a few more days, and one will say: “Ok. That's it, we have spent 2 weeks on these formalities, and now the work could start.”. But, what will happen when in two months, scope of the project has been changed slightly to reflect the (changing) needs of clients? Will the Project Manager spend one more day updating the charter, and one more day for the approval, which is the best case scenario? And this could happen several times during the project delivery phase. 

Project charter is the document that reflects the scope of the project. As project tasks are updated on a regular basis to reflect the latest status, the project charter should also be aligned with the latest scope changes. If this is not done, then why bother to create a charter in the first place. One of the solutions for having a project charter that is aligned with the latest requirements of stakeholders, and that will not require too much time to be spent on creating and keeping it aligned, is the lightweight project charter.    

Lightweight project charter 

Next are the guidelines for preparing a lightweight project charter: 

• Why are we doing this?

Start with clarifying why the issue/problem/situation occurred. 

• What are we aiming to achieve?

Define the scope of the work for the issue/problem/scenario. 

• How are we going to do this?

Define what will be included in the delivery of the solution.

• Who will be affected

Identify people, departments or teams that are affected by the problem, and who will be using/benefit from the solution that is aimed to be delivered. 

• When - Initial timeline and phases

Understanding the timeline could help in preparing a delivery through phases. 

• Who is the project sponsor?

Who will be giving the final approval for the project, and who will provide resources and the budget.

• Project reporting

Who will be receiving a report about the progress of a project? What will be the reporting frequency?

• Project team

Which roles are required for the delivery. In case of a software development project, it could be: 1 Backend, 1 QC, 0.5 DevOps. 

• Technologies to be used and related details

If the project is related to the software development, it could be useful to include as a separate section a high level information about the delivery (e.g. which frameworks will be used, which environments)   

• Other requirements

If necessary to provide more details to the project sponsor who is doing the final approval, or for the team, high level additional requirements could be added as a separate final section in this lightweight project charter.

Conclusion

1. To react appropriately and timely on the requirements from the stakeholders, delivery and development teams need to be agile and more flexible. The team needs to have a lightweight plan that could be easily updated, and that could assist them in the organization and coordination of work that needs to be done. 
2. Having a well written project charter will not guarantee project success, but having a well written charter and having constant project’s alignment to its charter does improve the odds for project success. 
3. If project scope, objectives or the reason why the project is undertaken has been changed, gather the stakeholders back together, review and update the project charter to reflect these changes.

References

• Brown, A. S. (2005). The charter: selling your project. Paper presented at PMI® Global Congress 2005—North America, Toronto, Ontario, Canada. Newtown Square, PA: Project Management Institute.
• Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute.