«

»

May 07

Some confusion around the project manager role

Introduction

Scrum has some really good points to it but one of its failings is that it doesn’t recognise the role of the project manager.  This in turn creates all sorts of difficulties for Agile teams, especially those that are transforming a large organisation.  To my thinking if we let go of the PM role then who is going to take over governance of the projects?  This is where I think Atern has got it right as it not only recognises the need for the PM role but strongly encourages its use.  However, my experience informs me that often PM’s in the Atern role have a hard time switching their thinking and behaving to be more aligned with the Agile way of working.  However I personally believe that the Atern handbook doesn’t help the plight of the PM in an all new Agile world as some of its direction can be somewhat misleading.  In this article I will explain more, but I am hoping to get hold of one Atern’s luminaries to shed some light for me on some of these differences.

My appreciation for PMs

But first, let me  clear up a few points as in the past I have been accused of “Project-Manager-Bashing” on some of the courses that I deliver.  I have come from a PM background where I have run projects in Waterfall and RUP; I have also coached and consulted PMs on projects running Atern and Scrum.  So I have much empathy (note, not sympathy – that’s way too debilitating to be in any way resourceful) for PMs moving from a mindset and associated behaviours of waterfall to Agile.  During a transition to Agile there is a time where many (not all) PMs will flounder as they grapple with the new behaviours required of an Agile PM and the thinking that supports these behaviours.  The transition required of PMs is IMHO the most stark and contrasted change required for any of the roles on an Agile project or programme.  To this end I believe that PMs need support and challenge, in equal measures, during this transitional period.  This support and challenge is often provided by means of Agile coaching especially adapted for PMs. (You can check out our offering here.)

What is the role of an Agile Project Manager?

In my opinion the Agile project manager (APM) is a mainly externally facing role.  The main goal of the APM is keep the customer happy and satisfied, in this case the business;  if I’m talking in Atern terms here I mean the business visionary and sponsor.    Now there are other high level managerial duties that the PM will carry out such as high-level project planning and scheduling (do note that I did not include estimating here), monitoring progress against the base-lined project plans, removing impediments that are outside of the solution development teams’ scope and so on.

However the Atern handbook does give the following, what I would call misleading, advice (see p40 under responsibilities):

“managing the overall configuration of the project.” mmmm – What is meant by configuration here?  If we are talking the setup of the teams i.e. should we structure the available people into two or three solution development teams in order to deliver, then I firmly believe that this is a job for the team to consider.  Isn’t this what we mean by empowerment? Aren’t Agile teams supposed to be self organising?  I’m not saying that PMs shouldn’t have some input into this because there may be limitations or restrictions that may mean that the teams can’t organise in the way they would optimally like to.

“motivating the teams to meet their objectives.” I don’t think so!  But imagine for a moment if that were true what possible “carrots” or “sticks” would the PM be offering their team.  When I coach PMs I help them understand this one point at the outset: the only way a PM will motivate the team is by seeking to deal with what Herzberg refers to as the Hygiene factors, things like environment issues, bureaucracy and red-tape, an escalation point for relationships with other team members (between departments) and salary & benefits.  (Of course even this last one not many PMs have much control over.)  I’ve had many PMs have most interesting discussions with me on this point and some even go so far as to say that they feel that it is their responsibility for the teams happiness! Good luck with that one, but I feel that this is a topic for a completely different blog post, but maybe you can provide me some answers below as to why this is a completely unrealistic expectation that is placed on the PM?

“coaching the solution development teams when handling difficult situations.” mmmm – again I can interpret this in many ways.  OK if a team member comes to the PM then I would say by all means be a supportive ear or a challenging voice.  But I feel that the PM ought to be building a network of leaders below them through the team leaders.  Often PM will unintentionally build learned helplessness into their teams by being the person who will solve all the teams problems and issues for them.  This is why I have serious reservations about the ab-use of the term “coaching”.  Much of the coaching I have observed is actually mentoring and falls under the banner of telling people what to do; but hey I know that ship has sailed and I’m not going to be able to get the whole Agile community to address the misappropriation of the term Agile Coach, so ’nuff said.  But coaching isn’t a clever or manipulative way of telling people what to do or giving them advice, that is one small part of coaching that is reserved for “emergencies” and is applied with many caveats.

The PM as the “one wring-able neck”?

I have saved the most challenging quote from the Atern handbook for last: “The Project Manager role is responsible for all aspects of the delivery of the solution.” (The highlighting of all is mine.) Ouch!  So are we back to a case of the PM being the one wring-able neck?  If the project fails the PM gets the boot?  I know this might still be the prevailing wisdom within organisations, but it is inherently flawed.  If the PM believes that they will be the one wring-able neck then they are going to act in ways that will be dis-empowering for the team.  Where is their responsibility?  Are they being given permission to fail.  I know this stuff really reads well in the text books just before we pop off to sleep to dream about our projects being in some Disney movie, but in actuality is the environment within which projects are delivered “blame-free” and “safe to make mistakes and learn from them” zones?  This is not the case in all organisations.   If not then this ceases to be a management issue and becomes a leadership issue.  I’ll write some about this in up and coming posts.

0saves
If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

About the author

Mark Buchan

Mark is an Agile Consultant and Executive Coach who specialises in working with leadership teams when they are transforming their organisation to a more Agile way of delivery.

3 comments

  1. Mick power

    It makes an interesting read and I particularly like the bit about that I as a PM am not responsible for the project failing……. I am less sure the senior people in organisations that pay little attention to projects until they believe it is time to show an interest (usually too late in the day) would agree with you. I think these people are suffering from la la la syndrome (a case of la la la I’m not listening). They ignore all the signs and don’t take escalations seriously enough until it is all too late and the project is in so much trouble that it costs far more to recover than if they had just kept their finger on the pulse.

    Another big mistake I have found recently is the thought that cutting corners early in a project will save time and money. There really os nothing further from the truth as this will only lead to the need for significant change late in the project that will inevitably cost more in the long run.

    1. Mark Buchan

      Mick – You are absolutely right. Senior managers like the fact that there is one wringable neck – it provides them a place where they can rest the blame if and when things go wrong. If we tell them the team is to blame for the project failing, well waht can they do about that – fire the team? But it is all most interesting because it is that one interesting point – who is to blame? To my thinking this is completely the wrong question and the wrong area of focus, whether the PM is responsible or the whole team is responsible is neither here nor there. The focus and emphasis needs to be on find the root causes of the issues and get on with the job of fixing those. One of the sad facts about agile teansformation is that all too often the senior managers or leaders think that it is for the delivery teams to become agile so we can deliver more and quicker. The leaders fail to recognise that they in some small way need to change, either changing their thinking or behaviours, until they do the major benefits of agile will elude them as they move on in search of their next silver bullet.

      On your other point about cutting corners I have observed this behaviour in mnay teams and organisations as they skip through the foundations activities, often completing them too early in order to just start coding – a typical JFDI attitude. This, as you suggest, results in significant changes further down the road which ironically loses us more time than we saved by doing the activity properly. It is my hope that your projects learn Mick as this is a core value and behaviour of an agile team.

  2. Richard Kilcoyne

    Reading this took me back to June 2011, sitting in Agile training with you, wondering “where do project managers fit in here?” Once we eliminated PMs as scrum masters, we seemed pretty redundant. A year on, I would agree wholeheartedly with your opinion that the role is mainly externally facing. I have tended to sum it up as “doing what is needed to let the team get on with delivery” which aligns to your discussion of dealign with Herzberg factors.
    I also agree with your “ouch” ref the consideration of a PM as the one wringable neck and a desire to see “one head on the block” (and the granting of permission to fail). That won’t change until there is a desire to see change at a senior level which will be a test of buy-in to Agile at the highest level.
    On the plus side, I have experienced this year as an Agile PM as an opportunity to lift myself out of the detail in my projects and to start taking a more strategic (programme?) view of delivering change. Hopefully this is a result of the project teams being more empowered.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site is protected by Comment SPAM Wiper.