Measure: Get a Baseline Before You Believe Anyone

"It takes about four days." That was the property team's answer when asked how long a fit-out request takes to decide, and the answer was accurate. It was also the least useful number available, because it described the process in the one way that hid nearly everything worth knowing. Before anyone fixes a process, someone has to say how it performs today, in numbers, measured in a way that two different people would reproduce. That statement is the baseline, and the Measure phase exists to produce it. Teams skip it because the process feels familiar and the pressure to act is high. They pay for the skip later, when nobody can prove whether the fix did anything.

Decide what to measure before you collect anything

Start from the CTQ defined yesterday and write a short data collection plan. It answers five questions. What exactly is being measured? Where will the data come from? Who collects it? Over what period? And how will quality be checked? The first question needs an operational definition, which means a description precise enough that two people measuring independently get the same number. For the fit-out example: working days from the moment the tenant submits a complete request to the moment the decision is sent, excluding weekends and UAE public holidays. Every word of that definition is there because someone, somewhere, will otherwise measure it differently.

The data usually already exists in ticket timestamps, email threads or a shared tracker, and a spreadsheet export is enough to work with. Where no timestamps exist, a simple tally sheet kept by the team for four weeks does the job, and it is better to have eight weeks of rough data than none. Cover enough time to include ordinary variation, which means a stretch that contains busy and quiet periods, rather than the one good fortnight someone remembers fondly.

Collect more than the measure itself. Alongside each result, record the factors you suspect might drive it: the type of request, who handled it, the day of the week it arrived. Capturing these now costs almost nothing, while going back for them later costs a lot, and Thursday's analysis depends on them. Finally, check the data before trusting it. Spot-check ten records against the source, look for blank timestamps, reopened requests and test entries, and fix what you find. This is a lightweight version of what Six Sigma practitioners call measurement system analysis, and it prevents the most embarrassing kind of error, where a whole project is built on a number that was wrong from the start.

Reading the baseline: average, median and the share that fails

Here is what the illustrative data showed for eight weeks and 120 requests. The average decision time was 4.1 working days. The median was 3. The longest was 14. And 30 of the 120 requests, a quarter of them, were decided later than the five-day promise. Each number says something different. The average is pulled upward by a few long cases. The median describes the typical request and is a better guide to what most tenants experience. The share beyond the promise is the defect rate, and it is the number to lead with, because it is the one tenants actually feel. "Four days on average" sounds like a team beating its promise. "One request in four misses it" sounds like what it is.

Six Sigma expresses the defect rate as defects per million opportunities, and 30 in 120 translates to 250,000 per million, a little over two sigma on the conventional scale, against the 3.4 per million that gives the method its name. Most service processes sit nowhere near six sigma, and that is fine. For BA work the sigma figure is a yardstick, not a target. The useful part is the habit of counting defects against the customer's requirement.

It also helps to write down, next to the baseline, what the data cannot yet tell you. The numbers say that one request in four is late. They do not say why, which types of request are responsible, or whether the problem is getting worse. Naming those open questions at the end of the Measure phase gives the next phase its brief, and it stops the baseline from being quoted as an explanation when it is only a description.

A summary also hides the shape of the data, so draw the picture. A simple run chart plots each request in the order it arrived, with the days taken on the vertical axis. It reveals things a table cannot: a sudden jump after a staffing change, a steady drift upward, a repeating weekly pattern. A baseline is a number and a picture together, and the picture often raises the question that the number never would.

Why the baseline is also your protection

Months from now someone will ask whether the project worked. With a baseline the answer is a comparison: the late share was 25 percent when we started and it is 9 percent now, measured the same way. Without one the answer depends on memory and mood, and a sceptical stakeholder can dismiss it in one sentence. The baseline also protects you from your own enthusiasm. One good week after a change proves very little, since ordinary variation produces good weeks without any help, and only a comparison against the full baseline range can tell a real shift from a lucky one.

Sometimes the baseline reveals that the process is performing fine. If the late share had come back at 4 percent, the right conclusion would be that the complaints came from a few memorable cases and not from a broken process, and the project should stop there. That is not a wasted effort. It saved a team from months of changing something that was not broken, and it is a result worth reporting. Treat small samples with the humility they deserve, since a baseline drawn from a dozen cases should be read as a hint and not a verdict. With 120 requests across eight weeks, though, the pattern is solid enough to act on, and tomorrow's analysis shows why the average, however accurate, was never going to be enough.

Go out and be successful.

Oluwatosin Ogunkoya · Flotog BA Insights · 1:1 mentoring and coaching for BAs at every career stage · www.flotogbainsights.com

TOMORROW

Analyse and Improve: The Average Is Hiding the Problem - Finding where the failures concentrate, then testing a fix before announcing it.