If you don’t scope and plan a project in a day, what’s the alternative? It goes something like this: Somebody identifies some kind of need, requirement or problem that needs to be tended to. Based on this, somebody does some investigation and then writes some sort of proposal, business case or specification. This is reviewed by the stakeholders and the reviews are fed back to the author of the document.

There are updates to the document, plus perhaps flurry of e-mail exchanges, phone calls, requests for information and meetings to resolve various issues. Proposals get looped around a number of times until finally … there is agreement on what we are going to do.

Then somebody is charged with building a plan. That somebody does some further investigation and then writes a plan. That plan is reviewed by some or all of the stakeholders and the reviews are fed back to the author. There are updates to the plan, perhaps more e-mails, phone calls, requests for information and meetings – particularly if there is a gap between what the stakeholders want and what the project team says is possible. And so the plan get looped around a number of times until finally … there is agreement on the plan.

So we finally know (a) what we’re going to do and (b) how we’re going to do it.

This process can take weeks, month or years in some cases. As an alternative to all of this, you can scope and plan the project in a day.

In their book, Developing Products in Half the Time, the authors Smith and Reinertsen refer to the beginning of the project as ‘the fuzzy front end’. They say this: ‘Time is an irreplaceable resource. When a month of potential development time is squandered, it can never be recovered Each additional month has a quantifiable cost of delay. Our goal as developers is to find opportunities to buy cycle time for less than this cost. These opportunities, large and small, appear throughout the development process. There is, however, one place that we could call the ‘bargain basement’ of cycle time reduction opportunities. It is the place where we consistently find the least expensive opportunities to achieve large improvements in time to market. We call this stage of development the Fuzzy Front End of the development program. It is the fuzzy zone between when the opportunity is known and when we mount a serious effort on the development project.’

If the ‘fuzzy front end’ is where ‘opportunities to achieve large improvements in time to market’ are greatest, then scoping and planning a project in a day is the best way of maxing out those opportunities.

Projects are often characterised by interruptions. We do some stuff and then we have to wait, for example, for reviews, for approval or for input from other people. Nowhere is this truer than in the fuzzy front end. Everyone believes they have something to contribute, lots of people want ‘signoff’, and there are always those, who feel that their input is being ignored. At the same time, because the project hasn’t really yet gotten off the ground, there are always a million and one things more immediate and pressing. The net result of all of this can be a long and frustrating period while requirements are identified, nailed down and agreed; and all of this before work on a plan can even be started.

We can circumvent all of this, telescoping everything into one decisive, highly effective event called a 1-day project scoping & planning session.

Convincing stakeholders

Given that people are almost always skeptical of something new, it’s probably best to assume that some or all of your stakeholders will be skeptical about your idea. They’ll maybe say that they can’t devote a whole day to a single project; or that they can’t devote a whole day to planning.

Your best argument is to point out to them that doing it the traditional way generally consumes far more effort. Any meeting is going to be at least an hour. Then there’s preparation time - reading and understanding what has to be read in advance of the meeting. There’s follow-up afterwards. 2-3 meetings will easily end up being equivalent to a day’s effort.

But there’s not only that.

There’s also the thing we might call ‘put down pick up‘ where you leave something and then have to come back to it some time later and get your head around it again. (These are examples of a more general problem – the inefficiency of multitasking.)

And this is not to mention things that happen between the meetings – emails or phone calls to be answered; people dropping in with ‘just a quick question‘ or ‘taking something offline.‘ All of these which have their own ‘put down pick up‘ time associated with them.

And assuming you’re trying to get your project off the ground as quickly as possible, doing it the traditional way – as described above – is going to take far longer than if the stakeholders had just set a day aside to get the thing done.

What kinds of projects is this applicable to?

In my experience, there are two types of projects where this technique is applicable. These are:

• The business case to carry out the project has already been made and the organisation now wants to go ahead and get the project done as quickly as possible.
• The organisation is not clear on the scale of the project and wants to better understand what the project will cost in terms of time, effort, resources and money.

How to scope and plan a project

To scope and plan a project you – the project manager – need to get the answers to six questions. These are: