10 Steps to Charting Project Success

These ten tips come from a?Baseline magazine article. However, the article needs to include substantial actions or expected outcomes. Here's how to implement the 10 tips.

Step 1 – Make it a Two-Stage Process. Start with an exploratory examination of whether 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 charter's role is to define the project's boundaries in a meaningful unit of measure for all stakeholders.

Step 2—Identify the stakeholders.?If the project passes muster during the first stage, it is time to involve more people. The person who conceived the project now needs to identify the key stakeholders.

• These include the project staff and representatives from all parties affected by the project.
• Define these members through their roles and responsibilities (R&R) on the project.
• Use an R&R matrix to form the RACI (Responsible, Accountable, Consulted, Informed) matrix – focus first on 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 those bells and whistles to be included, not five months into the project.

• Requirements gathered during the session must focus on the project or service's "ties” rather than features and functions.
• It’s a tool to define technical and operational requirements at the chartering session.
• Use a tool like Mindjet'Mindjet'sager to capture these capabilities hierarchically.
• Build a list of capabilities through the paradigm below

With the integration of SAP and PeopleSoft, we could improve the processing of accounts payable by closing three days after the end of the month for all tier 1 accounts, using staff from the regional accounting centers in North America.

Step 4—Create a Mission?Statement. Drafting this statement for the charter will help team members and stakeholders relate the project to the business objectives and?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?
• Can we measure the value of the sunk costs in units meaningful to the stakeholders?
• If so, can we call this the “mission"
• Remember"r, the “mission" statement describes how the project, product, or service will positively impact the firm's firm's

For example

1. The goal is to produce?visual media, events, and artwork that build public understanding of climate change and energize commitment to solutions.
2. The formal organization – construct a grassroots organization to distribute the media to schools and environmental organizations.
3. The operational structure – build local action committees to “pull” t"is m"dia into community organizations to increase the awareness of local actions on the environment.

Step 5—Set boundaries on the project's?mission statement, guiding the team to the next step: setting boundaries for the project. Define the mission in terms of observable changes in the business process outcome.

• 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 a new request is made, 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 the process for initiating changes in advance.?

• Controlling changes for the sake of controlling change adds no value
• Please 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 measurables. Come up with measurables that show mission accomplishment. These measurements are the basis for setting project milestones (and checkpoints). The charter should articulate if a project proceeds and if milestones still need to be met.

• Better yet, create a deliverables-based plan that predefines the business value of 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 when they were expected to be delivered.
• This does not mean the project is done; it just means that the deliverables are maturing over time.
• Never measure progress by the passage of time or the consumption of resources – only by Physical Percent. Complete this in units of measure that are meaningful to the decision-makers.

Stage Gates and Milestones are attractive to external executives, but they do not measure the project project's progress. Only a 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. It is also one of the fallacies of using stories and features without Measures of Effectiveness and Performance for each Story and Feature.

Step 8—Set Risk Tolerances—Risks must be laid out, and their tolerance level must 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 will you wait to find out you are late, over budget, and off-specification?
• Every point estimate in the project is 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 schedule
• The same is true for the technical performance parameters

And remember,?all risk comes from uncertainty Uncertaintyinty Uncertaintyuncertainty

• Aleatory uncertainty can only be handled with?margin. Alea is a single Die used by the Greeks for gambling. Cost margin, schedule margin, and technical margin.
• Epistemic uncertainty by?buying down the uncertainty and redundant knowledge-producing actions.

Step 9—Set a clear statement of ownership. One person needs to be responsible?for the project. This avoids project death by the committee and the age-old "I thought you weren't "king 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 successfully delivering the project's outcomes.
• By projecting the people (accountabilities) with increasing maturity (assessment of physical percent complete at a point in time) and risk-adjusted forecasts of future performance, the stakeholders can answer the question of where we are.

Focus on accountability, and all the other "...ilities" will follow "ow

Have "new templates, but only a few – businesses should streamline the project initiation process by developing project charter templates. This speeds up the process and ensures new PMs include all necessary elements.?

• Templates are a good starting point but never the ending point
• Project success depends on factors that need to be more amenable to templates. What does “done” look like? How will we recognize “done” when it arrives?"
• How"much longer and more money needs to be spent to get “done.”
• Don’t be fooled by "templates"; they’re not the project management.
• Remember – the customer didn’t buy the templates; they purchased the project's outcome.
• Use projects sparingly. Focus on outcomes. As the saying goes in the aircraft business, 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.