The estimation review
The estimation review was still in development. Integration leaders were in the room, with merger stakeholders from IT and from the business sections those processes served. On the table was a carry-over for two LNG producers becoming one organisation: a set of business functions to be taken from the old system onto the new one.
We were building those functions as SAP PI/PO BPM applications. One inbox would be the front door for every approval. A custom SAP UI5 framework gave the applications their building blocks and their runtime, and it carried the company-wide Fiori UI guidelines. Thousands of approvals, changes and correspondence threads were already running. Each company had its own rules for what a half-finished item meant. The people who depended on those threads were the business sections sitting in the review.
The estimate sized the effort by the functions to be carried. That list was the reasonable one. The business could name the functions. The scope was considerable, and it was not the whole estate, so it looked like a figure a programme could staff and defend. The number came out light. The complexity of the processes already running was not in it. We did not have that information in the room. Nobody had buried a figure to make the programme look smaller. The current state had simply never been brought in.
If we had accepted the list as the work, the January 2018 cut-over would have been planned against a quieter system than the one the two companies actually had. An approval started under one set of rules would still have to finish under the other. A change already in flight would not shrink because its function had a name on the new side. Correspondence waiting on a reply is work, and it does not appear as a line under a function. The people exposed were the business sections who owned those running items, and the integration leads who would have had to explain a date the current state could not support. Missing the look could have cost a great deal. We had no figure for that cost. We had a light number, and a gap where the current state should have been.
The estimate was light because no one had looked.
Back to the current state
Estimating by the functions to be carried is what a serious review does. Each function is something a stakeholder can point to. It can be staffed, sequenced and argued about. The evidence in the room supported that approach. The merger had asked for those functions to move from the old system to the new one. The list was finite. The scope was large enough to matter and bounded enough to feel tractable. A named function is a better planning object than a feeling that the old system is complicated. The people who built the first estimate were protecting the programme from a vague number. A review cannot put into a figure a complexity it has not seen, and the work already in flight was absent because no one had yet gone to get it.
What the list measures is a scope the room can see. What it leaves out is the state those functions are already in. A function name is the destination. The process already running is the part still unfinished, and the unfinished part has rules. One company can treat a half-approved request as committed. The other can treat the same shape of request as still open. Until someone looks at the old system as it is running, rather than at the list of what the new one is meant to contain, that difference never enters the estimate. The number stays light, and it stays light for lack of a look.
The room decided to go back to the drawing board. We would dig further into the current state of the old system, and we would estimate that complexity as close to reality as the digging allowed.
The cost was the calendar. The cut-over stayed January 2018. Returning for the look did not buy a later date. It meant the work still in front of us had to be compressed, a short crunch, so the deadline would hold. The people who had to live with that were the people already in the review: the integration leaders, and the merger stakeholders from IT and from the related business sections. What moved them was the cause they could now see. The functions were named. The number was light because the current state had not been brought in. A cut-over planned on the smaller number would have been a promise the running system could not keep.
Smaller than the room feared
We had not reached a production deployment of this scope. The review sat earlier, while the work was still in development. The decision met the schedule before it met live users. The question in front of us was whether the January 2018 cut-over could still be described honestly and still be met.
We went back to the current state of the old system and estimated again, closer to the complexity that was actually running. The first number had been light because the information had been missing, and that was what had to change. The second estimate carried the running work the first had left out. To keep the date we compressed the remaining work into a short crunch. The crunch was not a wider ambition, and it was not a new list of functions. It was the same carry-over, now priced against the system the two companies were already using.
The crunch sat with the seniors already on the team. They caught up. Once the current state was known, the decisions that closed the gap were not as hard on them as the light number had led us to fear. Those decisions stay with the people who made them. What I can stand behind is the result they produced. The remaining effort was absorbable by the seniors we already had. The deadline did not slip.
Two things came out of that, and only one of them matched what the room had braced for. We did not arrive at the cut-over still surprised by processes that were half finished. The discovery had been paid for earlier, in the second estimate and in the compressed weeks. The other fact was the one I had not assumed. After the look, the catch-up fitted the people already on the team. The fear in the room had been larger than the work required to close the gap. The date held because the estimate had been repaired while there was still time to repair it.
A light number has a cause
The estimate was light because no one had looked.
A function list tells you what has been agreed to move. It does not tell you the condition those functions are already in. Lightness means one of two things, and a review has to know which. Either the current state was brought in and the work really is that small, or the current state never entered the room and the number is light for lack of it. The second is what we had. Naming the functions, staffing them and defending them were all still the right planning habits. They were aimed at a figure that had not yet earned its size.
This stops being true where there is nothing hidden to find. When almost nothing is in flight, or when work already running can be abandoned and nobody owns the loss, the function list is the right estimate. A light number there is an honest number. Insisting on a dig through an idle system only spends the calendar you were trying to protect. The opposite choice is the right one in that room.
The test, in the next carry-over review, is one question. Can anyone name the processes already running, and say whether their complexity is in the estimate? If they cannot, the number is light because no one has looked.