Why so many PMs fail in IT project delivery?

"Errare humanum est, sed in errare perseverare diabolicum."
(eng. To err is human, but to persist in error (out of pride) is diabolical.)

Seneca

Now & then I re-visit my own idea / statement / opinion to find out that I totally disagree with it today. Actually I don't find it a problem, quite the contrary - only fools keep upholding stubbornly once formulated statement, regardless of subsequent experience and learnings. One of such past opinions goes as follows:

Project Manager doesn't have to be an expert in the industry project is about. Actually, Project Management is an industry-agnostic discipline - one should follow the same practices, use the same tools, measure corresponding metrics for the project to succeed.

What could go wrong? :) Earned value management, risk control, budgeting, clear & well communicated plans, governed dependencies - all this stuff is supposed to work in pretty much the same way everywhere, right?

Now I know (well, not that I've learned it yesterday, it happened years ago) - maybe it's true in many fields, but for software industry projects that's utter rubbish. Non-IT (or even IT ones, but w/o practical experience with software engineering) managers fail terribly when it comes to lead, manage & govern anything that involves software development (& TBH - that's one of the reasons why manager professions gets less & less respected in IT).

Just to make sure we're on the same page - by industry I mean the one the project work is classified to (not the one that will use the work product), so:

  • software engineering project & bridge construction projects are different industries
  • banking software engineering project & healthcare software engineering project are the same industry (software engineering)

Yes, we're special

Why is that? What's so special about software engineering?

  1. Velocity of change - technology, methods, whole context (infrastructure, operations, service management, QA) - they all are not only industry specific, but they also change very rapidly. That makes it very hard (sometimes) to find a common, ubiquitous language, hence different interpretations, too hasty assumptions, misaligned expectations.

  2. Variety & diversity - it's a very spacious industry - data warehousing project, JavaScript UI/UX project, distributed systems project: they all are software engineering projects but the differences are huge (sometimes it's really hard to find a common denominator between them); what is more, each of these types can have several different sub-types (approaches) that utilize very different technologies, tools - in various permutations that sometimes require very different knowledge & experience.

  3. Intangibility & volatility - software is so hard to grok for outsiders (people who never put their hands on code) because it's so non-pecuniary (non-physical) - basic inspection (with smart person's common sense) ain't enough to evaluate its state, maturity, readiness - we can't hold it in hands, sometimes its "boundaries" are too ephemeral to define what's in & what's not, what it consists of, etc..

  4. Multidimensional character - dimensions, dimensions, dimensions everywhere - data VS code, source VS binary, development VS test, customization VS generalization, several -ilities of architecture (maintainability, scalability, ..., etc.) - there are so many valid categories that it's not intuitive to evaluate software using simple, flat scale.

  5. Unmatched complexity - one day I've heard that software engineering is by far the most complex craft available, unmatched even by neurosurgery. Well, what can I say - I agree. It's one of few discipline when amazing happens:

    • you may have been more advanced yesterday than today (even w/o scope change ...)
    • potential regression (as nothing is sealed) - I don't just means work products of the project, but also foundation they are built upon ...
    • work unit X took Y time yesterday, but a very similar one may not even be possible to complete today (or take N * Y time)

Conclusion

All these factors above make Software Engineering totally un-transparent & incomprehensible in eyes of people who've never dug into details. They will be totally lost due to:

  • not understanding the dependencies & delivery pipeline (basic sequence of cause and effect)
  • not being able to properly assess / classify / quantify / qualify risks or problems (& their impact)
  • deepening communication gap between them & engineers - the latter group possesses a precious skill of detecting ignorance & bullshit; needless to say, managers without the credibility won't be respected - quite the contrary, they will be perceived as blockers, obstacles & disturbance

If they apply standard, generic approach that worked well in more traditional discipline of craft or science (more "physical" / "tangible") - they will fail inevitably. What is worse, usually fail without understanding why they had failed ... usually blaming everyone around.

Pic: © sripfoto - Fotolia.com