The Charter Document – Scope

The Charter Document – Scope
By Robin Vysma

The charter is the document you have to do before you agree to begin a project. It might be a bound glossy publication with covers and company logos or it might be in the body of an email. What it looks like and what you call it depends on the culture of your organization and the profile of your project but what’s not negotiable is that you translate decisions and the commitments required for success into an unambiguous universally agreed record of your mandate.

Today I want to talk about the scope. In a mega-project this might be a document in its own right but mostly it can be incorporated into the charter as a section. That it is done poorly is often the reason so many projects fail.

‘Scope’ refers to the boundaries of the project, ie what’s in and what’s out. In some textbooks scope refers to budget and time-lines as well. They are after all boundaries too. In practice when I’ve talked about project scope most people take it as the project deliverables. That’s what I’m going to focus on as ‘scope’. Time-lines and budgets are worthy of their own headings in the charter.

The reason for documenting the scope is to remove any ambiguity as to what’s coming. To reconcile what the salesman has promised to what the team can deliver. Your ultimate role is to keep people accountable. In this stage those under scrutiny are the decision makers. In the enthusiasm that leads to the signature, sometimes the blanks are filled in with assumptions. Some will be reasonable, some will not. The one thing for sure is that not everyone will be making the same assumptions. Sorting this out is going to raise heckles which is never pleasant, however this argument at the beginning will be between stakeholders. If you leave it to the end of the project you will be in the firing line and even if you survive, you will forever be associated with an unhappy project conclusion.

So how do you do it?

Step one is very simply to tabulate the things you expect to achieve. This is effectively a tick list. When they are all crossed off then you have delivered what you have promised. During planning sessions when the room is full of optimism and enthusiasm you will hear many sounds of agreement however the implementation details, perhaps not so relevant at this stage will become very relevant in the end. Your job is to turn the ‘artists impression’ into architectural diagrams. To that end, each objective in the scope must be worded as – and this cannot be over emphasized – a measurable achievable outcome. To take the concept of ‘measurable’ one step further, while you are documenting the outcomes specify for each, exactly what will constitute a demonstration of ‘success’. Be so specific as to name who will do the demonstration and who will make the decision that that particular objectives has been achieved. You’ll be able to use this information later in the charter under ‘methodology /quality assurance’ but it serves to further strip the project objectives of ambiguity. In my book, ‘What they didn’t tell you about project management in class’, I use as an example objective, the establishment of a high speed data link between two particular buildings. This sounds pretty concrete. The ambiguity is exposed when the ‘test’ to demonstrate is discussed. Apparently different parties have different ideas of what constitutes ‘high speed’.

As well as removing ambiguity, you also need to address any assumptions spawned by the legitimate elements of your scope. If it includes ‘New kitchen’, some might assume that the microwave will be replaced as well as the oven. A ‘network upgrade’ might mean faster connections and new servers. It might also include a new printer. It might not. Your job is to remove the ‘mights’. To that effect look for and ask about related opportunities, that will not be addressed in this particular project. The ‘line in the sand’ is defined as much by what’s out as by what’s in. Your job is to make that line in the sand irrefutable and unambiguous.

Again you will quite likely cause some arguments, however at the start of the project that’s appropriate. Perhaps the point of contention will become another objective included, perhaps not. Perhaps the project will be canned! Either way the argument will be between those with the money and those with the need. The same argument at the tail end of the project, when the money has been spent, will put blood on the walls, most likely yours.

In summary your scope section in your charter document should look something like this:

Scope:

• Objectives included
  • Tabulate the things that, when ticked off, will mean the project has been completed.
  • Each objective must be measurable and achievable.
  • Define the test that will demonstrate that the objective has been achieved.

• Objectives excluded

  • Tabulate related opportunities which you’re not taking up at this stage.
  • Include a brief explanation as to why it’s being documented and why it is out of scope.

In both cases be clinical and dispassionate. You’re not ‘selling’ the project at this point, just quantifying the outcomes. You are not expressing opinions or even preferences, just documenting the wishes of the sponsors in the context of what the do-ers say is achievable. This may cause some friction and may necessitate some further planning dialogue. This is not a bad thing, this is you doing your job as project manager. This is you making sure that the end-of-project party is a happy one and not a lynching.

Robin Vysma spent 15 years managing IT projects in health and defense. His interest in how things were taught began when he worked as a tutor for an organization called ‘Study Methods’ in the 1980s. The Study Methods approach was different in that its primary focus was retention and learning skills rather than subject matter. You can read more from Robin on his blog.