How to better manage definition of project scope for business change projects?

Question

My unit manages business change projects. In order to flesh out what a project is (i.e. what are we trying to accomplish, what is the scope, how do we define success, etc etc) we tend to get bogged down in a time consuming, iterative process that is frustrating for everyone concerned.

Does anyone out there have any suggestions for ways to efficiently and effectively manage definition of project scope in the early "starting a project" phase when you have a good idea of where you want to get to in terms of benefits but don't have a good idea of what the end product will look like or how you would get there?

Answer 1

You need to break it down into several sub-discussions, each with a different goal. Then try to keep everyone to the one topic.

A couple of suggestions -

First, it sounds like your unit manages change for other units? Then the first step is to identify the relevant stakeholders, and get their input - what do they want, how do they define success, what does 'done' look like, etc. If this is for your own unit, then the same questions apply really, but the key part is making sure you stick to the "why" of the project first. Scope comes later.

Second, once you've defined the 'why', now you move to the what - 'scope'. What's needed to accomplish this goal, what's included and what's not.

After you have the 'why' and 'what', then it's on to the how - planning.

By breaking it down this way and separating the different aspects, you can keep the discussion moving - if it starts to drift you can always bring it back with "great point, but's more scope related, and first we need to define X", or that's more planning related and first we need to define the sope to se if that's even going to be necessary", etc.

Answer 2

Have you tried using a Work Breakdown Structure? http://www.youtube.com/watch?v=80c-LRRJ0W8

Answer 3

I see that @Trevor K. Nelson has already provided what I think is the key element of the answer - obtain feedback from critical stakeholders. But there are many processes that can become bogged down in similar quagmires.

One of my mentors was fond of establishing "no fly zones" - identify the topics that generally are rapid paths to the quagmire and agree ahead of time not to discuss those topics. Any group member can point out that the discussion is veering towards a no fly zone. Make sure that the identification of the "no fly zone" isn't judgmental. We're not avoiding topic X because it is bad, but because we simply won't have enough information to deal with it productively, or (and this is a big one for us) because stakeholder X has declared it off-limits. We may not agree with Stakeholder X, but we know that if we include this topic in the discussion, stakeholder X will oppose us, and the issue simply isn't worth the effort. The no fly zone helps to avoid the quagmire and keeps the discussion productive.

The other alternative that comes to mind is to impose time constraints. Depending on what precisely is dragging you into the quagmire you can either agree that if topic X comes up, it can only be discussed for 15 minutes. At the end of 15 minutes either (a) assign a couple of people to construct a formal response to stakeholders for feedback on the topic, or (b) assign a couple of people to struggle with it in private and come back to the group with an alternative or (c) table the topic, take a quick break and then resume from a new angle. Which alternative you pick depends on which route is leading to quagmire. Time limiting the discussion does two things (1) it avoids the discussions which drain the energy and enthusiasm of the participants and (2) it shifts the psychological ground away from "can I win this discussion?" to "Can we really reach agreement in the allotted time, or is there a better strategy?"