The management spectrum and the planning process

The thinking move: a plan is a set of answers, not a set of dates

Ask an inexperienced engineer for a project plan and you get a schedule. Ask an examiner what a plan is and the right answer is a set of answers to questions that must be answered before work starts — and the schedule is one of them, quite far down the list. This matters for the exam because almost every management question is really asking which question did you answer first, and why. If you can produce the questions in order, you can produce an answer to a management question you have never seen.

The frame the course uses for this is the management spectrum: the four Ps — people, product, process, project — and the order is a claim, not alphabetisation. A manager who mishandles people cannot be rescued by a good process. A manager who handles people well but never bounds the product builds an elegant solution to a problem nobody has. A manager who has both but no process drops competent technique into a vacuum, with no checks and balances and no defined outcomes. And a manager with all three who never turns them into a tracked project finds out too late that none of it converged. Each P is a precondition for the next one being worth anything. Say that sentence in an answer and you have earned the mark the ordering carries.

Product: the difference between a description and a bound

Software scope is the first substantive planning artefact, and it is not a feature list. A statement of scope names four things: the context the software sits in, the information objectives — what data goes in and what comes out — the function it must perform, and the performance it must meet. The load-bearing word is bounded: every one of those must be stated quantitatively enough that someone could tell whether it had been achieved. "The app should open the locker quickly" is a description. "A valid scan opens the correct door within three seconds at the ninety-fifth percentile, on a four-year-old Android handset, over 4G" is a bound. You cannot estimate an unbounded scope, you cannot schedule it, and you certainly cannot test it — which is why scope comes before all three.

Once scope is bounded you decompose the problem: split it into functions small enough that a person can hold one in their head and put a number on it. Decomposition is the hinge between the product and everything downstream, because estimation, the work breakdown structure and the task network all operate on the pieces it produces.

The planning task set

The planning activity itself has a task set, and it is worth memorising in order because it is the skeleton of every applied answer in this module: establish scope → determine feasibility → analyse risks → define required resources → estimate cost and effort → develop a schedule. Feasibility is the honest question of whether the thing can be built at all with the technology, people and money available; it is cheap to ask and expensive to skip. Resources come in three families — human (how many people, with which skills, for how long), reusable software (off-the-shelf components, full-experience components your team has shipped before, partial-experience components that need adaptation, and genuinely new components), and environmental (the hardware, tools, licences and test rigs the work needs). Each resource is described by the same four attributes: what it is, how it will be described, when it is needed, and for how long.

W5HH — the smallest plan that is still a plan

Boehm's W5HH principle is seven questions whose answers are a project plan: Why is the system being developed, What will be done, When will it be done, Who is responsible for each function, Where are they located organisationally, How will the job be done technically and managerially, and How much of each resource is needed. Its two virtues are that it is scale-independent — the same seven questions serve a two-week increment and a two-year programme — and that it forces why to be answered first, which is the question a doomed project has usually never asked.

Worked example — BorrowBox release 1 in seven answers

BorrowBox is a neighbourhood tool library: members reserve a power tool in an app, collect it from a bank of smart lockers with a one-time token, and return it to any door. Release 1 is four people — two app developers, one integration developer and a designer at half time who also runs the usability tests — over twelve weeks, with one bank of sixty doors.

Writing W5HH for it takes about fifteen minutes and produces a document a stakeholder can argue with, which is the point. Why: about four hundred households each own a drill used twice a year, and a shared bank replaces those purchases. What: reserve, collect, extend, return, report damage, charge a late fee — one neighbourhood, one depot, no multi-site support in release 1. When: twelve weeks to a field trial on bank 1, general opening four weeks later. Who: named owners per function, with the integration developer owning the locker path end to end. Where: the four of us in one room; the librarian and the council sit outside the team and sign off scope. How: incremental delivery in two-week increments, with the locker path built against a simulator until the vendor SDK arrives. How much: about eleven person-months and one hardware budget line.

Notice what the seventh answer depends on. "About eleven person-months" is not a guess produced by looking at the ceiling; it is the output of the estimation work in the next lesson, which in turn needs the bounded scope from the second answer. That dependency chain is the plan.