Choosing what to run

AIM Pick a first project that matters and that you can win.

You walked the process, captured the field, routed each problem, and framed the ones that stayed. Now you hold several real candidates and you can run only one first. This chapter is about that choice. Choose the wrong first project and a good method still fails. Choose the right one and a modest result opens the door for everything after it.

9.1 The worthiness screen

By the end of the last chapter you had more than one problem worth solving. That is the position you want, and it is also the moment of most danger. With a sponsor waiting and a deadline pressing, the pull is to grab the loudest problem and start. Resist it for one more step. A short, honest screen across the whole field protects you from a first project that cannot be finished or cannot be held.

The worthiness screen holds four lenses over every candidate. Impact, feasibility, control, and data. You are not scoring for a perfect answer. You are separating the projects you can win from the ones that will sink a new function before it has proven anything. Figure 9.1 sets the four lenses out.

9.1.1 Impact

Impact asks how much fixing the problem matters. Matters to the client who feels it, to the board that is watching, and to the cost line that carries it. A problem with high impact earns attention and funds the work that comes after. A problem with low impact, however easy, teaches the firm nothing and wins you nothing.

Read impact in the firm's own terms, not yours. A statistician sees variation. A board sees churn and cost. The same problem scores differently depending on who is asked, so score it the way the people who hold the money would.

9.1.2 Feasibility

Feasibility asks a blunt question. Can you finish it. With the time you have, the access you can get, and the skill in the room, will this project reach a real result inside a sensible window. A problem can matter enormously and still be the wrong first project, because it is too large, too tangled, or too political to close.

On an immature ground, feasibility is often lower than it looks. The data is thin, the process crosses walls, and no one has run a project here before. Score feasibility for the firm as it is, not the firm you wish you had.

9.1.3 Control

Control asks whether the change sits inside the firm and inside your reach. A problem whose fix depends on a supplier you cannot direct, a system no one will change, or a decision that sits three levels above your sponsor is a problem you cannot close, however worthy it looks. Control is the lens new practitioners weigh too lightly, and it is the one that sinks the most first projects.

Control does not mean the work is small. It means the levers that move the result are reachable. A cross-team problem can be highly controllable when one sponsor sits above all the teams involved. A small problem can be uncontrollable when its real cause lives outside the firm entirely.

9.1.4 Data availability

Data availability asks whether you can measure the problem. Now, from a system you can query, or soon, from a short manual collection you run yourself. You do not need perfect data to start. You need a path to a number. A problem you cannot measure at all is a problem you cannot prove you fixed, and an unprovable win is worthless on a ground that has never trusted the method.

Be strict here. A figure everyone quotes but no one defined is not data. Score data on what you can actually stand behind, not on what the firm believes it has.

9.2 Weighting for an immature firm

The four lenses are not equal everywhere. In a mature firm with a quality function and clean systems, impact and feasibility carry most of the choice, because control and data can be assumed. On an immature ground you cannot assume them. So you weight them up. Figure 9.2 shows the shift.

9.2.1 Why control matters more here

In a firm with no system to hold a gain, control is the difference between a result that lasts and a result that evaporates. If the levers sit outside your reach, you can run a clean project, prove the cause, design the fix, and still watch the change die because you could never reach the thing that had to change. On a ground with no track record, a dead first project is not a neutral outcome. It confirms the suspicion that the method is theatre.

So you weight control up. A slightly smaller problem you fully control beats a larger one you only partly reach. The first project is not the place to test how far your influence stretches. It is the place to prove the method works, on ground where you can guarantee the levers are in hand.

9.2.2 Why data availability matters more here

Data carries the same extra weight, for the same reason. In a firm that has never run a structured project, the result has to be proven, not asserted. A number moved is an argument no one can wave away. A claim with no baseline is just another opinion, and the firm has heard plenty of those.

This does not mean you only pick problems with clean data waiting. Most immature firms have none. It means you pick problems where a path to a number exists, even if that path is a two-week manual collection you build by hand. A measurable problem with no data yet beats an unmeasurable problem with a full system behind it.

9.2.3 Reading the four criteria together

The screen is a guide, not a verdict. You do not add the scores, crown the highest, and stop thinking. You read the four together and apply judgement. A candidate that scores well on every lens but impact is a safe, quiet win that changes nothing. A candidate that scores high on impact and control but thin on data may still be the right first project, because the data gap is one you can close in a fortnight.

The screen earns its keep by removing the candidates you should not touch first, not by choosing the one you should. It clears away the unwinnable and the unholdable, and it leaves you a short list of real options. The final choice, among those, is yours to reason through.

9.3 Building the improvement register

The candidates you screen do not disappear after you choose one. They go into an improvement register. The register is the single place where every known problem waits, ranked, ready for the next belt or the next slot. It is the start of what a mature firm calls a portfolio, and on an immature ground you build it yourself, from the first week. The question that decides whether it works is where it lives. Figure 9.3 shows the idea.

9.3.1 A shared tool, not a private sheet

Hold the improvement register in one centralised place the organisation can see. The common habit is to keep it in a spreadsheet on your own drive, and that habit is the failure. A private sheet helps no one but you. No one else sees what is ranked, what is running, or what is waiting, and the whole thing dies the day you move teams. Visibility is the point of the register, and a hidden sheet cannot give it.

So put the register in a shared tool. One place, open for anyone who needs to read it, with write access held by you so the ranking stays clean. A problem raised, a status changed, a project closed, all visible to the firm without anyone having to ask you. That is the difference between a register that runs the work and a sheet that records it.

Reach for what the firm already owns first. Most organisations already have a shared board, a list, or a tracking tool that people use for other work. Use it. A tool already in the building skips the cost of buying one and the harder cost of getting people to adopt it. You are not introducing software. You are giving the improvement work a home in a tool the firm already trusts.

Keep it light. The failure at the other end is over-building, choosing a heavy platform and spending a quarter configuring it before a single project runs. The register does not need a workflow engine yet. It needs to be central, visible, and simple. The whole method can run on one system later, from problem submission through to sustainment, and that is a move for the scaling chapters, once there is a portfolio and more than one belt to justify it. For now, one shared tool, ranked and visible, is exactly right.

9.3.2 What to record against each candidate

Against each candidate, record a handful of things and no more. The problem in plain words. A rough size, in whatever terms you have. A rough owner, the team or person closest to it. The route the gatekeeper gave it. And a status, which says whether it is running, held, or closed. That is enough to choose from and light enough to maintain.

Keep the language plain. The register is a working record, not a board paper. When a sponsor asks why you chose one problem over another, you open the register and the whole field is there, ranked, with your reasoning visible. That openness is worth as much as the ranking itself on a ground with no track record of method.

9.3.3 The register as the start of portfolio work

What you start now becomes the portfolio later. As you finish projects and the firm matures, the register grows a backlog, a rough sequence, and a rhythm for review. None of that is built at the start. It accretes, one project at a time, from the shared tool you keep alive now.

This is the quiet long game of the role. Each project you run feeds the register as much as it drains it, because every walk and every fix surfaces new problems. Kept alive and visible, the register is the engine that turns one project into a programme.

9.4 Sequencing the first project

Choosing the first project is not only about which problem scores highest. It is about which problem, run first, sets up everything that follows. The first project on an immature ground carries a weight no later project will. It is the firm's first lesson in what improvement is, and the standing you earn from it funds the next one. Figure 9.4 shows the logic of the run.

9.4.1 Visible enough to matter

The first project has to be seen. A flawless fix in a corner no one watches teaches the firm nothing and earns you no standing. You want a problem whose result the board feels, whose improvement the client notices, and whose story you can tell in plain business terms when it is done. Visibility is not vanity here. It is the currency you spend to fund the second project.

9.4.2 Contained enough to win

Visible and winnable pull against each other, and the first project has to be both. Too small and the win does not register. Too large and it never closes, exhausts the team, and proves the opposite of what you intended. The art of the first project is finding the problem that is big enough to matter and contained enough to finish inside a window the firm will wait for.

When the two pull hard against each other, lean toward contained. A smaller win that lands beats a larger one that drags. You can always run the bigger project second, from a position of earned trust, with a team that now believes the method works.

9.4.3 How the first win funds the next

A first win does not just fix a process. It buys you the right to run the next project on easier terms. The sponsor who saw the result gives access faster. The team that lived through it argues less. The board that felt the gain funds the programme. None of that exists before the first win, and all of it exists after, which is why the first project is chosen for what it unlocks as much as for what it fixes.

So sequence with the run in mind. Pick a first project that is visible and winnable. Pick the second to build on the first, in the same area or with the same team, so the gains compound rather than scatter. Three connected wins move a firm further up the ladder than one large project that stands alone and exhausts everyone.

9.5 Placing the Crestline candidates

Return to Crestline. By the end of the first week you had four candidates in the scan log. The complaint resolution problem, a billing query loop, a new-client setup that stalls at one approval, and a weekly report that three people build and no one reads. Now you place them, screen them, and choose the first project to run.

9.5.1 Plotting impact against feasibility

Start with the two lenses that separate the field fastest. Plot each candidate by how much it matters and how readily you can finish it. Figure 9.5 shows the four placed, with the size of each marker showing how controllable it is.

The picture is clear at a glance. The weekly report sits in the easy, low-value corner. It is trivial to fix and changes nothing for the client or the board, so it is no one's first project. The setup delay and the billing loop both sit on the feasible side with moderate impact. The complaint problem sits high on impact and harder to run, because it crosses three teams, but well inside the firm's reach.

9.5.2 The control and data check

Impact and feasibility narrow the field. Control and data settle it. The complaint problem looks the hardest to run, and on feasibility alone the billing loop scores higher. But weight control and data for an immature firm and the reading shifts. The complaint process crosses three teams that all report under the same director, so one sponsor can reach every lever. The data does not exist yet, but a two-week manual collection at the handoffs will build it. Control is high and data is reachable, the two lenses that matter most here.

The billing loop is the strong runner-up. It is contained, controllable, and has more data to hand. It is the safer project, and it becomes project two, run on the standing the first win earns. The setup delay sits behind both, worth doing but not first. The weekly report was never a method project at all.

9.5.3 Why complaints is the first project

Complaints is the first project for reasons the screen surfaces and judgement confirms. It carries the impact, because client churn and board attention both trace back to it. It is controllable, because one sponsor sits above all three teams. It is measurable, once you build the baseline. And it teaches the firm the whole shape of the method on a genuinely cross-team problem, which is the lesson a first project should leave behind.

It is also the problem you were sent for, which matters more than it should. Renu asked you to fix the complaints. Running that as the first project keeps faith with the sponsor while the method does its quiet work underneath, and it puts the headcount assumption Martin keeps pressing directly in the path of the evidence. The first project answers the question the firm actually asked, and answers it properly.

9.6 The toolkit, in the order you reach for it

Four tools carry the selection work. You reach for them in a rough order, and the order is a default, not a rule. The checklist gates each candidate into or out of the method. The screen scores the ones that pass. The grid places them so the choice can be seen. The register holds the whole field and ranks what comes next. Each is shown here filled with the Crestline candidates, so you see the tool used, not just named.

9.6.1 The worthiness screen, scored

The screen takes the candidates that earned the method and scores them across the four lenses. Figure 9.6.1 shows it filled for Crestline, with control and data weighted at one and a half for an immature firm. The scores are rough and that is correct. A screen scored to one decimal place is a screen pretending to a precision it does not have.

Read the weighted column and complaints leads, with billing close behind. The screen did not crown the easiest candidate. It surfaced the one with the impact and the control, and it showed billing as the strong second. That is the screen working as intended, narrowing the field and informing the choice without making it for you.

9.6.2 The improvement register

The register holds the whole field in one shared place, ranked, with a rough size, an owner, the route, and a status. Figure 9.6.2 shows it filled for Crestline. The complaint problem runs first. Billing and setup are held, ranked behind it. The weekly report is closed, sent to a one-step fix rather than the method.

Keep the register live. As the complaint project runs, new problems will surface and old ones will shift in priority. A register that is still being updated a month in is worth far more than a tidy one closed too soon. It is the first thread of the portfolio you are quietly building.

9.6.3 The impact against feasibility grid

The grid is the fastest way to show a room why one project comes first. You met it in Figure 9.5, with the four candidates placed by impact and feasibility and sized by control. It is a selection tool as much as a thinking tool, because a sponsor who sees the field laid out understands the choice without a briefing. The grid argues the case visually, which lands harder than a column of scores.

Use it in the sponsor conversation, not just in your own head. When Martin presses for the headcount fix, the grid shows the whole field and where each candidate truly sits. You are not arguing. You are showing a picture that makes the reasoning plain.

9.6.4 The project selection checklist

The checklist is the gate that runs before the screen. Three questions. Is the problem recurring, with real variation. Can you put a number on the gap. Does the change sit inside the firm and the sponsor's reach. A problem that fails any one of the three does not belong in the full method, and forcing it through wastes the method on work it was never built for. Figure 9.6.4 runs the checklist against the complaint problem.

The complaint problem passes all three. It recurs weekly with wide variation in resolution time. It is measurable in working days against a clear expectation. And it is controllable, because the three teams all report under one director who can act. The weekly report, by contrast, fails the first gate. It is waste to eliminate, not variation to study, so the checklist sends it to a quick fix and keeps the method for the problems that earn it.