Scope Tips

Author: Neville Turbit

Overview of Scope Tips

One of the most popular white papers we prepared is on how to set the scope of a project. Since then, I have been asked on a number of occasions to provide some more tips and techniques for estimating scope. This white paper on scope definition will pull together a number of tips and traps around the topic of defining the scope.

1. Unclear Outcome

I have seen many projects exceed their scope causing cost and time overruns because they had no clear idea what they were trying to achieve. You can define a project scope in many ways. Deliverables, objectives, KPIs etc and they all have their role. The most important, and the first one to define, is the outcome.

Outcome is the answer to a simple question.

“What will be different in the organisation when the project is completed? “

This is the critical question that causes many projects to fail. Take an example.

“What will be different is that we will know at any point in time what our stock levels are in each warehouse.”

Some obvious questions are:

“Does that include stock on order? Does it include orders due?”

Once there is a clear understanding of the outcome which may now be:

“We will know at any point in time what our warehouse stock is, and any commitments we may have. We will also know when stock is due to arrive.”

You have a starting point to define what you need to deliver to achieve that outcome. This leads you to the scope. The outcome should not only be defined. It should be understood and agreed between all major stakeholders.

2. The Players Change

This is a really unfortunate situation that happens far too often. You have all the executive support you hoped for and suddenly a key player leaves the company or is moved. A new player comes on board and wants to send you in a different direction. Consensus goes out the window.

I had this on one project where I was managing the selection and installation of a new financial system for a worldwide recruitment agency. I lost the CFO mid project. In fact he had been disengaged for some weeks and I could not understand why, until he announced his resignation. The mood within the organisation was to stop the project until his replacement was found and had time to understand the environment.

My argument was that although the CFO was no longer there, what had changed in the company’s need to replace an aging financial system running on obsolete hardware? There could be a minimum gap of 3 months between now, and a replacement being established enough to confirm or change the direction. What was the risk to the organisation of a 3 month delay? The decision was that the thought of a failed financial system was too great for the company to address. They decide to continue with the selection and replacement of the current system.

That brought us to part two. How to convince the new incumbent when he or she arrived, that the project was proceeding down the right path. Basically we put together a concise presentation that identified:

The problem
The implications of not addressing the problem
The forward plan and impact of any delays
What was still negotiable if we were to meet the deadlines
When those aspects became non-negotiable without incurring a delay
Progress to date
Immediate goals
What we wanted from the Sponsor
How we planned to keep the new Sponsor informed of progress
Anything the Sponsor required from us to keep him involved

We also ensured we had everyone else involved in the project supportive of the direction so that there would be nobody sowing doubts. Fortunately it worked. The Sponsor later said that it was a relief to hear about a part of the business that was on track, and had sound reasons for the direction it was taking. In terms of his involvement, he saw it as more a watching brief than having to become actively involved in setting a direction.

3. The Person who cannot say “No”.

This may be anyone from the Sponsor to the Project Manager to a team member. Whenever someone wants a change they always say “Yes”. Suddenly the scope is blown out of the water.

It all gets back to how the project is set up. If you put in place a scope variation process, and make sure everyone uses it, you stand a chance of managing the scope. For a start, all variations should go through one channel. It is usually the Project Manager but may well be a Steering Committee.

My preference is to have the Project Manager as a channel to the Steering Committee. Unless it makes it through the Project Manager, it does not get to the Steering Committee. This ensures that any variation is properly sized and costed. The implications must be understood before it can be considered. Any variation must also result in a variation to time and cost.

The Project Manager may have authority to accept lesser variations, but the Sponsor and Steering Committee must authorise major variations.

You know you have successful scope management in place when you hear someone say:

“Sorry but if you want to change something you have to go through the change process. I am not authorised to make changes that will impact time and cost.”

4. Scope and Requirements

This is one that consistently amazes me when I look at project scope. Much of the time, a scope estimate is made based on a requirements document without any attempt to translate that into deliverables.

Let me give an example. In a recent project I was required to quote on, there was a comprehensive requirements document. It covered what needed to be captured, and some of the desired reports. What was missing was a quantification of the requirements in terms of screens, reports, tables, environmental issues, security, audit history etc.

I wrote a quotation that specified there would be the following screens; the following reports; the following security functions; the following tables. To make it realistic I quoted an additional 10% to 20% on each category. I identified 25 tables but quoted on 30. There were bound to be some additional ones we could not identify and I did not want to turn each table into a scope variation. In the end we agreed what would be delivered but not necessarily the requirements to produce each deliverable.

Don’t fall into the trap of quoting on a broad requirements document. The time and cost is related to what you have to build, not what outcome you achieve. The benefit comes from the outcome. If the deliverables are aligned with producing the outcome, they will translate into a successful project. What you need to be sure is that you have enough time, resources and money to build those deliverables.

5. I forgot to quote on that

You have to constantly ask what else is involved in this project. I was asked to go over a proposal someone was preparing for an ERP implementation recently. They were costing out a proposal to put to an organisation to implement an ERP system for them. One glaring omission was data cleansing and preparation. The person had not seen this as a major issue. Anyone who has done an ERP implementation will tell you that data can be a major headache. I suggested they do a sampling of the data then do a quote. If you are not on familiar ground, get as much outside advice as possible.

6. The Peripheral Scope Issues

Another trap is to quote only on the visible deliverables. For example we are building an order entry system and we quote on building an order entry system. What about training, new forms, hardware, manuals, business process changes, travel to install the software and train people away from head office, development software, testing software, consulting from knowledge experts, customer liaison, data conversion, audit approval of the system, security testing, integration with other systems, technical documentation, perhaps even cost of preparing an RFI and evaluation of package solutions.

7. The Task from Hell

This one is very close to my heart. Project Perfect was burned on a fixed price contract a few months ago when we totally under quoted a particular task. Every Project Manager has been there. A task looks straight forward and you quote a week, or a month to complete it. When you start you find out there are complexities you never envisaged. It is going to take you five times as long – and that is with putting all available resources on it. In our case, we ended up working for less than 20% of the rate we based our quotation on.

So what did we learn? Firstly, with all the best information available at the start of the project – or in our case when we provided the quote – some problems are going to be more complex than you could ever imagine. This raises two issues:

What do you do when it goes pear shaped?
How do you manage these within the planning stage?

Our answer to the first was to advise the client very early that we had hit a barrier. We offered some options. These included:

Moving the deadline
Delivery of part of the solution and not completing the problem functionality
Leaving the problem area until later and moving onto other parts of the project.

In the end the customer decided we should move the deadline. We made it clear that given the unfolding complexity, it was not possible for us to quote a final date. New information was coming to light every day. In the end what had been planned as around 4 days work took the best part of a month. The client was not happy, but they were at least engaged. We were bearing the cost of the additional work. We kept them involved in viewing prototypes and discussing the various dilemmas we faced in resolving the issues.

On the second question of how do you plan for these, there is a simple truth. At the early stage, you don’t know what you don’t know. You only know there are things you don’t know. You MUST build these into your plan. I have had the contingency argument with many managers and won more than I have lost. I come back to the line

“If you can define precisely what you want, I will tell you how long it takes to deliver and how much it will cost. If you want me to quote on finding out what you want to deliver, and then delivering whatever that may be, you are asking me to do what you, as a responsible manager, would never do. You want me to say that whatever you want, I will deliver it for this amount of money, and in this time.”

In our case, Project Perfect lost a bucket load of money on that job. The positive thing that came out of it was that the client was impressed with our approach. They were annoyed that we did not meet our timeframe, but after becoming involved, realised what a difficult situation we faced. They also realised that it was not for lack of trying that we were struggling. Our loss of revenue proved that. They were also involved in selecting the path forward.

The end result was we lost money but gained credibility in the eyes of the client. Hopefully more work will come our way which will help compensate for the loss on that job. In terms of predictability of the problem, even in retrospect, we would have been hard pressed to do a better estimate. We did have some contingency in the quote, but it was nowhere near enough. Put it down to that 1 in 20 estimates that is going to blow out. Your emphasis has to be on managing the fallout.

Conclusion

Scope management is one of the most difficult parts of managing a project. It is fine for an organisation to say at the start, they want to know what they are committed for, but sometimes it is unrealistic to believe the answer is going to be more than a wild guess. If you are involved in quoting on a job ask yourself how you want to manage risk and reward. The reward may be the contract, but if the risk is high because you are shaving the estimate, is it all worth while? There are many more projects come in over budget than under budget.

We could probably end up with a list of many more scope traps. Hopefully the experiences documented above will help people avoid making the same errors that we have made.