"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

Share this post