While reviewing the material to be used at the kickoff, we noticed something.Promises written with good intentions had crept in, in several places.
There is no malice. If anything it is sincerity. We will report thoroughly, we will respond immediately, we will manage in fine detail. While writing it, you believe that is the road to trust.
This instalment is the story of cutting those promises.
We brought promises heavier than the contract back in line with it.
The largest was the promise about reporting.
The contract stated “once a week, satisfied by reporting at the regular meeting.” The material, however, said“a report will be sent by the day before the regular meeting, together with the status of budget consumption”.
A promise heavier than the contract. And it is written in the belief that heavier is kinder.
We reviewed this.Weekly, report progress, issues, decisions and next week’s plan at the regular meeting. Report budget consumption monthly.However, the moment an overrun becomes foreseeable, tell them that week without waiting for the monthly report.
We did not thin it out.We lowered the frequency and, in exchange, promised to surface bad news early..
An arrangement to produce every number every week is certain to become an empty ritual. It becomes work for the sake of work, and the time to write the report is subtracted from development. And the one thing that matters — “we may go over budget” —does not stand out inside a routine report.
We deleted operating rules that would not hold, in advance.
From the same standpoint, there were other things we cut.“We will respond within one business day.” “Issues will be managed one by one.”That sort of thing.
Some days you can. Some days you cannot. Andthe one time you fail to keep it erodes trust in everything else.
A promise should be written at a level you can keep even in a busy week. Exceeding it can be shown in the actual record; it does not need to be in the material.
We took the word “freeze” out of the material.
We fixed the wording too. Where the material said “requirements freeze,” we replaced it with“confirming the requirements (your approval)”.
The meaning is the same: from a certain point, changes are placed under control.
But when the word “freeze” comes out in a room where the people who do the actual work are present, it lands differently.It rings as pressure — as “you will no longer be allowed to say anything.”And then the requests they really wanted to raise stop coming out. Requests that never came out do not disappear; they come back after the thing is built, as “this is unusable.”
“Confirm” conveys that the purpose is to decide.If the control is the same either way, choose the phrasing that makes requests easier to raise.
We even matched the fonts in the material to the other side’s environment.
A small matter, but in this period we also replaced every font in the material.
Our material specified fonts that exist only in our own environment. Opened in the customer’s environment they are substituted with something else, andthe character widths change and the layout breaks.Looking into it, the customer’s material was built using only the standard fonts of a common environment.
So we unified the whole document set to fonts that do not break in that environment. We replaced more than 400 font specifications and confirmed that none remain.
When material displays broken, what gets across before the content is“they did not check our environment.”Losing points before anyone judges you on substance is a waste.
We settled the approach at this point too.
And at the end of this period we settled the development approach itself in writing. How issues are registered, who holds work at what granularity, how changes are taken in, where review is inserted.
Try to settle it in the middle of requirements definition andhandling the issue in front of you gets mixed up with arguing about the approach.Once mixed, the approach is usually what gets postponed, and by the time you notice, nobody holds the whole picture.
Designing promises turned out to be work AI cannot take over.
What is written in this instalment is not a story of AI making things faster.
If anything it is the reverse.Exactly because implementation got faster, time became available for judgements like these.
How to promise the reporting frequency. Which words to choose. Where to cut promises you cannot keep. This is the work of imagining the other side’s position, andits effect on whether a project succeeds is far larger than any single feature.
Whether you can move the time freed from hands-on work into this is, I think, what will separate approaches from here on.
Next time is the finale: dropping the paper comparison and deciding by measurement.
* The content of this article reflects judgements on our own project. Nothing identifying the customer or the system is included. The form of contracts and reporting varies with the shape of the engagement.
Series “Project Diary” (7 parts)Part 1: 82 fixes to the prototype on the day we won the projectPart 2: Cutting our own company introduction out of the first meeting’s agendaPart 3: Counting what we did not understand and putting it on the tablePart 4: Bringing the prototype closer to the real buildPart 5: Killing “it looks like it worked but nothing happened”Part 6: Cutting promises we could not keep out of the material (this article)Part 7: Dropping the paper comparison and deciding by measurement