Rethinking the Charter
Categories:
Tools,
Portfolio Management,
Project Failure,
Risk Management,
Agile,
Human Resources,
Nontraditional Project Management,
Calculating Project Value,
Reflections on the PM Life,
Documentation,
Project Planning,
Facilitation,
PM Think About It,
Project Delivery,
Project Requirements,
Translations,
Roundtable,
Strategy,
Metrics,
Stakeholder,
Innovation,
Change Management,
Leadership,
Lessons Learned,
Program Management,
Scheduling,
Benefits Realization,
Complexity,
Education,
Programs (PMO),
Communication
Categories: Tools, Portfolio Management, Project Failure, Risk Management, Agile, Human Resources, Nontraditional Project Management, Calculating Project Value, Reflections on the PM Life, Documentation, Project Planning, Facilitation, PM Think About It, Project Delivery, Project Requirements, Translations, Roundtable, Strategy, Metrics, Stakeholder, Innovation, Change Management, Leadership, Lessons Learned, Program Management, Scheduling, Benefits Realization, Complexity, Education, Programs (PMO), Communication
| Since I retired after 26 years in one company, I have had assignments in various PMOs in different industries. I’ve been in the energy sector, the insurance sector, credit card services, industrial/manufacturing, and now healthcare. Every industry has struggled with the project charter. What does baselining it mean? Does it ever get updated? Who should issue it? And the list goes on. And while PMOs in all these industries try to invent the perfect process – we are ignoring one important aspect. The project charter, as defined by PMI, does not meet the needs of today’s business! Before you call me a heretic and an incompetent – hear me out. The problem I have with the charter is it becomes a reformatting of existing information, bloated, and redundant – and it doesn’t provide the project team with the most important information it needs. Shouldn’t the charter give the team a definition of what success looks like? I propose the charter should be extremely streamlined. After all, how many people, let along executives, will read a 14 page charter? Many charter templates contain information that is already in one artifact and will no doubt be included in another. I propose we throw away the bloated all-inclusive charter of today and replace it with a simple charter. Project Organizational WrapperYou need to have the organizational wrapper of project control structures. If the project pipeline has a defined Demand Process and there is a demand id, it should be in the charter. This should also be aligned to the business case information – what went into the approval, and other justifications. No need to repeat them in the charter – they already exist in a corporate database of record. If information is in two places – that doubles the risk of inconsistency, confusion, and delay. If you have an integrated project management system (IPMS) that tracks project work in process – then that project id should be there. Projects assume titles and identify from the ideation phase through project initiation. That title, or name, should be included in the charter because that’s the lingo that has defined the initiative. Should be results focusedOnce the project is ready to kick off, the work initiative needs to be focused on the results. If your organization is mature enough to be doing Benefits Management Realization, the charter should map directly to the benefit register. The next section of the charter should be: What does success look like?Quite simply – what is the vision in reality? Knowing what success is far outweighs the value of several scope bullet points. The definition of success can be expressed in several ways including: Critical success factors The essential areas of activity that must be performed well if you are to achieve the mission, objectives or goals for your business or project. What can we do in the future that we can’t do now? How do we measure success? Not calling for specific key performance indicators here, but should have an idea of how we will measure success. It also provides requirements for the product and what are the critical success factors. External/legal requirements If you are driven by a legal requirement or an industry standard (HIPPA or an ISO requirement comes to mind) than that should be identified. The charter must identify conformation to external factors. What benefits are being realized?Again, if you have a mature benefits realization process, then the entire benefits quantification/qualification should be in place and your project is delivering outcomes and capabilities to realize the defined benefits. Organizational RACIThe charter must be able to identify all the organizations that are impacted by the initiative. After all, how did you get high level estimates for the business case if you didn’t have a means of identifying organizations involved? This RACI should then be driven to know which groups need to receive and approve the charter. Time FrameWhat time frame is expected for the organization to start to realize benefits? Let’s avoid the charade of bottom up estimates and defining the schedule after you have all requirements defined etc. We are driven by budget cycles and funding is only approved to last so long. This isn’t to say those things can’t and shouldn’t happen, but at a Charter level – the approval has a defined end time. This also helps define the scope. I have purposely omitted several pieces of what is considered part of a charter. Not that I don’t think they are important, I do, but they belong in defined sections of the project plan. There is no need for budget as that should already be in the business case approval – and I don’t know if it directly contributes to the definition of the outcomes and capabilities. Scope is implied in what success looks like and the Critical Success Factors. If during requirements definition, a question is raised that doesn’t directly support the definition of success, than it is out of scope. Assumptions, risks, issues, and constraints are all important, but they live elsewhere. The charter should identify the future state, not dwell on the challenges of the present state. And the charter should be a onetime document that is not modified or have addendums. It initiates the work – other artifacts ebb and flow during the project life cycle.
In closing – the purpose of the charter is to authorize the project manager to start delivering on the project. It is not to cut and paste from all over to make an all-inclusive summary of all business intelligence that justified the project. I propose to make it a lean document focused on the outcomes and capabilities and the definition of success. Items that have a workflow/life cycle (risks, assumptions, issues, etc.) do not need to be in a charter, they are taken care of elsewhere. A lean, concise, and easy to read charter allows the team to focus on delivering within the success criteria.
Please sign up for a 1:1 with me while at the PMI Global Conference! We can talk about PMOs, healthcare project management, teaching project management, or any other topic related to project management! To schedule a 1:1, use the SIGN UP button on this page. |
What you don't like about someone is what you like about them.
| Tips for managing a cross-functional team
This sounds very self-conflicted. But it’s not. I’ve found that with a project team of highly skilled people, there’s at least a few people that will *really* bug you. They’ll get under your skin and annoy you in team meetings. The project manager’s first instinct is to “deal around” them. In other words, don’t get them involved important aspects of the project. Leave them out, don’t ask them questions, don’t get their opinions. You’re hoping that maybe they’ll get the message and leave the rest of you alone. This is absolutely the wrong thing to do. You need the pests, you want the pests, the pests are your BEST friends! LOVE THE PESTS! Don’t get annoyed, simply smile and say “thank you!) When these people annoy you and the project team, they’re showing a unique quality that will, most likely, be very useful to everyone. The best way I can think to explain what I mean is by picking a few personalities that stick in my mind. These are my recollections of real people, and there’s a chance they’ll recognize my description of them. That’s OK. They know we’re all friends that worked long and hard together. Here are some of the best and most frustrating team mates I’ve ever worked with ANNOYING TEAM MEMBERS Always Wanting More Detail I must say this is typically considered an engineering oddity. I have it myself. Some of the best engineers are NEVER EVER satisfied with the information they have. This behavior isn’t just restricted to engineers though. But, when I’m typing this, I’m thinking of our reliability / maintainability person. He never had enough detail to calculate reliability numbers or to insure we met our maintainability goals.
Whiner / Complainer These folks will complain about every step in the project, every deviation, every change, everything that’s not what they think it should be. These folks are the first choice to work-around, do without or leave out of any project decision. That would be a big mistake. Here’s a few test cases:
Negotiator These folks want to negotiate every detail in the project. “Can’t we do it differently – everyone does it this way?” “Let’s get the two teams together and work out a solution.” This is *after* it’s all be decided.
THE LIST GOES ON AND ON… We all have a list like this of different personality types we’ve worked with on teams. The key is when the annoy you and everyone on the team -- remember this when you DON’T like them. But sooner or later, this person will help the project a great deal. Embrace the jerks on your projects – they may be your best friends! Please comment with a list of your favorite project jerks! And remember that's what you like them for. MEET ME IN SAN DIEGO NEAR THE PROJECTMANAGEMENT.COM BOOTH. MAKE AN ONLINE / EARLY RESERVATION TO TALK TO ONE OF OUR EXPERTS HERE! |
