Are Project Managers Living A Lie?

[A Scary Halloween Article]

“I am going to describe my personal views about managing large software developments… In these assignments I have experienced different degrees of success with respect to arriving at an operational state, on-time, and within costs. I have become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.” – Dr. Winston Royce, 1970 Managing the Development of Large Software Systems

I had a fun 20 minute talk with a VP of Development and a Sr. Program Manager at a DoD facility during my time at AgileDC 2011 this year. The topic was around Project Managers managing projects in a way that is already poised for failure. Are they living a lie?

It has always been eye-opening to many people when I tell my workshop participants or clients that they old waterfall way of doing software was never intended to be used. It was a misinterpretation of Dr. Royce’s seminal paper. What happened was that government agencies read the first page, saw a diagram (with a poorly chosen caption), and said: “Hey, that’s how we do software development!”

Yes, that’s right. Waterfall project management was never the point. It was actually iterative development that Dr. Winston Royce was pointing to… later in his paper. 

How Not To Manage Large Software Projects:

If they had read the second page of Dr. Royce’s paper, they would have found the following quotes:

“I believe in this concept, but the implementation described above is risky and invites failure.”

“Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required.”

“The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.”

Interestingly enough, Manoj Vadakkan spoke about Dr. Winston Royce’s findings this during his AgileDC talk as well, but he wasn’t harsh on Project Managers.

One quote during my conversation that almost flattened me was the following:

“You know, Project Managers should wake up and see that their entire existence is based on a lie. Their work, their management style, and their careers, are built upon a fallacy, a lie, and a management construct that should have never been put out there in the first place. It’s like a cult with millions of followers who, the more they learn about project management theory, are going deeper into failure for themselves and their company.” [Paraphrased by me]

So, what you’re saying is that Project Managers… and project management is like… a cult…


What do you think? I hardly had words.

 [See Dr. Winston Royce’s Full Paper below]

Author: peter

Peter Saddington is an Organizational Scientist and Certified Scrum Trainer. You can find him at

22 thoughts on “Are Project Managers Living A Lie?”

  1. Do you not find it ironic that the concept of waterfall arose by approaching Dr Royce’s paper in a waterfall manner? ie. they read the first page and figured they now knew everything there was to know and proceeded to implement?

    As a 10+ year vetran of living the lie (yes as a PM) … I can attest to the failure of the industry to recognize the failings of what PMs are bringing to the table (ie. I agree with your statements above). As an society and industry we seem to be out to find silver bullets. PMI, IIBA, SCRUM, and all other frameworks are being applied in a manner where people believe they will help them if only applied in a perscriptive manner.

    It’s a shame really. If we were doing our job properly we would be looking for the right balance… regardless of what that might be. We need to start educating people how to think for themselves, and stop thinking we can pick up a book that will save the world by itself … regardless of what domain you might specialize in.

    1. Well said Mike. My take away from the conversation was that we need to be less dogmatic about things. We are problem solvers after all… doing things blindly or without thinking… well, we aren’t paid to do that, are we?

    2. OOOhhh that’s good Mike. A BUFD on the paper, without actually exploring it entirely! How often does that happen?!

      I have two personal beliefs around project management; the first is in general and the second is more specifically for anything that is product-focused.

      1) Project Managers are give a “body of knowledge” that fails to recognize that project context is what needs to focus folks on what to use or not use. Additionally, PMI (and others I presume) say that PMs should be ethical, yet never give any guidance ot what ethical behavior is. There simply is no framework; well I am attempting to provide one with my Manifesto for Project Leadership:

      2) You’ll notice that there is a pre-amble to that Manifesto. Most “projects” create something that will last much longer than the project’s life-cycle. This product (which could be a service) has a longer life-cycle; yet when we think in projects we short change thinking along the full product’s life-cycle. We need to turn project thinking where this occurs into product thinking. (There are still some projects out there, but these are not as numerous as you would think. Couple of examples: advertising campaign and clean-up of a hazardous waste site two that come to mind.)

      1. Just some notes:

        1) Actually PMI does have a code of conduct. It is downloadable from the website.

        2)Interesting; you can say a product is a group of projects + operations work. The latter is more focused on metrics and performance measure of the product itself rather than the resources doing the product. That is why it is better to have both the Project and product in the know, however both should be managed differently.

        1. Yes you are right… As a recovering PMP though, it doesn’t provide the type of focus on people I’d like to see.

          as far as your #2; you can look at it that way, but what I see organizationally is that thinking of ops & maint as a separate function changes your mindset such that you make trade-offs that should never happen. Let’s see I don’t have enough money for this, so I won’t listen to the PM when he tells me that my tech debt is mounting, I’ll handle that when it finally gets into maintenance. I need those last set of features! Oops, don’t have enough money to pay down the debt…

  2. Here project manager is associated to waterfall. I think this is usual comparison. Still I’ve seen scrum master and product owners to be as stick with old models as I’ve seen project managers. So maybe it’s not fair to judge all project managers here.

    Saying that, I think wide variety of project manager are unnecessary. It’s a decease of big companies, where there’s some people who are doing project management, just for project management sake. Project managers or whom ever incolved in projects or iterations must bring some value to the actual end product. Sometimes communication towards stakeholders is a value, but more often it’s not. It even doesn’t matter what’s the methodology used, is it waterfall or agile, still all the personnel have to bring something to the end product. That’s all that matters.

    Sometimes when people are talking about Agile and Waterfall, people are thinking about small software projects. On those you can easily live with short iterations and bythebook type of implementations of Agile. When you start to scale your projects to involve more than 100 persons, you need to have some planning there also. There needs to be limits and scenarios or plans how things get together. And of course there needs to be iterations and lots of co-operation between people. What I’ve seen is that people are talking about apples and oranges when talking about how Agile could save all the projects. Some people are so fanatic about bythebook Agile, that they are incapable of thinking what really adds value to the project and what is not addind. All the things which have some linkage to waterfall are judged as unnecesary. Maybe there could be more thinking on what adds value to the end user than there is about what methodology this refers to.

    And for disclosure, I’m currently in project management/operational role in a bigger company. This is not a defense speech for the role, but

  3. In 1970, coders created 80-column Hollerith cards at card punches and carried them to a data center, where the high priests in their lab coats loaded them into hoppers and scheduled them to be compiled. The next day, the coder would pick up his green bar printout, correct any errors flagged by the compiler by replacing the offending cards, and hike back to the data center. Debugging was accomplished by inserting statements to print messages, and unit testing consisted of requesting the data center to schedule the process. “Tedious” does not begin to describe the process. Consequently, the emphasis was put on minimizing the number of iterations. This was accomplished by highly structured requirements gathering, meticulous design, and “desk checking” the coded cards before submitting them to the compiler. While this process sounds ludicrous today, it was driven by the simple fact that labor was a whole lot cheaper than CPU cycles, and analysis and design took less calendar time than code and test.

    Now skip forward four decades. The economics have been completely inverted: high-quality packaged software is widely available, much of it free, and CPU cycles are essentially free. Computers are imbedded in every device, and the average smart phone has more computing power, storage, and memory than the IBM 360 Fred Brooks spoke of in “The Mythical Man-month.” We talk about “consumer quality interfaces” as the new standard for business transaction-processing systems, and keyboards are being abandoned for tablet interfaces. The difference is about six orders of magnitude greater than the difference between a bow drill and a Bic lighter.

    Of course, no one develops business software the way they did in 1970 – the “waterfall” model only remains for safety-critical applications like avionics and similar control systems, and to support vacuous arguments by those who feel the need to contrast their favorite methodology against something obviously inappropriate. Builds are quick and can be scheduled to run several times a day; tests can be run automatically, so even a small change can be thoroughly regression tested while the developers are eating lunch. Users demand active involvement in the design of the human interface, in order to minimize time to use an application, and time to learn has to be essentially zero. It’s more cost-effective to use an iterative approach, involve the users throughout, and use cheap technology to replace far more expensive labor. So that’s what nearly all of us do, using one approach or another.

    We don’t need to contrast Scrum or Extreme methods to what was prevalent in 1970, any more than we need to compare a Honda Accord to a one-horse surrey. We need to find smarter ways to address today’s problems, like the accumulation of technical debt as a by-product of refactoring, or scalability, or survivability. We need better life cycle models for web services, and better approaches to implementing software as a service. Let’s talk about those things, and quit talking about archaic practices like they are an insidious threat to modern society. It’s time to move on, guys!

  4. I think the phrasing absolutely appropriate – and I still find it astonishing that this “revelation” of Royce’s true intent with single-pass/phased delivery is still the exception and not the rule when it comes to learning how to deliver complex projects – IT/software or otherwise.

    In a talk I delivered recently I put it to the audience that we should all be damn upset about the fact that we’ve been “lied” to by well-intentioned folks about project delivery, and channel that into learning iterative/incremental approaches that have **60 YEARS** of successful implementation on hardware and software projects to back them up, not to mentiont the endorsement of thought leaders like Brooks Jr., Gilb, Boehm and others.

    As far as I’m concerned, you’re a fringe lunatic contributing to the morass of project failures, abysmal team morale rates and lowered customer expectations if you adhere to waterfall.

    1. OK, so name three U.S.-based organizations developing application software using the waterfall “method” described on page one of Royce’s paper, exclusively, other than for avionics or similar systems where loss of life is a consequence of a software failure. Who are these “fringe lunatics” you speak of, whose archaic practices are a threat to modern society?

      1. I can think of several US Federal Government organizations that use waterfall exclusively… If we extend this to the contractors supporting the Government, it expands exponentially.

  5. Theoretically, a PM can be an enabler .. it is just that it was acceptable to have the PM do a one man show before. But the correct way has always been through enabling the rest of the team.

    And we always had iterative development, the things Agile focus on in m opinion are dropping the over-documentation, more focus on work, communication and shorter iterations.

  6. actually it’s true.. some project manager even thing they their best.making own software much faster then in a company because stupid politician.Wee need solution to solve and to ease lifestyle and not some stupid marketing to promise everything to client.

  7. Pingback: Are Project Managers Living A Lie? | Agile | Syngu

Leave a Reply

Your email address will not be published. Required fields are marked *