As a project manager, have you ever been assigned to a project that is destined to fail before it begins? Your boss looks across the table and says “John, you are going to lead the XYZ Development Project. It looks like we are targeting a ‘go-live’ by summer. I am pretty sure Jane is the business representative and she should be getting you a charter document in the next few days.” In turn, you say “Great! Who is the Exec Sponsor? Will this be an enhancement to the current XYZ System or new implantation? Are we launching in the continental US then going global?” And then the dreaded…”Not sure John. Get with Jane and knock out the details and let me know how I can support the effort.” You shake your head and in hopes that your boss is just overwhelmed, you call Jane to get some details. “Hey Jane! This is John and I will be working with you on the XYZ Dev Project. I wanted to get a better understanding of the project, can you shoot me over the business case and charter if you have it?” Jane tells you “we haven’t done the business case yet and are finalizing a charter/requirements document but competitor X is very successful at this and we need to get something to market fast.”
If this resembles your situation, don’t be too discouraged. This can actually be a positive thing for a Project Manager. If you are in a smaller, growing organization you have the opportunity to bring value by introducing a project management framework into the organization. If you are in a mature, projectized organization you have the opportunity to set the tone and expectations as the leader of the project (professionally) by reiterating the value of project processes and artifacts. In either situation, this is the make it or break point in the project! Too many people will focus on the later stages of the project…durations were estimated incorrectly, scope creep changed the schedule, or costs got out of control. While many organizations do not have Portfolio Planning Management, even those that do often leave the Project Manager out of the loop. Not until the executives have said ‘go for it’ is a project manager assigned to the project and the clock starts ticking.
I don’t think a sole Project Manager will get an organization to adopt Portfolio Management (in the short-term), but He/She can insist on a comprehensive Project Charter Document. This often means that a Project Manager needs to ‘interview’ the requester/customer in order to create the Charter. From there, He/She can then obtain the appropriate reviews and sign-offs to gain the ‘security’ so important to the project going forward. The Charter is what gives the Project Manager authority to leverage resources to develop a product or service that meets the needs of the Stakeholders. This is the ‘insurance policy’ for a project manager to ensure the project aligns with business goals, stakeholders agree to the deliverables, how success is measured, limitations & assumptions, etc. Before a Project Manager goes off with His/Her team, they need to ensure they have a Project Charter approved and signed-off by the Project Sponsor and other stakeholders. I have reviewed templates/guidelines from over a dozen sources…PMBOK, Method 1-2-3, CDC, State of Texas Info Resources, Princeton University, Project Management Hut, Gantthead.com and many more. The following are common elements shared by most, if not all, of the resources and should be in every Project Charter:
* One Key point to remember, is that no level of project documentation can save a project that does not have executive support. So make sure you building that relationship and keeping your sponsor engaged.
- Problem Statement – Provide the business reason(s) for initiating the project, specifically stating the business problem.
- Project Description – Describe the approach the project will use to address the business problem.
- Organizational Alignment – Describe how this project aligns with other initiatives in the organization. Is this a top priority? What other initiatives will be effect if this is not done?
- Project Goals & Objectives – Describe the business goals and objectives of the project. Refine the goals and objectives stated in the Business Case.
- Project Scope – Describe the project scope. The scope defines project limits and identifies the products and/or services delivered by the project.
- Project Includes –
- Project Excludes –
- Critical Success Factors – Describe the factors or characteristics that are deemed critical to the success of a project, such that, in their absence the project will fail. These should be measurable…X% increase in CSAT, or $Xmil dollars saved, etc.
- Assumptions – Describe any project assumptions related to business, technology, resources, scope, expectations, or schedules
- Constraints – Describe any project constraints being imposed in areas such as schedule, budget, resources, legal, technology/vendor that must be leveraged, etc.
This section provides a full listing of benefits, costs, and feasibility. Multiple options can be (should be) included to illustrate doing nothing, doing a scaled-down version or doing the full project scope. Try to minimize the number of options available by conducting a detailed Feasibility Study beforehand. For each solution option identified, the following information should be included:
- Benefits – Describe the tangible and intangible benefits to the company upon implementation of the solution.
- Costs – The costs of the actual project should be included (e.g. equipment procured) as well as any negative impact to the business resulting from the delivery of the project (e.g. operational down-time).
- Feasibility – Describe the feasibility of the solution. To adequately complete this section, a Feasibility Study may need to be initiated to quantify the likelihood of achieving the desired project result.
- SWOT Analysis to illustrate the current situation the organization is in and how the project plays to certain strengths or fills a gap.
- Strengths – Experience, Geography, Innovation, Qualifications, Price, Value, Quality, etc
- Weaknesses – Deadline, Systems, Capital, Reliability of Data, etc
- Opportunity – Competitor Vulnerability, Industry Shift, Niche Market, etc
- Threats – Legislative, Market Demand, Loss of Key Staff, etc
Project Milestones & Authority
- Project Authority – Describe management control over the project. (i.e. – project management office)
- Funding Authority – Identify the funding amount and source of authorization and method of finance (i.e., capital budget, rider authority, appropriated receipts) approved for the project
- Major Project Milestones – Include a basic table with Milestone/Deliverable, Target Date for completion, and Must Have (y/n).
- Project Structure – Specify the organizational structure of the project team and stakeholders by providing a graphical depiction of the project team (Org Chart), up to governing resources or project sponsor.
- Roles & Responsibilities – Summarize roles and responsibilities for the project team and stakeholders identified in the project structure above. This can be a descriptive/text table or even an RACI/ARCI Matrix.
- Project Facilities & Resources – Describe the project’s requirements for facilities and resources, such as office space, or computer equipment.
Points of Contact – Identify and provide contact information for the primary and secondary contacts for the project. (i.e. – The PM and a Backup/Escalation)
Glossary – Define all terms and acronyms required to interpret the Project Charter properly.
Appendices – Include any additional documents for further reference or explanation.
Revision History – Create a table columns for Version, Date, Name, Description
As I step through the next posts, they won’t all be about templates. You can find great templates at the resources I mentioned above. Until next time, have a great week!