19 January 2008

PM Methods in context (of Perrow's model)

Recent conversations about project management methods called to mind Perrow's technology model. Technology needs to be appropriate to the degree of complexity inherent on the problem you are facing and the maturity of the subject area domain.

I wonder if this placement of project styles fits the model? Readers, what do you think? Does this work or not?



  1. I'd swap Agile and Waterfall because I think Complexity arises when there are "many exceptions" as defined by Perrow's model.

    I think with light weight processes will allow you to better handle exceptions that you find as you develop the system. Exceptions which cannot be thought of and handled upfront.

  2. Akshay,

    I was wondering about that. But the larger programmes and projects are the ones that have the greatest amout of risk for the business if they fail.

    As a result I would think they wuld be less inclined to go down an agile path for these projects.

    Do people run 12-18 month agile projects?

  3. :-) So two of my last projects have been 12-18 month projects. Of course, with many internal releases. They have also been mission critical to the client.

    The point I want to make is that the duration of a project OR it's criticality has less to do with it's complexity. I think complexity has more to do with flexibility in terms of handling exceptions.

    So consider a project to be done for say NASA... critical, large, technically much more complex than average projects, but doesn't have many surprises in terms of what needs to be done. I wouldn't exactly push for agile on such a project. The type of complexity in this project (technical) cannot be helped by using a different methodology.

    But for a business critical project where the client needs a product out into the market with that particular "killer" feature, as fast as possible, I'll definitely push for agile. Sure there are other features to be built, bells and whistles to be added and that can happen for as long as required, but... after the killer release.

  4. I know what you mean. Maybe compelxity and capability are the wrong dimnsions.

    By the way, on the topic of NASA type projects, I am sure they are full of uncertainties and surporises also. You can actually read about project management in that type of environment at Glenn Alleman's blog Herding Cats.

  5. Hm, a diagram I often use has the following dimensions:

    How much do we know what we need?
    - Do we know what we want?
    - Do we agree?
    - Is it stable or can it change easy?

    How much do we know how to get there?
    - Have we done it before?
    - Do we know what the best steps are?
    - Do we agree on them?
    - Do we know all risks?

    In a High for Need + High for Get there: waterval.

    In a Low for Need, Low for Get there: Iterative/Incremental...

    More interestly I find is that perceptions during the dicussions on approach can vary between stakeholder groups. E.g. one group thinks all requirements are or should be frozen, other group feels they are less stable...

    Hope this helps,

  6. Two thoughts:

    1) I'm inferring that this diagram advocates using Waterfall if the degree of complexity is high and availability of domain knowledge is high too. I would argue to swap Waterfall and Agile with each other. I would want to handle a complex project with Agility.

    2)This picture gives me an impression that Agile/Waterfall are in the same category as Outsourcing and Consulting. I know that it isn't the picture you want to draw, but it gets drawn. It is, again, my understanding that such diagrams are useful when all the four quadrant's consituents belong to the same category. In this case two are methodologies while the other two are business approaches. This is not a biggie though.

    That said, I think the jury is still out on the relationship between level of knowledge and software development methodology to follow. I haven't worked in a pure Waterfall project but it is my assumption that it'd need very highly knowledeable team to effectively complete the project on time since you only have a limited time upfront to design it. Agile, on the other hand can be a little forgiving in that you can build your knowledge up during the entire time period.

  7. Anonymous8:48 am

    The diagram doesn't address one thing - when considering a type of approach it's very important what kind of a customer we have on the other side. It's hard to go for agile when we have a client who doesn't want to cooperate.

    Another thing is we all focus on top two squares. I don't agree with universal "outsource" answer for low complexity/low expertise. I'd start with "learn" although it would be put into discussion (outsource would be one of options of course).

    I think generally the model simplifies thing way too much.

  8. Anonymous9:57 am

    Pawell, it looks like the consensus is with you. I might try to put up Roeland's matrix soon.