Project Charter - Abraic

Making the Most out of the Project Charter

When a project charter is not focused on outcomes the eventual results are bound to be disappointing. A business case for a project typically describes expected benefits as a justification for the effort. However, the charters typically fail to mention these benefits and lay out operational aspects of a project, such as scope, timeline, budget, approach, governance, workflow and team structure.

Why do we lose sight of the reasons we are doing this? The answer may be that it is easier to measure and manage operational metrics, while outcomes are not hard wired to a technology solution.

Such charters redefine the project success criteria from the benefits to scope, timeline, and budget. As a result the project team will do everything that is possible to meet the scope, the timeline, and the budget. But the devil is in the details. As the scope is translated into a solution, whenever there is a choice, the team will pick an alternative that do not temper with scope, timeline, and budget, regardless of the effect this choice makes on the outcomes. In some cases we see project teams sacrificing functionality that would otherwise result in more value.

It is critical to evaluate (e-value-ate) your project charter. Let’s recognize that the scope, the timeline, and the budget are the cart while the outcomes are the horse. To help with the evaluation I am listing some of the typical holes in project charters with regards to outcomes.

Planning to derive value in Phase II

“Let’s get it up and running first – the benefits will come later” is a philosophy that is often adopted for implementations of packaged solutions. This philosophy is clearly irresponsible – none of us would invest our family budgets in technology if we didn’t have a clear plan for utilizing it. Provisions must be made in the charter to make sure that solutions being created can in fact be used as the foundation for well-planned, high-return follow-up initiatives.

Overly-aggressive rollout plans

Of course everyone is anxious to get the new technology up and running. Quick completion of projects frees up resources and allows for the start of other projects. However, when speed is the only parameter that matters, the project team is bound to make regrettable choices that will prevent you from enjoying the business value for months or even years afterwards.

Expecting technology to single-handedly deliver strategic value

Technology alone carries no strategic value. We all know that the value is in how a technology is utilized that makes a difference. To put it another way, a great driver in a slow car will do better around a track than a bad driver in a fast car. The charter should outline an approach that shapes up a solution based on its eventual use. I find that translating the scope into use cases that spell out exactly how a new business process will work with the new solution to be very helpful in fleshing out exactly where the value will come from. I will have more approach related suggestions in future posts.

Not accounting for business value in scope

The most critical component of a project charter after outcomes is the scope. It is the scope that will dictate the timeline and the budget. There has to be a direct or causal logic that matches scope line items to the benefits outlined in the business case. Most technology solutions will have a direct correlation between features and benefits. It helps to spell out these features as must-have scope components. In some cases there is an indirect, or causal, connection between features and benefits that may not be directly derived from a solution but rather come about over time. It is still important to list out all these features as a part of the scope.

Calculating ROI based on cost savings only

There is nothing wrong with cost savings. In fact, it is a noble cause for tactical efforts. However if you are planning a strategic project that is large enough to require a business case and a charter, it really needs to be more ambitious than saving money. Having said that, if your project approach includes momentum building based on quick wins, cost saving opportunities tend to be easier to attain and demonstrate. More on that in further posts dedicated to change management.

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *