Blog
Archive →Hundreds of thousands more and six months late, because the client changed leaders
The blueprint was signed and development was under way when the client's new leader wanted his own way. Why the signature didn't hold, and the two things I'd now settle at kickoff and sign-off.
When the shop floor and the system clash, why is it always the system that gives way
Once the hardware is in, almost every clash between the floor and the system ends with the system changing. A new series on 12 real changes, and three threads that keep coming back.
Every plant says it's special. Build all of it and you end up with one system per plant
Six common kinds of customization; printer drivers are the most forgotten. If standard config can do it, it isn't custom. Too much ends in one system per plant. Agree it upfront and sign it off.
Development estimates rarely blow up on the hard features. They blow up on the parts you don't control
Requirements come from the blueprint, explained before coding. Estimates are split by function; equipment, third-party and vendor work is listed apart. Four test rounds. New requests go via the PM.
When a blueprint review turns into a round of Q&A, the problem is rarely the design. It's the jargon
Research with key users and the factory layout. Six parts per business area. First review rejects missing reverse flows; final review stalls on jargon. Changes after sign-off get signed again.
The page in a project proposal that needs the most detail isn't the solution. It's "assumptions and preconditions"
Eight things to lock at kickoff. The one most often missed: no limits on what scope changes and delays cost in time and people. Write it into assumptions, name who decides, list deliverables.
When a project only moves when pushed, the problem is rarely the project team. Nobody on the business side decides
A project team has three parties: IT, business, vendors. Five signs it is stuck, each deeper than the last, and the fix for each layer. Plus what to do when vendor staff leave or fall short.
Project delays never happen overnight. They pile up one weekly meeting at a time
Two risks show up most: schedule and cost, both rooted in requirements. Watch three milestones, split go-live prep into six layers. When a delay is coming, warn in writing, then check daily.
When system acceptance won't get signed, the problem usually isn't the system
From go-live to acceptance: one line first, trial orders from few to many, then full switch. Five metrics, thresholds set at kickoff. Most stalls: no criteria, scope creep, new leader.