Solution-based scope vs. problem-based scope
OK–we’ve now caught up to 1970’s project management.
Scope control is central to project management. Projects should have a charter and a scope statement, and there should be a process for reviewing scope changes before they are approved. If you don’t have project scopes defined and under control, then the project manager is the walking, talking project scope and their life can be very difficult.
I don’t believe you can skip this step. You have to walk before you can run, and if you don’t have defined project scopes then projects may never complete.
However, let’s say that your project scopes are defined and project scope changes are controlled. (Yay!) Let’s review how the scope was defined: customers and a project sponsor guessed at what solution they wanted, and then they worked with the project manager and/or business analysts to define the solution more concretely–sometimes to the level of screen mock-ups. Perhaps (hopefully) an IT architect or a subset of the project team was involved. The danger here is that the solution is defined before the problem is well-understood.
This is why the excellent book Lean IT recommends putting the problem under scope control rather than the solution, and using an iterative approach to deliver value to the customer based on a better understanding of the problem.
Lean IT devotes an entire chapter to this concept of iterative, problem-based projects and I’m not going to repeat their recommendations here. Please check out the book–as I’ve said before, I think it’s the best IT management book I’ve read.
It turns out, many typical project charter sections become more important when you have a problem-based scope. It’s much more important to understand the goals, objectives, and constraints, because the project team can start to dig into root causes and build something (perhaps something unexpected) that might provide more value than what was known at chartering time.
When project solutions are scoped, the project is done when deliverables match the specified solution. If the solution doesn’t actually help anyone, that’s the customer’s problem–they should have scoped the project differently.
When project problems are scoped, the project team takes on responsibility for value creation. The project team knows what is possible, and they must learn the processes involved. Then, with their expert knowledge of the problem as well as their domain-specific knowledge, the project team can work together to find (and experiment with) solutions.
Many, many times an IT solution is requested for an out-of-control process. When project problems are defined, the project team might find solutions that require very little IT. Google Forms may be sufficient for tracking the number of calls received each month. Or, perhaps there could be a button on the phone that counts every time it’s pushed. These solutions may work when the original proposed solution might have been “implement an ACD system.”
Getting project teams and stakeholders to move to iterative, problem-focused projects means people across campus trusting one another more, and people moving outside their comfort zone. Technical people may feel more comfortable blaming Institutional Research rather than talking to them and finding out the IT tool is crashing every day.
The value of moving to iterative problem-focused projects, however, is huge. IT tools are only implemented after there is a demonstrated need and after other options have been considered. Project teams learn more about what’s valuable to the institution, which they can carry forward after the project. IT project failure rates can go down as problems are better understood.