Framing the problem

AIM State a problem that is measurable and free of any assumed cause.

A problem arrives as a feeling. You cannot work a feeling. You work a measured gap in a process. The step between the two is the one most people skip, and it is the one that decides whether the project is built right. This chapter is that step.

8.1 Symptom, problem, and cause

A problem reaches you as a feeling. Someone is unhappy, a number is moving the wrong way, a client is threatening to leave. That is the surface, and it is real. It is also not yet something you can solve. What you can solve is a measured gap in a process. Between the feeling and the gap sits a step that turns one into the other, and this chapter is that step.

Three things get confused with one another at the front of a project. The symptom, the problem, and the cause. Keep them apart and the rest of the work stays clean. Blur them and the project is built wrong from the first day. Figure 8.1 sets the three side by side.

8.1.1 What people feel

The symptom is the surface. It is the complaint, the churn number, the angry client, the tired team. It is the reason you were called, and it is loud. But a symptom is not a problem you can work. The phrase clients are angry tells you that something is wrong. It does not tell you what, or where, or by how much.

Every project starts at the symptom, because the symptom is what gets noticed. Nobody escalates a process gap. They escalate the pain the gap causes. So you will always meet the feeling first. The mistake is to stop there and start fixing.

At Crestline the symptom is plain. Clients complain that complaints take too long, and the board has watched churn climb. Renu feels it as pressure from above. Martin feels it as proof the team is stretched. Both are reacting to the same surface, and neither has named a problem yet.

8.1.2 The gap in the process

Under the symptom sits the problem. The problem is a measurable gap in how a process performs. It has a process, a measure, a current level, and a level it should reach. The statement resolution time ranges from 2 to 21 working days against a 5-day expectation is a problem. You can see it, size it, and track whether it moves.

The shift from symptom to problem is the shift from feeling to fact. It is also the shift from a person to a process. Clients are angry points at a mood. Resolution time is too variable points at a process. One you cannot fix. The other you can. That single move, from the mood to the measure, is most of the value in this chapter.

This is the band you will frame, and the only one. The whole of the chapter lives in moving cleanly from the top band to the middle band, without slipping into the third.

8.1.3 The cause you will prove later

The third thing is the cause. The cause is why the gap exists. At Crestline it might be the handoffs between teams, or the intake step, or a system that drops work, or something else again. You do not know yet. You will prove it in Analyse, with data, much later in the project.

The cause is the most tempting of the three and the most dangerous to touch early. Everyone has a theory. Martin is sure it is headcount. Geoff is sure it is the other two teams. Each theory feels obvious to the person holding it. None has been tested.

Hold the cause back. Name the gap now, and leave the why for the phase built to prove it. A problem framed without a cause stays open to the truth. A problem framed around a guessed cause is closed before it starts.

8.2 The assumed cause trap

The most common way a project goes wrong at the front is this. A problem arrives with a cause already attached, and you accept both as one thing. The cause rides in on the back of the symptom, unnoticed, and from then on the whole project quietly serves it. Figure 8.2 shows the trap in its usual form, a sentence that sounds like a problem and is really a solution with a cause hidden inside.

8.2.1 How leaders attach a cause to a symptom

People do not bring you problems. They bring you solutions. We need more staff. We need a new system. We need to retrain the team. Each one sounds like a request for help. Each one is a conclusion that skipped the working.

This is not a failing. It is how people think. Faced with pain, the mind reaches for the nearest explanation and the nearest fix and bundles them together. By the time the problem reaches you, the bundle feels like a single fact. The person has stopped seeing the cause as a guess. To them it is simply the truth of the situation.

You will hear the cause folded into the words. Complaints take too long because we are short staffed. The word because is the tell. Everything before it is the symptom. Everything after it is an untested theory wearing the clothes of a fact.

8.2.2 Why accepting it poisons the project

Accept the assumed cause and every later phase bends to serve it. You will measure the things that support it. You will analyse around it. You will arrive at the solution that was decided before you walked in, and you will have used the method to decorate a foregone conclusion.

The damage is quiet. The project still runs. Tools still get used. Tollgates still pass. But the question was settled on day one, so the answer was never in doubt. If the assumed cause is wrong, and it often is, you will spend months proving the wrong thing, and the gap will still be there at the end.

There is a second cost. When you accept a leader's theory and it fails, the failure lands on the method, not on the theory. The next time you propose a project, the memory in the room is that improvement does not work here. The assumed cause poisons not just this project but your standing for the next one.

8.2.3 The Crestline headcount assumption

At Crestline the assumed cause has a name and a champion. Martin is certain the answer is more staff. He has said it in two meetings. He has a number ready. He is not being difficult. From where he sits, busy people and slow output add up to one obvious conclusion.

Accept it and the project writes itself. Measure the workload. Show the team is stretched. Recommend three hires. Everyone nods, because it is what they expected to hear. And resolution times do not move, because the time was never lost to a shortage of hands. It was lost somewhere Martin never looked.

So you do not accept it. You also do not fight it. You write the problem in a way that leaves Martin's theory standing as one possibility among several, to be tested later like any other. The headcount idea is not banned. It is queued. That is the move, and the next section is how you make it.

8.3 Writing a cause-neutral statement

A good problem statement does one hard thing. It describes the gap completely and says nothing about why the gap exists. It is full of fact and empty of cause. Writing one is harder than it sounds, because the cause wants to creep back in with every draft. Figure 8.3 shows what a finished statement carries and what it deliberately leaves out.

8.3.1 Making it measurable

A problem you cannot measure is a problem you cannot close. So the first job is to attach a number to the gap. Not a vague more or less, but a measure with a unit, a current level, and the level the process should reach.

The phrase complaints take too long has no number. The statement resolution time ranges from 2 to 21 working days against a 5-day expectation has three. A measure, which is working days. A baseline, which is the 2 to 21 spread. A target, which is the 5-day expectation. Now the problem has edges. You can tell whether it is getting better.

The measure does more than size the problem. It settles arguments. When the number is agreed and visible, the project stops being a matter of opinion. Martin's certainty and Geoff's defensiveness both have to answer to the same figure. A measured problem is harder to spin than a felt one.

8.3.2 Pointing at the process, not the fix

The second job is to point the statement at the process and never at the solution. The statement says what is wrong with how the process performs. It does not say what to do about it.

Resolution time is too variable points at the process. We need more staff points at a fix. The first keeps every option open. The second has already chosen one and thrown the rest away. A statement that names a fix is not a problem statement. It is a decision wearing a disguise.

Watch for the fix sneaking in as a verb. Reduce handoffs. Add a tracking system. Speed up intake. Each names an action, and an action implies a cause you have not proven. Strip the action verbs out and leave only the gap.

8.3.3 A worked statement for Crestline

Put the two jobs together and the Crestline statement reads like this. Complaint resolution time ranges from 2 to 21 working days across the three teams, against a 5-day client expectation, measured over the last quarter.

Read what it does. It names the process, complaint resolution. It gives the measure, working days. It states the baseline, the 2 to 21 spread. It sets the gap against the 5-day expectation. It bounds the window, the last quarter. And it says nothing about why. The handoffs are not mentioned. Staffing is not mentioned. No team is named as the culprit.

Read what it refuses to do. It does not say because the teams are short staffed. It does not say by adding headcount. It leaves Martin's theory, and every other theory, exactly where they belong, unproven and waiting. That refusal is the whole craft of the sentence.

8.4 Holding the problem open

Writing the statement once is not enough. The assumed cause does not leave quietly. It comes back in the next meeting, in the sponsor's questions, and in your own thinking when the deadline presses. Holding the problem open is the discipline of keeping the cause out for as long as the method requires, which is until Analyse. Figure 8.4 marks the line. On one side you frame. On the other you prove. The work of this chapter is to stay on the framing side and not step across early.

8.4.1 Peeling the cause off, every time

Every theory that arrives gets the same treatment. You do not accept it and you do not reject it. You peel it off the problem and set it aside as a question to test later. Maybe it is the handoffs becomes a hypothesis for Analyse, not a finding for now. Martin thinks it is staffing becomes another. They go on a list. The list is useful. It just is not the problem.

This is gentle work, not a fight. When Martin raises headcount again, you do not tell him he is wrong. You cannot, because you do not yet know. You say the staffing idea is one of the things the project will test, and you mean it. Then you write it down where the team can see it being taken seriously. A theory recorded as a theory stops trying to become a fact.

You will do this many times. Each handover meeting, each sponsor update, someone will offer the cause as settled. Each time, you peel it off and reframe to the gap. It is repetitive and it is the job. The problem stays open only as long as you keep reopening it.

8.4.2 Separating Recognise from Analyse

The reason for all this sits in the shape of the framework. Recognise frames the problem. Analyse proves the cause. They are different phases, run at different times, with different tools, for a reason. Framing asks what is wrong. Analysis asks why. Collapse the two and you lose the thing that makes the method trustworthy.

When you guess the cause during framing, you have run Analyse in your head, with no data, in the first week. Everything after that is theatre. The real Analyse phase, when it comes, will be shaped to confirm the guess rather than test it. The separation is not bureaucracy. It is the firewall that keeps an early opinion from contaminating the later proof.

So in Recognise you stay deliberately ignorant of the cause. Not because you have no theories. You will have several. But because naming one now would cost you the ability to find the right one later. You hold the ignorance on purpose, as a working state, until the phase built to end it.

8.4.3 Why a pre-baked solution kills a project

A project with a pre-baked solution is dead before Measure. It looks alive. It has a charter, a team, a plan. But the conclusion is already written, so nothing the project finds can change it. The tools become decoration. The tollgates become rubber stamps. The team learns that the method is for show.

This is the worst outcome on an immature ground, worse than no project at all. A firm with no improvement history watches the first project closely. If that project turns out to be a headcount decision dressed in the language of the method, the lesson the firm takes is that the whole thing is a costume. You will not get a second chance to teach the real lesson.

Hold the problem open and the opposite happens. The team watches a theory everyone believed get tested and fail, and a real cause get found and fixed. That is the lesson worth teaching. It is only available to a project that refused to decide the answer at the start.

8.5 The toolkit, in the order you reach for it

Four tools carry the framing work. You reach for them in a rough order, and the order is a default, not a rule. The worksheet turns a feeling into a draft. The template tightens the draft into a statement. The is and is not analysis scopes where the gap lives. Five-why, used with restraint, helps you climb from symptom to problem without falling into cause. Each is shown here filled with the Crestline complaint problem, so you see the tool used, not just named.

8.5.1 The symptom-to-problem worksheet

The worksheet is a short ladder of questions that walks a raw symptom down to a drafted problem. Figure 8.5.1 shows it filled for Crestline. It starts with what people feel, captures the cause that arrived with the feeling so you can set it aside on purpose, names the process the feeling points to, picks a measure, records what the measure shows, and ends with a first cause-neutral statement.

The second row is the one people skip and the one that matters most. You write down the assumed cause, not to use it, but to park it. Naming Martin's headcount theory in row two gets it out of the problem and onto the record. The worksheet makes the parking visible.

Use it in the first framing session, on a whiteboard or a page, with whoever raised the problem in the room. Working the ladder together does two things. It produces the draft, and it shows the person how a feeling becomes a problem, which teaches the method without a lecture.

8.5.2 The problem statement template

The template takes the draft from the worksheet and tightens it into a statement that will survive scrutiny. Figure 8.5.2 shows the seven fields filled for Crestline. Process, scope, measure, baseline, gap, impact, and a last field that names what the statement deliberately does not say.

That last field is the unusual one. Most templates only ask what to include. This one asks you to state, in writing, what you are leaving out. No cause. No fix. Staffing does not appear. Writing the exclusions down is how you check the statement against the trap. If you cannot fill the not-stated field honestly, a cause has crept in, and you rewrite.

The template is also your defence in the sponsor meeting. When Martin presses for headcount, the filled template shows the problem stated cleanly, with his theory logged as one to test. You are not arguing with him. You are showing him a discipline already applied.

8.5.3 The is and is not analysis

The is and is not analysis scopes the problem by drawing its boundary. Figure 8.5.3 shows it filled for Crestline across four dimensions. What the problem is and is not, where it is and is not, when it shows and when it does not, and how much of the work it touches.

The tool sharpens the frame. At Crestline it shows the gap is in the time to resolve, not the quality of the answer. It is at the handoffs between teams, not inside one team's own queue. It shows on complaints that cross more than one team, not on the simple ones closed quickly. That narrows the project to about a third of the volume, the cross-team cases.

Notice what the tool does and does not do. It tells you where the gap lives, which scopes the work. It does not tell you why the gap is there. Reading the handoff pattern as the cause would be the trap again, one step subtler. The is and is not analysis points at a place, not a cause. The proof still waits for Analyse.

8.5.4 Five-why, used only to separate symptom from problem

Five-why is a cause-finding tool, and that makes it dangerous here. Used in full at the front, it walks you straight to a guessed cause and hands it over with false confidence. So you use only the top of it, and you stop early on purpose. Figure 8.5.4 shows where.

The early whys are useful. They carry you from the feeling to the measured gap. Clients say it takes too long. Why does that matter. Because it drives churn. Why is that. Because the time swings from 2 to 21 days. Those whys move you down the symptom and into the problem. They earn their place.

Then comes the why that reaches for the cause. Why does the time swing. Stop there. That answer is what Analyse exists to find, with data, not what you guess in a framing session. The skill with five-why in Recognise is knowing which rung is the last one you are allowed to climb. One why too far and you are back in the trap.