Software Project Management claims to be a scientific discipline. Google it. You’ll find all manner of shiny websites offering training, toolkits, mentoring, proven best-of-breed methodologies and so forth. The words “Scientific” and “Discipline” will feature extensively in their marketing bumph, along with “Professional”, “Strategic”, “Enterprise” and “Delivery”. It all sounds good. Looks good too. There’ll be nice pictures of well-groomed guys and gals in crisp white shirts and jackets pointing significantly at flip-charts and laptop screens. The body language will be committed, serious and hard-working, but at the same time open, approachable and inclusive. Like this:
Yeah. Lifts the page up already, don’t it ? I could be selling Waterfall to Agile conversion mentoring to the FTSE 350. Mmm. Quality.
What these various types of virtual snake oil salesmen offer is certainty, or rather the illusion of certainty. If you buy this tool, take this course or follow this simple nine-step programme, you will be able to predict the day and the hour at which your code is complete, tested and purring along in live operation, bug-free and stable. Sadly but inevitably, much of what is on offer is balls. It won’t guarantee success, and is about as scientifically well-founded as locating your team under a Power Pyramid festooned with dreamcatchers, healing crystals and an orgone accumulator. To be honest, software development spiritually assisted by large chunks of woolly New Age Mysticism could be quite fun. Is our test coverage thorough enough ? Let’s ask the Tarot Cards. And it would barely get in the way of productivity, unless the aromatherapy candles set off the sprinkler system and you had to evacuate the building. These proper management philosophies are a little more intrusive and dangerous, and tend to have something of the character of a new and slightly disturbing church. Their adherents are fervent in their belief that only (say) Test Driven Development can save your wretched project from eternal damnation. If you wish to use their model, there is a vocabulary to be mastered and a whole new mindset and paradigm(*) to be adopted. There are also curious rituals to be performed and sacred documents to be venerated, all with Capitalised Names To Make Them Seem Important: and lo, in the third week the Domain Walkthrough shall be held, and all those present both physically and via conference call shall look upon the Strategic Reference Architecture and pronounce it to be good. And there is a great deal of bile spilt as zealots of one deviationist faction curse the cherished tenets of another. Big Design Up Front is slammed by Scrum partisans, while PRINCE2 devotees bewail the adolescent Agile cowboys’ lack of rigour. Salvos fly across the blogosphere and a remarkably large amount of self-righteous spleen is vented to very little purpose.
So, we have an array of software doctrines to chose from, each of which is an unholy amalgam of Management Consultancy, Scientology-style Cult and the Judean People’s Front. Organisations will often develop a passion for one or more of these new creeds in a wave of corporate hysteria and / or desperation. This won’t help in getting any work done. but if you are aiming for chaos and paralysis from the off, then there is value to be had. Ideally, buy the full spectrum. Pick up all of the different strains of ill-conceived, contradictory, blue-chip received wisdom you can stomach and embrace them all. Draft a 2,973-node product-orientated work breakdown structure. Produce earned-value charts, burndown charts, PERT charts and Gantt charts. Translate the requirements into UML diagrams and COSMIC function points and a user story backlog and a BRD and an SRS and seventeen other varieties of alphabet soup. Cross-reference the lot against a quad-A0 entity-relationship diagram and the Zachman framework. Invent your own project artefacts – seven-dimensional extended requirements traceability matrix, anyone ? – and take it all deadly seriously.
This is gold dust and will knacker the job in all sorts of ways. First off, it will take months to produce the Baseline Architectures, Terms of Reference, Initiation Portfolios, High-Level Designs, Programme Visions, Governance Overviews and so on that are all apparently essential before a single line of code is written, according to all the genius management theories you’ve just signed up to. Secondly, as you’ve brought at least six mutually antipathetic and conflicting theories into your workplace, there’ll be infighting as to which bits apply in which circumstances, and this will add in further months of delay. Thirdly, when work finally does start, the team will be compelled to spend most of their time performing the multitudinous ceremonies which are demanded by the various rule books, manifestos and philosophical set texts. So much time will be spent contemplating, reviewing, documenting and reporting on progress that very little will actually be made.
So, to finally return to the proposition that Software Project Management is a Very Serious Scientific Discipline. Not Proven, I would say. The thing about science, see, is that it does useful stuff, and it bases what it does upon evidence and logic. Rather than verbose, polysyllabic, banal, excruciating, pointless and intellectually unsound bollocks. But considered instead as a new fringe religion, splintered already into dozens of heretical sects, Software Project Management ticks all the boxes and stacks up rather nicely. Amen.
(*) Paradigm. No, I don’t know what it means either. But the nub of it is there’s always a new one, and it’s essential you get hip to it right away, and the old one was rubbish.