|Slow down (in development) to go fast (in deployment and production). Local experience gives example to this point and might provide insight to the many of use trying to develop and deliver value at speed. (Boston Globe article and white paper).|
The Massachusetts Bay Transportation Authority (“MBTA”) is under fire. New subway cars, meant for the T’s Orange and Red lines are being delivered late and underperforming from Chinese state-sponsored vendor CRRC.
Easy explanation: bureaucratic incompetence, perfidiousness by the foreign vendor, etc. More likely, both CRRC and MBTA had reason to get into operation as quickly as possible. Consequently, they didn’t recognize how much more developmental work had to be done–tailoring the product to Boston area use, debugging a new, in-state production facility, training more deliberately the new workforce.
In a rush to “get on with the real work,” they each short changed the capability building necessary to have operations that run silky smooth. To go fast, they went to fast (when they shouldn’t have), and so are going too slow now.
The alternative: go slow (allow time to do the active experimentation development) when capability is being built to go wicked fast when systems are actually on line.
There are lessons for both vendors (to bid with developmental time built in) and buyers (to realize that before thinking in terms of dollars per unit they have to budget for ideas per hour).
The Boston Globe’s Adam Vaccaro wrote a piece about this situation, “Long before pandemic, problems mounted for new Red and Orange line cars.”
I’ve written a longer thought piece exploring this distinction between developmental and routine-production modes. <–click to download.
Looking forward to your feedback and comments.
PS: Check out our See to Solve systems, portable andons and virtual processing mapping tools to make the hidden visible.
Down load “Getting the T Back on Track“