A Rhetorical Question

Several times over the last few years, I’ve seen the same question asked in forums ranging from LinkedIn to various blogs, and most recently, on Reddit: “Is Project Management a skill-set or a profession?” Here’s my answer:

Project manager is a role.

Project management is a body of knowledge, skills, and common practices. It is also the application of that intellectual capital.

Those working in a project manager role who pursue the study of project management and work at achieving competence in practicing it, and expect to make a career of managing projects, while following ethical practices and mentoring others, can reasonably call themselves professionals.

But, project management is not a profession, in the classic sense. Project managers are not subject to malpractice suits, in that capacity. Hence, they are not regulated in the same way as practitioners of a learned profession, such as a doctor or lawyer. The New York State Education Department operates the Office of the Professions, charged with licensing practitioners in a lengthy list. From medical, dental, pharmacy, and related fields, to engineers, architects, and even interior decorators, New York maintains standards for licensing a number of professions. Project managers didn’t make the list. I haven’t checked the other 49 states, but I suspect the story would be similar.

So, how can those who do not practice a profession reasonable call themselves professionals? Because the dictionary says they can: a professional is one “following an occupation as a means of livelihood or for gain: a professional builder.”

Reasonable people can disagree, as can unreasonable people and even disagreeable people. If you are any of these, please add your thoughts in a reply, below.

Received Knowledge, Fanaticism, and Software Consultants

Professor Harold HillBack in the 70’s and 80’s, when I was a young coder, you could generally group programmers into two camps: those who thought that the GOTO statement was evil (including such luminaries as PJ Plauger and Edsger Dijkstra), and those who thought it was perfectly acceptable, when used responsibly (such as algorithm guru Donald Knuth). Of course, by the late 80’s, we were all migrating to object-oriented languages, and the notion of structured programming seemed … quaint. Objects were going to free us from the anarchy of procedural code, just as relational database management systems freed us from whatever-the-Hell we’d previously been tinkering with.

But a funny thing happened on the way to high-quality code: bad coders. Oh, there were always bad coders. We simply pretended that the problem was our choice of programming paradigm, and that Bjarne Stroustrop’s preprocessor would suddenly make lousy C programmers into great C++ programmers.  Of course, it didn’t.  So some other coders-in-denial created Java, with the intent of encapsulating great code into packages that could be called by lesser practitioners. It was an incremental improvement, but it opened the career door to many more programmers. And many of them were also bad coders. IDC recently estimated that there are now eleven million professional programmers in the world, and nearly eight million more that they refer to as “hobbyists.” Not me; not any more. I moved on, a long time ago. I just got tired of repairing the software equivalent of a film by Troma Studios – as one critic memorably put it, “dogshit with sprocket holes.”

“Ninety percent of everything is crud.” Theodore Sturgeon

The rise of Agile methods, as they are now called, began well before the 2001 conference in Snowbird, Utah that produced the Agile Manifesto. Scrum and Extreme Programming were in wide use, even as we were correcting old dogshit code in preparation for the year 2000.  The serious improvements came from XP’s pair programming and test-driven development. As long as you didn’t pair two bad coders, you got better code, and eventually, better coders. Then came Snowbird, and the Manifesto, and the Agile Coaches. And the obvious Pareto-truth, that 80% of the bugs were being inserted by 20% of the coders, was papered over in favor of Yet Another Salvation Myth.

Instead of focusing on the coders, the consultants wanted us to focus on how we organized, and planned our work. It wasn’t the coders’ fault that their code sucked – it was the way they were being managed.  The words “traditional” and “waterfall” became epithets, used to describe the reactionaries who would have us focus on code quality, rather than methods. The new word was “refactoring,” which sounds less judgmental than “we have to replace this unmaintainable, write-only, dogshit code.” Yessir, the real problem was project management, and (lately) this fixation on providing cost and schedule estimates. And all of these proof-free assertions fed on each other, until it seemed like you weren’t a real Agile coach unless you dismissed project management, not just for coders, but for all human endeavors. I recently had the temerity to say I wouldn’t want to fly in a commercial aircraft designed using Scrum, and was tut-tutted by a True Believer who reminded me that many modern software practices have their roots in auto manufacturing practices. Not “design,” but “manufacturing.” Egad, have you even read The Scrum Guide?

So I got quite a chuckle this morning out of Nick Pisano’s rebuttal to Neil Killick’s recent expansion of the War on Management, demonizing the “traditional” software contract. It’s bad enough that Neil and his fellow Accusers insist that any approach they don’t like is “command and control;” now they’re going to prepend “traditional” to software contracts? Intolerable! Nick shredded Neil’s assertions, admirably. I was still laughing when I sat down to write this, late in the evening.

To be clear: I embrace the values in the Agile Manifesto, as do most software project managers. I embrace Scrum, as an effective method of organizing small teams of software developers to deal with uncertainty. I follow Neil’s blog, and Tobias Meyer’s, and several other Scrum-lord blogs. They know a lot about Scrum, and modern methods. That they are wrong about other things is immaterial. I have no problem with them dispensing received knowledge and calling it science. Of course, I feel no particular sympathy for the lousy coders who find affirmation in their anti-PM blather, nor for their more skilled colleagues who enable their inability by cleaning up after them. As long as the ratio of chaff to wheat is tolerable, I have no objection to separating them.

But I fear that, until the competent software developers address the real problem – bad coders – we will still be fixing dogshit code, under one procedural name or another, for a very long time to come (“Technical debt?” Coder, please …). And since I am a project manager, I have to point out that these competent coders are thus assuming a risk they could easily avoid, if only they weren’t in denial.

New PM Articles for the Week of March 3 – 9

NewsboyNew project management articles published on the web during the week of March 3 – 9. We read all of this stuff so you don’t have to! Recommended:

Evolution

  • Cheri Baker explains why most of her consulting customers are social enterprises (and why that’s really cool).
  • Linky van der Merwe examines PMI’s recent survey on the global growth of project management to understand what it means to us practitioners.
  • Peter Taylor expands on a statement by J. LeRoy Ward regarding the ever-evolving practice of project management.
  • Susanne Madsen exhorts us to become project champions.

Risk Management

  • Steven Levy follows up on his series on risk management, with recommendations on how to apply the principles he described to a legal practice.
  • Andy Jordan continues his series on managing risks across the organization, through collaboration and common processes.

PM Best Practices

  • Glen Alleman takes the point of view of the people who pay for a software development project to explain why estimates are needed.
  • Henny Portman summarizes the Management of Value approach.
  • Elizabeth Harrin reviews Ann Pilkington’s new book, “Communicating Projects.”
  • Dave Wakeman tells why integrity, adaptability, and judgment are absolutely required by all project managers.
  • Martin Webster tells us how to create a shared vision across the project team.
  • Allen Ruddock explores a tough scenario on managing up.
  • Michael Nir exposes the basics of stakeholder management, as told in a children’s book.
  • Brett Beaubouef shares a technique for conducting an organizations fit/gap.
  • Jennifer Lonoff Schiff collects twelve suggestions from data management and disaster recovery experts on how to design for data survival.

Complexity

  • Shim Marom describes the Cynefin model for problem domains, and finds a domain where #NoEstimates actually seems appropriate.
  • John Goodpasture considers alternatives to complexity.
  • Kailash Awati tells the fable of an architect and the conscience he argues with, to tell why you can’t just gather your requirements at headquarters.
  • Matthew Squair explores the evolution of initial designs, from obvious to plainly unworkable.

Agile Methods

  • Kelsey van Haaster unpacks her thoughts about whether making an exception to the team’s Scrum timeline is Agile.
  • Soma Bhattacharya asks whether managers are a benefit or a hindrance to Agile, and explains why a Scrum Master should not be a decision maker.
  • Francesco Attanasio describes what he calls “Scrum Master 2.0.”
  • Adam Zuzanski explores different ways to present information as a burn-down chart.

Podcasts and Videos

  • Mark Phillipy hosts a Google Hangout to follow up on the second PM FlashBlog, Project Management Around the World. Just 54 minutes, safe for work.
  • Peter Saddington shares a recent TED talk by Rosalinde Torres on the three questions that great leaders contemplate in the 21st century. Just nine minutes, safe for work.

Enjoy!