≡ Menu
Pawel Brodzinski on Software Project Management

We Don’t Need No PM Methodology

As regular readers of Software Project Management probably know I don’t evangelize any specific project management or software development methodology. Depending on a project, its size, external constraints and business environment the best choice can differ from very flexible approach to formalized heavy-weight methodology. Or maybe no methodology at all.

No? Not at all? Am I crazy? Well, when I’ve checked last time I was still sane.

Every process you formalize, and agile methods are formal too, brings some additional hassle which you need to deal with. Nothing comes for free. You get better control over process and raise your chances of delivering on time something your customer expects, but your team spends time on meetings, documentations, analysis, requirements, you-name-it.

Are there projects which can do without any formalized project management? There sure are. Talking about software the only part which can’t be cut out is development. Project management isn’t on the list. Heck, you can produce a piece of software even without designing and testing.

OK, what kind of projects am I talking about? Most of tiny-sized projects. At least these which aren’t mission critical applications. If you have a single or a couple of developers you don’t need much formalism to organize their work. It’s much better idea to let them code for as much time as possible. If you don’t have formalized organization as a client you won’t have an external driver to bring a formal process either.

Another group which doesn’t need any project management methodology is a big part of R&D projects. It’s like focusing on a journey not on a destination. There’s no deadline written in the stone. There’s no list of requirements to meet. There’s no impatient client over your head. When a group isn’t very big you don’t even need to organize their work in any way. Famous Google 20% projects aren’t managed by project managers and that doesn’t make them unsuccessful.

Sometimes we tend to think project management is indispensable in every project, but the truth is a bit different.

in: project management

10 comments… add one

  • Glen B. Alleman February 5, 2009, 11:27 am

    I spoke Tue and Wed at Carnegie Mellon Universities Masters Program (project management sessiion) on the topic of "what are the themes of managing ofwtare development projects?
    One speaker was from Pay Pal (Google) describing the Scrum approach – very interesting.
    My talk was on the questions a project manager needs to ask and answer.
    > Are We Done?
    > When will we be Done?
    > What will it cost when we are Done?
    > What does Done look like for the customer?
    > How can we recognize Done when it arrives?
    > How can we be sure we can get to from here Done?
    > What are the impediments to getting to done?
    If you answer these questions in credible way, then you have a project management method. Whether it has a name or not probably doesn't matter in principle, since you're performing the practice of PM.
    The formlizaition of the process is not for you the PM. It is for others. Others to follow, others to assess, others to reuse.
    I challenge the R&D management though. Unless you're spending your own money, someone what's to know what you've done with that money, why they gave it to you, and when you're going to produce soemthing – even if it is a journal paper. In the R&D (pharma) firms we work with they definitely have a PM method, it's focused on R&D, but there is a method to their spending of the shareholders money.

  • Pawel Brodzinski February 5, 2009, 11:49 am

    Thanks for a comment Glen.

    I see the point although that's not something we usually consider as the project management methodology. We think more about what activities we should exercise than how we define Done. You can go with a piece of paper with a couple of requirements and have all the rest in a head of a developer and it would fit your definition. I guess we wouldn't find many people calling that a project management methodology.

    Talking about R&D projects I included only a part of them on purpose. There are big full-blown R&D programs which often need more careful project management than standard commercial projects. On the other hand there are tasks which:
    – are about to check some technology or to develop some low-priority high-potential application in spare time of a group of developers
    – aren't restricted in any way as they're rather a part of company culture than a focused effort (Google 20% projects fits there)
    Then it's hard to define Done, because project-wise goals are vague. The real goal is somewhere else: to learn something, to check feasibility of some idea or to make developers more happy. There's no need to treat these tasks as standard projects because they're completely different.

  • Andrew Meyer February 6, 2009, 7:48 am


    I agree with you. Too often people in the project management profession focus too much on methodology. The last time I checked, there were no PM methodologies used in WWII, founding MSFT or executing 9/11.

    There were clear and compelling goals that clarified what people needed to do and people did what they needed to do. I suppose of someone wants to call having a clear and compelling goal a methodology, they can.

    There’s a saying in America: “he put the cart before the horse.” Personally, I think people who spend too much time agonizing over methodologies are over analyzing the cart when they really should be hitching up the horse.

    They end up with too much cart that they’ve put in front of too little horse.

  • Pawel Brodzinski February 6, 2009, 8:04 am

    It’s always about choosing a right tool to the right job. If you hunt a mosquito you don’t need a machine gun. And sometimes I think people are telling you that their machine gun is the best, no matter which creature you want to hun.

  • Paul Marculescu February 6, 2009, 9:26 am

    I agree with you, Pawel.
    Sometimes, it’s even hilarious to see how one PM insists on hunting the mosquito with the shotgun, to follow your example. I think this happens mostly because some project managers forget they have to focus on the outcome and instead they accentuate on the process, to get the ego pumped up maybe.

  • Pawel Brodzinski February 6, 2009, 9:31 am

    Another reason why it happens so can be a habit. If a PM always worked with projects in the same way it’s hard to change his approach even when the situation differs much.

    I remember when I changed a job once and I came to a completely different environment. I had to change my visions to implement old, well-known MSF since it was irrelevant in that company. Anyway it was an eye-opener for me.

  • Pradeep Bhanot February 9, 2009, 3:47 pm

    Of course you can make the case that many projects are too small or too big to justify project management involvement. However, I for one like to be able to see the big picture of cost, progress and activity. Before my last employer started reviewing all patch requests and involving the project manager, we repeatedly missed deadlines because of this ‘invisible’ workload.

    One way to handle it was to only make the core developers 70% available, another way was to dedicate individuals to maintenance, while the new important project retained dedicated talent. Having too much invisible work will impact your ability to keep on-track with deadlines for your more strategic projects.

    As for those large architectural changes, the only sane way to make those changes is to phase them in incrementally. That way, they do eventually get done and you can track the investment against potentially competitive or supporting objectives. A by-product of tracking projects is that it demonstrates to your project teams that the team can simultaneously handle operational and strategic demand, which should increase morale and retention.

  • Pawel Brodzinski February 9, 2009, 5:02 pm

    I wouldn’t go that far saying a project can be too big to justify project management.

    I don’t say you shouldn’t manage a team at all. If your team is doing a couple of big projects and in the meantime you have a few small tasks to do (e.g. patch requests or change request as we used to call them) you won’t be able to succeed if you don’t plan these small projects in any way.

    If your team is 100% loaded with big projects you either won’t complete patch requests or will have a slip in main tasks.

    However if you’re lucky enough you can spend one of your experienced developers to work on small tasks only you probably don’t have to manage this project. Or do you?

    Of course when estimating tasks one should never assume that resources will be available 100% of work time. There will happen something unexpected or a developer will have to help his colleagues or discussion in the kitchen will be so fascinating it will take a couple of hours. Anyway with patch request you most likely has your estimates already agreed with the customer so the thing you can (and should) do is to verify whether your estimates were good and adjust them another time if needed.

  • galleman February 10, 2009, 3:45 pm

    Independent of the project type, its size, its duration – I woiiudl conjecture that the questions I posed need to be answered by the project manager or anyone playing the role of a project manager (Scrum Master)

  • Pawel Brodzinski February 11, 2009, 12:20 am


    In vast majority of cases yes. Maybe even in all of them. Even when there's no scrum master or anyone else playing the role of project manager. But you can get answers like that:

    > Are We Done?
    – Nope.

    > When will we be Done?
    – God knows. We've planned for 9 months and it looks like we're going as we planned but it hard to say for sure since it's still impossible to do any end to end test with any hardware.

    > What will it cost when we are Done?
    – Amount of time spent on the project multiplied be the salary of a developer working on it.

    > What does Done look like for the customer?
    – There's hardly a customer for that at the moment. Actually when there is a customer they won't see any functional difference between current and future application behavior.

    > How can we recognize Done when it arrives?
    – We'll be able setup our application in specified scenarios on a Linux machine (instead a Windows one)

    > How can we be sure we can get to from here Done?
    – We can't be sure. That should be feasible as proper analysis was done, and technically we see no blockers at the moment. However as we learned from the history vendor of our hardware doesn't always support each function on both platforms.

    > What are the impediments to getting to done?
    – At the moment none.

    And for me in specific environment:
    – It's a good plan
    – You need no project manager or project management methodology whatsoever to complete the "project."

    And yes, the example is real. Work was completed successfully and on time. I wouldn't say we had a methodology supporting the process. Answers to your questions were in our heads although no one asked them loudly to make it more formal/proper/whatever.

    If you asked Google or 3M engineer working on her 20%/15% project what's her project management methodology she'd answer "none." If you asked her your questions she'd be able to answer them although answers would be probably as vague as in above example. That doesn't mean it's managed poorly. Management is proper to its size and maturity.

Leave a Comment