Techn@gerial

There are many things in life, day to day, that we take for granted; especially in the developed world. Clean water, available energy, medicine, longevity, the list is enormous. However, when one of these "certainties" is disrupted, for whatever reason, the impact can be quite disastrous. On the whole, disruption to these mostly (seemingly)mundane amenities is quite rare, but to those that are impacted, see New Orleans storm refugees, Gloucestershire flood victims and New Yorkers during their prolonged power outage, these outages of normal function are extraordinarily disabling.

On a more personal level, the day to day can be thrown into disarray by a mere or inch of snow or a flat car battery. Depending on your personal circumstances, the things you take for granted are only really evident when they are momentarily, or sometimes permanently lost. Clearly a software project lesson is upon us…

Quite often the things that disrupt any schedule the most are the mundane things we take for granted. Availability of resources, accuracy of estimates, understanding of the overall goal or solution. Process is good for collating and distributing a shared vision and is used to effectively automate the human elements of software development. But process is only as good as the circumstances in which it is executed. If instability exists amongst the people or overall vision; or if external influences come to bear on a project it can rapidly encounter issues that are catastrophic to the schedule but are, on the face of them, things that could have been planned for. Hindsight is after all, a wonderful thing.

So what are the things to *not* take for granted to ensure success, or at least survival of a reasonable schedule? How are these factors gathered assessed and mitigated? What measures can be taken, other than arbitrary and unsupportable *bloat*, to offset impact on the schedule? How can senior management be kept content and fulfilled without an enervating amount of contingency being added to each schedule? Planning is key, and that is planning that is based on experience, memories, instinctive opinions of senior stakeholders and contributors, basically, knowledge. Applying knowledge to any situation will always help remove aspects of doubt and educate strategies for dealing with known troublesome areas.

But what about developing new software, new features and services that have either never been done before or are new to your business? Here be dragons, when everyone has an opinion about how complicated and technically challenging it is, and how "easy" and "just" straightforward it must be, after all, how hard can it be? The answer is *very* hard. It is no surprise that staggering percentages of IT and development budgets are spent learning these lessons and dealing with these upfront generalisations and optimisms. We all do it, it is human nature to underestimate the economic (not just financial) cost of undertaking anything new.

Various development methods allow you to slowly bite your way into these situations, which allows for a controlled level of spend and exertion, the only drawback is that these invariably don’t offer a date when the product in all its undefined glory will ship, this makes agile projects hard work to sell to senior management. Waterfall methods that *can* deliver higher degrees of certainty also come at a high upfront price, not just in terms of time but also cost; to learn how to do a thing you need to try and do it to educate how to plan it.

Planning alone is insufficient to create a deliverable schedule, where the dates are cast in stone.  To avoid the flat battery or snowy morning scenario occurring on your software development project, you will need to have a firm and intent eye on RISK, what may go wrong or occur that could impact your ability to deliver?  Often risk management is something that is seen as an operational or in-flight aspect of project management.  It needs to happen before your plans are cast, to educate the level of contingency that needs to be applied to mitigate for risks that can’t be controlled.  A formula or metric will need to drive the risk factors and provide an overall level of targeted contingency that protects your plan from the everyday and exceptional things that can occur.

Tweet This Post