y boss called me into his office and asked if I thought Project Indigo could be completed on time.
Strange question. My opinion on Indigo’s feasibility was no secret — I’d told him more than once. Indigo was due to start the next business day. Was he having last-minute doubts? Or wondering if I’d make trouble with his superiors or the new hires?
It felt like being dropped into an Asch conformity experiment. I had estimated Indigo would take five years with a team of seven. The other senior developer and the project manager? Nine months with a team of five.
Even my five-year figure was generous, thanks to the anchoring effect. Every shred of my experience told me it was a multi-year slog, yet surrounded by confident people quoting nine months, I began to doubt myself.
Mistake #1 – The Compromise Trap
Under my boss’s gaze, I suggested a “compromise”: the PM’s detailed schedule said the first module would be done in a month. If we measured progress after that month, we’d know how long the whole thing would take.
That was my first mistake. The problem wasn’t a lack of evidence — Indigo was a reboot of a project that had already failed once. We knew exactly how long it would take.
If my boss was looking for a reason to kill the project, I’d just blown my best chance. Or maybe he only wanted to know if I’d be a “team player.” In a company as internally competitive as ours, that wasn’t paranoia — just experience talking.
Mistake #2 – Not Locking in a Review
I also failed to set a firm, calendar-booked review meeting with clear evaluation criteria. If it’s not scheduled then and there, it won’t happen.
Later, I learned to make post-spike reviews non-negotiable. They led to pivots in some projects and smaller, life-saving adjustments in others.
Still, my partial resistance paid off: the PM and other senior dev ran Indigo, while I stayed on Project Teal — the project Indigo was supposed to replace. Perfect spot: close enough to watch the train wreck, far enough to avoid the flames.
Month One – Nothing Done
After a month, I checked the tracker: zero completed stories. The PM insisted they were on track because they’d “partially completed many stories.”
I pointed out that partially completed work is impossible to measure reliably. He said his “years of experience” told him they’d make the deadline.
I told my boss it wasn’t going well. He said it was “early days” and he trusted the PM.
Year One – Still Nothing Through QA
A year in, not a single story had passed QA. Some tasks had passed QA, but tasks aren’t supposed to be tested alone — they’re part of stories.
Indigo’s stories were massive. In fact, stories were functioning like epics, and tasks were functioning like stories. The estimates? Pre-determined before anyone started.
Using completed tasks (gappy though they were), I built a chart showing Indigo would take eight years. My boss dismissed it: “We’ve learned a lot, we’ll do better this year.” When I asked how long he thought it would take, he didn’t answer.
By this point, canceling the project would have been too embarrassing. I don’t think anyone expected to meet the deadline. They wanted the project approved and assumed “few months” of overrun would be fine. It turned into years.
Year Two – Scope Games
Real scope dropped (low-priority features cut), but on paper scope increased as hidden work surfaced. New stories were added.
Management panicked: No more new stories. No more splitting stories.
This, of course, made stories even bigger and harder to push through QA.
Year Three – Reality Check (Sort of)
Management reversed course: Split stories, re-estimate to real values. The backlog improved, but stories were still too big. QA remained a bottleneck, and the backlog kept growing.
The PM was now flying in from interstate every two weeks, reputation on the line, venting to anyone who’d listen. The original team, except him, was gone.
The Endgame
I left for greener pastures.
Years later, over coffee, the final Indigo team lead told me the ending:
-
Year 5: A prototype was shown to beta customers. They hated it.
-
Year 6: Project Indigo was canceled. The dev team was laid off.
My former boss had been right — there was a lot to learn from Indigo. Unfortunately, the lessons didn’t stop after Year One.
Final Thoughts
Most of Indigo's problems I have seen to a lesser extent in other projects. However the words "lesser extent" are doing a whole lot of work in the previous sentence.
There was one difference that was a difference of kind rather than a difference of scale, one mistake that doomed Indigo from the very start. A mistake that caused many of the other problems.
Mistake #0 – Letting Politics Determine Estimates
There were other projects were I was pressured to reduce my estimates, as if re-estimating would change the real completion time. There was only one project that I have ever been on where I was given the estimate I was supposed to come up with before hand.
Related Posts
- Have the Courage to Speak
- Never Ask for Feedback You are Not Willing to Listen To
- Making Work Actually... Flow
No comments:
Post a Comment