Keeping Your Project on Scope

by Bruce Beer, PMP:

Note: This is part 3 of a 3-part series.

The first in this series of Keeping on Track blogs dealt with how to keep your project on track with regard to time, the second dealt with how to stay within budget, this final blog in the series now looks at keeping to defined scope and how to avoid the dreaded scope creep!

As with time and cost, to be able to meet your scope baseline you first have to establish it. Project implementation can either be based on a firm, solid bedrock of requirements or it can be built on the shifting sands of indecision, false assumptions and differing interpretations that will eventually sink the project and lead to project failure, recriminations, accusations, heated arguments and potentially a visit to the unemployment office for the PM. So what are the basic requirements for a solid scope baseline and how do we create one?

The first step, often omitted, is to identify ALL project stakeholders – anyone who impacts or is impacted by the project. “Why is this” I hear you ask. Well any one of those stakeholders may have a requirement that is vital to the success of the project, and if we miss this requirement it may take time, money, and added complexity to include it later. So we will interview, perform surveys, have workshops etc. to ensure we get the full set of requirements at this stage rather than during acceptance testing! However, note that not all stated requirements will be included in the final scope of the project because each requirement has to be cost justified.

Once we have identified all requirements we can then start building our project scope by first identifying the deliverables required to meet them, then discussing and agreeing these with the customer (the person paying for the project) to decide which requirements are “must haves,” “wouldn’t it be nice ifs,” and “bells & whistles.” At this stage, if there are any areas of uncertainty, they should be clearly identified as definitely either “In scope” or “out of scope” just so that there is no ambiguity or room for interpretation at a later date. Then we can create the Work Breakdown Structure (WBS) – the heart of all project planning – based on these deliverables, followed by a specification. The WBS together with the specification creates the scope baseline. The purists amongst you will know that there is a third element of the scope baseline, the WBS dictionary, but we will not consider this now.

OK so now we have a solid scope baseline. We know exactly what it is the project has to deliver and have created a detailed project plan based on the WBS. All we have to do now is to ensure the project meets the three baselines. Controlling and meeting the scope baseline is probably the easiest of the three baselines to achieve as there is one main process used to control scope – change management. This means that ANY deviation from the original specification will need to be formally requested, evaluated and authorized by the customer before it is implemented. Some people may think that any change that does not involve additional time or cost does not need to go through the formal rigor of change management. These are probably the people out on the street looking for a new job wondering why their life took such a sudden and unexpected downturn.

Let us consider an example where a customer wants to change the length of an address line from 25 to 30 characters. Let us assume this is recognized before the programmer has written that section of code, so there will be no additional time or cost just to extend that field. So why bother to create a formal change request for such a simple change? OK, well let us look at this from three main viewpoints: ripple effects, acceptance and stakeholder satisfaction.

1.       Ripple effect

If there is no formal change management process, the programmer extends the address line and keeps this as a well hidden secret because they do not want the PM to find out they did it. What harm can it do? Let us suppose the address is part of the order input screen. Other areas of the software such as invoicing will be working on the specified basis of 25 characters per line, so all printouts, disc records, searches, etc. would use this basis. So the ripple effects of this apparently innocuous change can be many and serious.

2.       Acceptance

Now let’s look at acceptance for the above. During acceptance testing, the person performing the test will look at the specification (25 characters), incorporate any formal authorized changes (none), and will expect the test to meet this combined requirement (25 characters). The tester puts in a 24 character address, expecting it to be processed correctly. Then they will try a 25 character line with the same expectation. Then they try a 26 character line and expect it to fail and produce an error message, and guess what, it doesn’t do this, it accepts the over-length line without any problem. The tester will then declare that acceptance test has failed.

Now let us consider the correct procedure. The customer creates a change request for the address field to be changed to 30 characters and gives it to the PM (all change requests must go to the PM). The PM logs it and sends it out for impact analysis. The analysis comes back identifying other parts of the project that might be affected by the additional characters and additional changes that might be required. Then it might say that there is minimal or no time or cost impact. The customer would formally authorize this change and the change is implemented. The acceptance tester will see the initial requirement of 25 characters, will have the authorized change to 30 characters and will test accordingly, and lo and behold it passes acceptance.

3.       Customer satisfaction

Now let us look at customer satisfaction. Consider a fairly substantial change. If the change does not go through the formal process it will not be formally approved, so in addition to failing acceptance we now have additional time and cost to worry about. We as PM are measured against how well we perform against the project baselines (customer expectations) for scope, time and cost, so immediately the PM now fails on all three baselines. If there had been a formal approved change request, the project would then meet the scope requirement (initial specification plus formally approved changes). If the project took longer than initially planned but there are formally approved change requests providing an audit trail for the additional time to perform changes, then the initial time estimate plus authorized additional time is the new measure against which the PM will be judged. The same with cost – the initial cost plus approved changes is the new measure for the PM, so providing they meet their initial estimates plus allowances for formal changes, all is good and a pay rise is on the horizon. In conclusion, formal change management creates an audit trail of authorization for any change to the original baselines.

Most companies these days will have a formal change management process with which the PM should be familiar and use. One of the key areas discussed by a PM during the project kick-off meeting will be to review, explain and distribute copies of the change management process to all stakeholders. The PM should explain the serious repercussions of not following this process! If the customer is not at the kick-off meeting, the PM should review and agree the process with them prior to the start of implementation to ensure it is understood and agreed.

Final thought: if you have read all these blogs you will know they are highly interrelated. If time or cost start going out of control, one option depending on constraint priorities is to de-scope the project to bring it back on track. De-scoping will involve looking at “bells & whistles” first to see which can be removed with least impact on the end product. Once all of these have gone, the next object of your gaze will be the “wouldn’t it be nice ifs.” If you reach the end of these and are left with the prospect of de-scoping some of the “must haves,” you have a serious problem. Removing any “must haves” will affect the viability of the project, so at this stage scope cannot be reduced further. You will need to review cost and time to reach the optimum results.