Abandon hope, all ye who enter Development Hell
Development Hell, like its Biblical cousin, means many things to many people up and down the project chain.
For those in the planning role, it's a black hole consuming resources and time where voice- and e-mails go forever unanswered and each problem solved seems to spawn a host more, with the end objective never nearer.
For the developers, testers and consultants charged with building the product, it's the no-man's-land of poorly defined, ever-changing requirements and constant moving of goalposts, while they wrestle with the wrong tool for the job.
And for the client and end user, it's limbo; the nagging dissatisfaction with the compromises that have had to be made to balance required functionality with available funds compounded by rounds of acceptance testing that never seem to result in a finished product.
And this is the situation affecting – by some estimates – as many as 66% of large-scale development projects.
For those in the business of IT contracting, the crucial task is to identify the warning signs that a project may be heading for disaster - the deadly sins of the development process. To be useful, though, this identification needs to come early. Recognising problems that originate six months or a year previously in the initial conception of a project will rarely provide an opportunity to wrestle it back on track.
Development Hell, unlike its namesake, cannot be avoided through a good act of contrition; its misdemeanours once committed cannot be wiped from the slate. The only sure answer is for your project to lead as far as possible a blameless life.
So, what are the cardinal sins? Common sense and painful experience reveal most of them: failure to understand current systems and ways of working; failure to understand and agree on the aims of the project; failure to manage expectations and achieve stakeholder buy-in; failure to communicate and share knowledge. And as well as the sins of omission, there are more proactive faults: reaching too high and trying to achieve too much in too little time; selecting tools and technologies on the basis of fashion and hype rather than fitness for purpose, dependability and longevity; imposing a hidden agenda or pet preference on the collaborative effort.
Above all, there's failure to plan for failure; a refusal to ask 'what if?' and know your options in the event of all the likely problems occurring. They sound obvious, they are obvious – but somehow a majority of information systems developments fall foul of them to a greater or lesser degree.
Can project and planning methodologies provide an answer? Certainly they can – these after all are the teachings of experience. However, like the teachings of any faith, while simple in theory they are often hard to implement in practice.
It's easy to see the logical appeal of the Waterfall Method, of PRINCE2, of the Microsoft Development Framework, but not always straightforward to map the clean, clinical process of the textbooks onto the messy, chaotic reality of development. The key is to appreciate that methodologies are models, and like any model they're stripped down to the bare essentials necessary to represent their subject.
Learn to strip out extraneous details and personalities from your project and the fundamental structure will start to show through; a structure that can be described in terms of your preferred project management solution.
To sum up, no-one enters Development Hell unless they choose to be there. The tools and techniques that can steer a project away from the temptations of failure aren't an arcane science or privilege of the enlightened few, they are the simple skills of listening, learning, knowing what you have and what you want.
Above all, make sure you never stop talking to your project colleagues. As a wise man once said, "There are three things that will ensure (project success) – understanding, planning, and communicating – and the greatest of these is communicating."
Here endeth the lesson.