≡ Menu
Pawel Brodzinski on Software Project Management

Who Is Responsible For Crappy Project Goals?


Recently I started discussion at PMStudent on relation between project manager success and project success. Undisciplined client, lack of control over project and preservation of team were mentioned as reasons to reconsider PM success despite project failure.

There was however one aspect I’ve missed. Project can be delivered on time, on budget and on scope and still bring no benefit whatsoever. How? What you achieve in project depends on its goals. If goals are crappy project will hardly bring any value. It will be a failure.

The question is: who is responsible for crappy project goals?

It isn’t PM who defines project goals and key requirements. Stakeholders do. Does it mean PM shouldn’t actually care what these goals are? Well, not quite. If stakeholders define contradictory goals it’s PM’s job to make the call. If goals are plain stupid or at least look so someone should start discussion about them and PM is a good candidate here.

These are however only the most extreme cases. Most of the time when project fails it is because general strategy was wrong or business goals missed the market or someone went way too optimistic about some results. It is not because goals were simply stupid or no one put any thought on them. Is it still PM’s job to verify that?

Most of the time it is not. I won’t go definite about this one because across different organizations role of project manager differs much. In smaller companies project manager is often a bit of product manager and/or a business owner. Then it becomes completely different story. But coming back to typical situation, project managers usually don’t have full business perspective. They don’t invent business goals – they follow goals invented by stakeholders.

Now, if these goals appear to be rather crappy and project doesn’t yield expected results whose fault is that? I’d say I’d discuss the problem with guys who set them, not with those who worked their butts off to finish on time. You wanted this revolutionary project no one really knows what to use for so here it is. Don’t blame me when it appeared a bit too revolutionary for users.

When perfectly delivered project fails to produce any valuable outcome it isn’t project management fail. You should rather point your fingers at business owners or product managers.

in: project management

6 comments… add one

  • Nick Myers February 17, 2010, 12:07 pm

    Great blog, and great question.

    I believe the role of the professional Project Manager (PM) is to ensure that the objectives, scope, critical success factors, and detailed requirements are captured, planned and delivered against.

    Also, at a fundamental level, in terms of ownership – the project is wholly owned by the sponsor, they are the PMs customer and the PM is simply a role that fulfils certain needs that projects have, he does not ‘own’ the project – ever.

    However, typically the delivery of business benefits/value is a goal of the project and the PM is responsible for delivering the changes required in the organisation to realise these benefits.

    In agreeing to manage the project for his customer, the sponsor, the Project Manager must ensure that all risks are managed, and that covers the risks exposed to benefits realisation.

    If the benefits of the project are not achieved, and the Project Manager failed to identify the risks that prevented the benefit from being realised, then the PM has not done a good job.

    If the benefits of the project are not achieved, and the Project Manager has managed the risk, and therefore the expectation, properly then the project will not ‘fail’. It will conclude in a managed, understood sense that requires no blame to be proportioned.

    It is vitally important that the PM have respect and integrity for everyone involved in the project, users, business owners, product managers, sponsors and other stakeholders. Humans are fallible, imperfect and easily distracted, there is never any need to play the blame game unless someone has fundamentally failed to carry out their responsibilities as agreed with the PM.

    I would also expect a PM to be able to identify weak objectives and requirements, or those which ‘don’t stack up’ when compared to the business case, and work with the key stakeholders to determine strategies to mitigate the risks, and plan accordingly.

    There will never be a surprise result to a well run project, perhaps undesired results but they will have been arrived at in a way that is managed and expected.

    My own experience has led me to find that on software projects, once the finger starts to point I know that I’ve failed to do something I should have done sooner.

    If you find that as a PM you are not responsible for planning and executing all the way through to benefits realisation, then you are not really ‘the’ PM, someone else has taken the responsibility, and you are a sub-project manager of a set of work packages.

    So yes, the PM is not responsible for setting crappy goals, however he is responsible for calling them and managing expectation appropriately. Whilst they might not understand the business context completely, they do understand the project completely (in fact, they are probably the only person that does) and what its delivery means within the context of the business, so cannot be devoid of responsibility.

    Just IMHO YMMV :o)

    Keep up the good work!

  • Max Walker February 17, 2010, 12:46 pm

    Hi Pawel – In my informal project environment, I find that that the stakeholders and sponsors really count on the PM to question, validate, and challenge. It took me a long time to learn that in my career, but now I value that behavior within my team, too. So while I’m not quite ready to say the PM owns it all and is ultimately responsible for any weakness in the project definition, I think the PM owns much more responsibility in the definition of the project than we may often think.

  • Joshua Lewis February 18, 2010, 11:27 pm

    The same argument applies to prioritising features – its not the responsibility of the technical or delivery team. Simply because they’re not running the business and don’t have the information.

  • Pawel Brodzinski February 21, 2010, 11:24 am


    I didn’t want to make pointing fingers (as an activity) a summary for the post but it appears it went this way.

    I’m with you when you say that once blame game starts someone should have done better job in the first place. I agree PMs are often those who failed. But at the same time I can think of a number of projects where project manager had virtually no chance to verify project goals. One big group of these projects are custom applications developed according to specifications delivered by the customer. You just get big book of specs and no one really tell you what are the goals.

    The closer the vendor is to the client the more the project manager should do in terms of verifying project goals and dealing with goal-related risks. If you have internal client you will know business background better. If you work for application addressed directly for end-users definition of client changes so you should be probably talking with product manager so you’re even closer with goal-setter and you should know even more.

    Anyway, it all depends on specific situation. In big organizations office politics often kicks in and real goals remain hidden. Then, no matter how PM tries it won’t be her responsibility for failure in this area.

  • Pawel Brodzinski February 21, 2010, 11:29 am


    In small projects project management is often a kind of all-in-one role. I’m not surprised you’re often expected to share your opinions on business side of the project. As long as you, or any other team member for that matter, have enough knowledge about project background every insight is welcome.

    At my current team we work exactly the same, although I share formally a few roles so I can’t say I’m pure project manager. I would even say project management isn’t the most important role I fulfill, but that’s how you work in small teams. And that’s why I love working in small teams.

  • Pawel Brodzinski February 21, 2010, 11:36 am


    Good point. Although sometimes it goes too far. I recall a number of situations when old “you can have this or that feature by the end of the month so choose” kind of discussion happened while it was possible to have it all. Some people just needed to understand why specific features were being added to find a solution which satisfied everyone. The problem was they didn’t even tried to understand this.

    Of course that doesn’t mean tech team should own prioritizing.

Leave a Comment