These 10 tips come from a Baseline magazine article. But in the article, there were no substantial actions or expected outcomes. Starting with the 10 tips, here's how to put them to work.
Step 1 – Make it a Two-Stage Process. Start with an exploratory that examines whether or not the project is a good idea. This early stage should include a feasibility study and a hard look at the return on investment.
- Describing the project through the set of “capabilities” needed for business success is the 1st stage
- The 2nd stage is to build high level requirements, feasibility analysis and the business case around these capabilities
- By continuously focusing on the added capabilities, the temptation to dive into the technical details too soon – in the chartering phase – can be avoided.
- The role of the charter is to define the boundaries of the project in some unit of measure meaningful to all stakeholders
Step 2 – Identify the stakeholder. If the project passes muster during the first stage, it is time to get more people involved. This who conceived the project now need to identify the the key stakeholders.
- These include the project staff as well the representatives from all parties affected by the project
- Define these members through their roles and responsibilities (R&R) on the project
- Use a R&R matrix to form the RACI (Responsible, Accountable, Consulted, Informed) matrix – focus first on the Accountability
- Use the RACI in the Master Plan and Master Schedule to assign accountability for the deliverables
- The other relationships are interesting, but not all that useful once accountability is established
Step 3 – Brainstorm Capabilities, Not Requirements. This is the time to dream up all of those bells and whistle to be included, not five months into the project.
- Requirements gathered during the requirements session must first focus on the “Capabilities” of the project’s product or service, rather than features and functions
- It’s too soon to be defining technical and operational requirements at the chartering session
- Use a tool like Mindjet's Mindmanager to capture these capabilities in a hierarchical manner
- Build a list of capabilities through the paradigm below
With the integration of SAP and PeopleSoft we could make the improvements in the processing of accounts payable by closing 3 days after month end for all tier 1 accounts, using staff from the regional accounting centers in North America.
Step 4 - Come up with a Mission Statement - the process of drafting this statement for the charter will make team members and stakeholder clearly tie the project to the business objectives and the expected ROI.
- Define the mission in terms of observable changes in the outcome of the business processes
- What will be different in the business once this project is complete?
- Will we be able to measure the value of the sunk costs in units meaningful to the stakeholders?
- If so, can we call this the “mission?”
- Remember the “mission statement” describes how the project, product, or service will positively impact the future of the firm
For example
- The goal – produce visual media, events, and artwork that builds public understanding of climate change and energize commitment to solutions.
- The formal organization – construct a grassroots organization to distribute the media to schools and environmental organizations
- The operational structure – build local action committees to “pull” this media into community organizations to increase the awareness of local actions on the environment.
Step 5 - Put Boundaries on the Project's Scope - the mission statement will also guide the team to the next step, which is setting boundaries on the scope of the project.
- Define the mission in terms of observable changes in the outcome of the business process
- Connect these boundaries with the needed business capabilities first
- Only then define the top level technical requirements
- Avoid detailed technical requirements until the business capabilities and their measure of compliance have been understood
Ask the following questions first to define the boundaries of scope
- What does it mean to have a capability?
- How would we put this capability to work to earn its keep?
- If there is a new request, how does it add value to what we have defined as the project?
Step 6 – Set Change Control Processes – a project plan cannot be completely inflexible. The project charter should have a section on change control. The team needs to determine in advance what the process will be to initiate changes.
- Controlling changes for the sake of controlling change adds no value
- Determine if the requested change increases the value of the delivered product or service, if so incorporate the change
- If not, archive the change request in the change control system for later consideration
- Test each change request against strategy, economic value added, risk, and needed stakeholder capabilities
Step 7 - Milestone Based Measures - create milestones based on tangible measureables. Come up with measureables that show mission accomplishment. These measurements are the basis for setting project milestones (and checkpoints). The charter should articulate is a project proceed of milestones are not met.
- Better yet, create a deliverables based plan that predefines the business value or each deliverable
- Milestones are simply rocks on the side of the road you look at as you pass by
- Predefined value of deliverables provides an assessment of those deliverables at the point in time they were expected to be delivered
- This does not mean the project is done, just that the deliverables are increasing in their maturity as a function of time
- Never measure progress by the passage of time or the consumption of resources – only by Physical Percent Complete in units of measure meaningful to the decision makers.
Stage Gates and Milestones are interesting to external executives, but they do not measure the physical progress of the project. Only a some measure of physical percent complete does. This can only be done if it is defined before it is reached.
This is one of the fallacies of agile development when Story Points are used. As well, one of the fallacies of using stories and features in the absence of Measures of Effectiveness an Measures of Performance for each Story and Feature.
Step 8 – Set Risk Tolerances - risks not only need to be laid out, the level of tolerance for these risks has to be defined. The charter should give the PMs guidelines for when to pull the plug and cancel the project because the risk is too high.
- How long are you willing to wait to find out you are late, over budget, and off specification?
- Every point estimate in the project is actually a random variable
- Understand the probability distribution from which this random variable is drawn
- Use this information to model the inherent risk in the project’s cost and schedule
- The same is true for the technical performance parameters
And remember all risk comes from uncertainty and Uncertainty on projects come in two forms:
- Aleatory Uncertainty – which is a stochastic process that can only be handled with margin. Alea is a single Die used by the Greeks for gambling. Cost margin, schedule margin, technical margin.
- Epistemic Uncertainty – which is the lack of knowledge and can be handled by buying down the uncertainty with prototypes, redundancy, and other knowledge producing actions.
Step 9 - Set a clear statement of ownership – responsibility for the project needs to be on one person. This avoids project death by committee and prevents the age-old "I thought you were taking care of that" mentality.
- With the RACI diagram built in the previous step this comes for free
- Add the top level deliverables
- Add the measures of maturity at each assessment point in time
- The result is a Master Plan
- A Plan is a Strategy for the successful delivery of the outcomes of the project
- By connecting the people (accountabilities) with the increasing maturity (assessment of physical percent complete at a point in time) and risk adjusted forecasts of future performance – the stakeholder can answer the question of where are we?
Focus on accountability and all the other "...ilities" will follow
Have a Few Templates, But Only a Few – businesses should streamline the whole project initiation processes by developing project charter templates. This speed the process and ensures that new PMs include all necessary elements.
- Templates are a good starting point, but never the ending point
- Project success of the depends on factors not amenable to templates
- What does “done” look like
- How will we recognize “done” when it arrives
- How much longer and how much more money needs to be spent to get to “done”
- Don’t be fooled by the templates, they’re not the essence of project management
- Remember – the customer didn’t buy the templates, they bought the outcome of the project
- Use templates sparingly. Focus on outcomes. As they say in the aircraft business – the documents don’t fly.
Build templates showing how to define, measure, and assess
- Physical percent complete
- Testable requirements
- Measurable business value
- Agreements on the interfaces
- The coupling and cohesion of the system components
This is what adds value to the project and its deliverables
