Can I add more scope and still deliver on time? Or should I Scamper
July 30, 2012 Leave a comment
I often seem to face the same problem – how can I reduce my resources, increase my scope, improve quality and go faster?
The best answer is – be clear on what you really want and decrease your scope. Sadly that is the opposite of what people want to hear, but usually delivering the right thing (done well) is better than delivering a lot (even if its done well).
But I have also found that the grinding task of trying to fit more in and failing can actually help you define what you really need. So I often find the process worthwhile even though I end up with a different scope rather than a bigger one. So here are some ideas I have tried:
Options and outcomes:
- Cut corners and deliver tactical solutions to fit more in
- Never say never … except that you can say that this will never work
- Every time we cut corners we end up spending longer trying to fix what we did and then fix it again later in production … and then fixing it again properly after that
- The result is that I always imagine my grandmother looking at me and saying “there is never time to do it properly, but I bet you will find more time to fix the crisis later”
- Add resources
- Experienced project managers will tell you not to do this, but I still try sometimes.
- When done right at the start it normally results in getting more done but at greater expense for what got delivered. Each person adds more communication overhead and more assumptions and this quickly ends up passing the point of adding value
- When done later in the project it always ends up with us taking longer and then me re-reading the old classic “the mythical man month”.
- Use Scamper or options generator or other brainstorming solution
- Generally I end up changing the scope and delivering something better
- Stakeholders always come back later and say “remember we were also going to do (everything we mentioned in the brainstorming before removing it)”
So on balance I think scamper is the best approach.
- List your entire scope and prioritise to taste
- Choose a deadline and lock it in
- Estimate very roughly and work out what is likely to get done and what will probably not get done
- List all the disappointing things you fear (or know) you won’t get done
Now take your list of disappointing things and do the following for each item:
- S – see if you could substitute it for something else
- What can you re-use that is already in the system?
- What can you integrate with that already does it? For example do we have another system or product that we could use? Or another feature?
- What manual work or training could be done to do it?
- What other tools could users make use of (eg Excel or Word for report generation)?
- The gold question – What esle could someone do to meet the need that this addresses?
- C – Combine
- What requirements could you combine with this to deliver something?
- Could you bring together several requirements to deliver the essential components of each and then drop other elements
- A – Adapt
- How can we adapt an existing feature (or report etc) to include this item?
- How can we adapt the way someone uses our product to address this need?
- M – Modify
- If we can’t do this, how could we modify the request to do what we can deliver?
- How could we modify another requirement to deliver part of this request?
- P – Put to another use
- If we did do this, what else could our solution be used for?
- If we did this, what existing feature could we replaceor make obsolete? What process or manual effort could we eliminate?
- (This might change the priority so that it is worth doing. It often actually creates a need for you to do further investigation and talk to additional people – which justifies putting it in a future release to give time for feedback – which is a happy outcome for any project manager)
- E – Eliminate
- The favourite of most project teams – how can we eliminate this request?
- But hang on a minute, there is more. How can we eliminate SOME of this request to make the rest achieveable?
- What is stopping us (not enough people, not enough time, it is illegal etc). Now what would happen if we could overcome that constraint? Don’t worry about how just yet, just “what would happen”? Sometimes you find you couldn’t do it anyway and sometimes you suddenly find a way because you can see it actually happening
- How can we shave complexity from other requests to make time for this feature?
- What else can we get rid of? This could be another feature or it could even be part of our usual process. For exampe “we can include this but it means we won’t have time to test anything”. This sounds bad but can lead to more challenges that lead to the right outcome
- R – Reverse
- How can we change the flow of events to make them more efficient? For example, could we add the global solution first and then the local ones, instead of our existing plan of adding local functions and then creating a global version?
- Could we build the features in a different order?
- The real purpose of this idea – simply go through your scope in reverse. Assume you are doing all the least important stuff and descoping the most critical ones. Then see what would not be delivered and start the SCAMPER process again. You might find that one or two changes at the top result in many different options
Hope that all makes sense. It never seems to result in the magic of some other techniques. But it often results in a better outcome after all the debate.