project-management
14 itemsHundreds 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.
At acceptance, one sentence from a frontline key user outweighs ten from the project manager
Pick key users by role, plus the logistics planner; senior and willing to learn; in from requirements. Three traps: assigned, transferred, or the only one who knows.
A parts table with 30-plus columns, cut to 8. That is when in-plant logistics started to run
In-plant logistics runs on one table, one row per part. Ours had 30-plus columns nobody could maintain. Cut to 8, each with an owner, the system finally ran.
From SAP to AGVs, everything went live and the line got slower: none of the 8 systems owns takt time
Once every system was live, the floor asked to switch automatic order grouping back to manual. No single system is at fault; each only answers for its own documents.
Your resume says WMS for an automated warehouse? I ask about one field to know if you were on site
A manual warehouse and an automated one look identical on a resume. My dividing line is eight fields — people who can answer have been on site; people who can't have at most read the design.
A system gets bypassed three months after go-live — and it is never because staff resisted it
Say "the floor won't cooperate" and the investigation stops. The real chain has three links — bad item codes, unabsorbed variances, and the fact that you did make them slower.