The Power of a High-level Project Charter

In 1215 on the banks of the River Thames, forty barons convinced King John to limit his powers and recognize their rights by signing the Magna Carta. Although it ultimately failed to avert civil war, the document lived on to inspire and justify those rallying to democratic action for centuries to come.

Use a charter to answer why and plan

Why do IT projects need their own Magna Carta, and how is a formal written charter different from a project plan?

A charter is crisp and brief. It is a one or two-page treatise that paints a picture of the final outcome. It also aligns the project team and stakeholders to the end goal by describing what success looks like.

Done right, a project charter should be devoid of legal language. It is not the place to describe the technology solution and lay out all the tasks required to implement that solution on a timeline. That is a project plan, which comes later.

A core component of a charter describes the higher purpose Ws – Why a project is being done, What must take place to achieve this higher purpose, and Which metrics will be used to determine success.

When drafting your charter, you should consider the following:

A problem description: Perhaps you need to update IT architectural standards or an organizational process. Whatever your goal, a charter should start out by briefly stating what’s wrong or lacking about your current environment. When describing the problem, it helps to consider the following questions:

• A problem description: Perhaps you need to update IT architectural standards or an organizational process. Whatever your goal, a charter should start out by briefly stating what’s wrong or lacking about your current environment. When describing the problem, it helps to consider the following questions:
  • Where does the problem exist?
  • How big is the problem?
  • When and where does the problem occur?
  • What is the impact of the problem?
• Project objectives and goals: High-level goals should focus on the anticipated results of your effort. Executable objectives set to meet your goals should be realistic, specific and measurable. For instance, if you are implementing an IT disaster recovery solution, you can set a feasible target for your RTO and RPO. If drafted and acted on correctly, meeting measurable objectives will satisfy business needs and help your project stay on time and within budget.
• Project scope: A scope provides teams with what work needs to be done. When drafting your scope, identify boundaries for the project and be clear on items that will not be included in the project. This is especially important for items that others might assume are included.
• Project milestones: By listing a few key milestones and estimating milestone completion dates, you can chunk an overall project into smaller segments and create a chance for reflection and adjustments if necessary. For instance, your first milestone may be to define goals and objectives for an ideal data center architecture. In the process of developing your ideal, you may discover improvements that can be ironed out before it’s time to rack and stack equipment.
• Resource requirements: All large-scale IT projects will require a resource assessment. At the charter stage, you should provide high-level requirements estimates to make sure you stay within capital and operating budgets.
• Project flexibility: Your project needs will likely change as you progress toward your goal. Scope, schedule and cost are three constraints on every project that are not independent of one another. Defining points of project flexibility helps provide guidance to the project team.
• Cost estimate: A charter must include a timeline and the estimated cost it will take to complete the project. Don’t overdesign at this stage to get a detailed cost; rather, estimate on the high side and build some contingencies in so that you cover your overall cost. In this initial phase, you need stakeholders to own the project or approve it. Once the project is approved, you can develop a more detailed cost analysis.

What you exempt from your charter can be just as important as what you put in. Keep charters high-level. Don’t use it to develop a detailed project plan. Instead, define your problem and prepare for change as you execute.

Quick Tip: A charter describes why the project is being done and reveals the project’s ideal outcome. It’s not the place to draft a detailed project plan or explore solutions. If it’s written correctly, you can use a charter to help validate and verify your assumptions.

Where we left off: Managing infrastructure or services procurement and overseeing the lifecycle of IT contracts is a crucial component to large-scale IT initiatives. In my last post, I outlined proven steps for beginning profitable vendor relations.

What’s up next: Colocation can provide serious cost-savings, but it’s not always the best option for your data center. To address the reasons for and against colocation, I’ll outline some takeaways from a recent colocation whitepaper I developed.