Contingencies

In my previous posts I wrote about the elements needed to devise an effective plan, to anticipate problems, prevent their occurrence, and to deal with them if they occur.  With everything in place, nothing over looked, everything should run smoothly.  There is a good chance that will happen but there is the chance it will not.

Even though you have everything covered there is the possibility that something could happen that could hamper your progress.  The situation or event could be within or outside of the process or the design.  Either way it could be something that is beyond your control.

So far, the procedures I have written about, for the most part, have been reactive. Something adverse happens, we deal with it.  The only proactive procedure I have written about was anticipating problems and taking measures to prevent or quickly rectify them.

There is, however, a situation that I have not written about that we tend to take the reactive approach to.  That situation is when a feature of the product, service, or process being designed simply does not work.  As I said, the reason could be external to the system and / or beyond your control.  What do you do when that occurs?

There is only one answer; change it or replace it with something that does work.

Anticipating possible problems and incorporating measures to prevent them is a proactive action.  Redesigning a feature when you discover it doesn’t work is being reactive but it doesn’t need to be that way.  You can proactive about it. It starts with you asking yourself the question, “what if this doesn’t work?”

I always ask myself that question throughout every step in the design process for the following reason.  If the reasons for it not working is completely beyond my control then that feature will have to be replaced by one that will work.  That question then results in the following question, ‘what would work?’  That subsequent question, in turn, produces the need to devise a backup idea or plan.  Initially the backup idea does not need to be detailed.  It should just be an outline but it will set the potential requirements for resources and thus their identification.

If it is discovered that the feature will not work then a baseline alternate will have already been devised.  The resources for this alternate will have also been identified, therefore, considerable time would be saved.  It could be argued that time was already spent devising the alternate plans, so no time was saved.  While it does take time to create them, overall time would still be saved.  Take into consideration these alternate plans would be initially just a basic outline and they would be conceived concurrently whilst you were working on the details of the original idea, therefore, very little extra time was used.

I have experienced instances where a feature did not work. Management then became rather concerned about a schedule slippage. I would allay their concerns by presenting an alternate feature with it’s resources already identified. Since it’s outline and resource requirements have already been defined then there should not be any appreciable or no slippage to the schedule. Had I not already thought of an alternative feature then there would likely be a delay in the schedule.

So, does this technique save time? Definitely. It also reinforces confidence in the team and within it. You should also keep in mind that this technique is not just for individual contributors. It could also be used in the various aspects of management.

Until the next time!