Documentation and Rework

Once, a long time ago, I worked at a company that was having some difficulty coordinating their development work.  The product that was produced was a complex arrangement of mechanical and electrical / electronic systems.  The company was ISO certified and had documentation describing how they would work, including configuration and change management.  Funny thing, though this company shows major signs of a configuration and change managements system that routinely does not work.  For example, a previously agreed upon solution iteration constituent parts show up, and the parts are then put together to make the product.  However, the parts do not fit together and obstruct other parts in the system.  The typical symptoms look like:

• extensive and costly rework over the interfaces represented by the departments
• extensive and costly rework at supplier at the last minute
• inability to put sub-systems together to make the entire system function

Documentation and Organization Performance

When we take this to the person in charge of the ISO processes, they indicate there is a configuration and change management process defined and that it is followed.  We provide him with the evidence to the contrary and once again cite the documentation.  Yet the evidence, multiple geometric collisions with parts that were designed to fit together and costly rework to the contrary.  To quote the Grateful Dead, it’s even worse than it appears since each of the subsystem developers model their subsystems in CAD in a way that would allow the constituent parts to be put together allowing a virtual vetting of the system. In other words, we should have few surprises when we put the parts together – yet here we are with plenty of rework.  The problem; the models are not updated, and during virtual builds some aspects or portions of the models are not included in the build.  This provides yet another example of a good tool not used appropriately and providing a false sense of security.

 Documentation and Work Instructions

Work instructions do not mean the process is performed as your paper documentation says it should be.  Rules and processes don’t keep you from doing what you want to do; rather, they keep you doing what you need to do or should do.  Management is complicit in these acts because a lack of regimen means it is possible to deliver hurdle free and quickly. Never mind that the delivery is impaired, frequently missing key features, or over cost and has post-launch quality problems.  I am sure that is what happened in the health care website boondoggle.  By the way, this is not only true for IT and agile, but it is also true for conventional project management as some companies turn their nose up to a by the book approach and cut many corners then wonder why quality is poor, costly rework and late deliveries and there are numerous expensive campaigns and recalls.