Spot the Agile PM

Last week I was able to attend the excellent Thomson-Reuters/PMI Project Management “Unconference”, held at Exeter University. I also volunteered to host a couple of the bar-camp sessions, one on Coaching for PMs and the other Stakeholder Management.

The event offered plenty of opportunity for discussion during the breaks, and it struck me in particular how much Agile came up as a topic of debate. This was even more remarkable because it wasn’t particularly a subject on the agenda. Even in my bar-camp sessions if I spoke about coaching, I got asked about best practice as an Agile Coach. If I spoke about stakeholder management, I was asked about stakeholders in Agile projects. It is clearly a hot topic!

One thing that seems to be happening is that project managers are concerned about their role in the Agile world. Quite a few are going on Scrum Master training courses, and are confused because there is no explicit PM role in Scrum (which is, of course, just one flavour of Agile – but seems to be the one that most are going for).

Here are the three roles defined in Scrum (source: The Scrum Alliance):

Product Owner

  • The product owner decides what will be built and in which order
  • Defines the features of the product or desired outcomes of the project
  • Chooses release date and content
  • Ensures profitability (ROI)
  • Prioritizes features/outcomes according to market value
  • Adjusts features/outcomes and priority as needed
  • Accepts or rejects work results
  • Facilitates scrum planning ceremony


The ScrumMaster is a facilitative team leader who ensures that the team adheres to its chosen process and removes blocking issues.

  • Ensures that the team is fully functional and productive
  • Enables close cooperation across all roles and functions
  • Removes barriers
  • Shields the team from external interferences
  • Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint planning
  • Facilitates the daily scrums

The Team

  • Is cross-functional
  • Is right-sized (the ideal size is seven — plus/minus two — members)
  • Selects the sprint goal and specifies work results
  • Has the right to do everything within the boundaries of the project guidelines to reach the sprint goal
  • Organizes itself and its work
  • Demos work results to the product owner and any other interested parties.

So where has the PM gone? The answer, of course, is that the responsibilities have  been redistributed.

If we start from The Seven Essentials being the basis of project management, how do these map onto the Scrum roles?

  • Benefits – clearly the responsibility of the Product Owner
  • Scope and Quality – also Product Owner, since they define the features, and accept or reject
  • Stakeholders and Communications – not really mentioned, but external communications (to senior stakeholders) will also be handled by the Product Owner
  • Plan – This one is split. Scrum Planning (i.e. high-level planning) is facilitated by the Product Owner. The Team organises its own work (detailed planning).
  • Team – Scrum Master looks after the team.
  • Suppliers – Not explicitly mentioned, but both the Product Owner and the Scrum Master have a role here. The Scrum Master in particular has a responsibility to remove barriers, which could indeed be due to suppliers.
  • Risks – Again, not mentioned, but there is a touch of risk management in everyone’s role. The Product Owner will be concerned with external and commercial risks, the Scrum Master with risks to the team’s efficiency, and the Team itself organises its work accordingly.

So, to summarise in table form:



Scrum roles


Now can you spot the PM?

I’m not saying that Project Managers shouldn’t retrain as Scrum Master. I’ve done it myself, and the training will teach you a lot about Agile. And the Scrum Master role itself can be interesting, demanding, exciting… I’m sure it would suit many former project managers. But if you’re a “seven essentials” sort of PM and you want to continue to develop those skills, then you should think about moving towards becoming a Product Owner.

Posted in Agile, Project Management | Tagged , , , , | 1 Comment

The Fifth Essential: Team

In the first four keys we have established our business objectives, engaged our stakeholders, agreed a scope, and planned a delivery. Now the focus of the project manager should turn to enabling the team to deliver.

It is really important to understand that it is the team that delivers, not the project manager. From this it follows that the project manager works for the team and not vice-versa. True leadership is about vision and purpose – and enabling the team to succeed.

So who is the “team”? Whereas when defining stakeholders it is good to take a very wide view (everyone impacted), I prefer to be more focussed when it comes to the team. The team is the set of resources that are directly under the control of the project manager.

Often, the team members are not actually line reports of the PM. This gives rise to potential conflict between project manager and line manager, but the ideal situation is where the team member is effectively functionally assigned to the project manager for the duration of the project.

It is not unusual for staff to work on multiple projects in parallel. I suggest that a team member is someone who spends most of his working time (i.e. greater than 50%) on the project. Anything less, and that person is an internal supplier, not a team member.

The makeup of the team is often dynamic – for example it may have more designers early on, and more testers later on – but at any point in time the PM should be able to state unambiguously the current team membership.

Now we know who the team are, somehow we would like them to become “high-performing”. What does that feel like? When I’m part of a high-performing team, I experience:

  • a sense of purpose – of shared vision
  • absolute determination to deliver, no matter what it takes
  • willingness to step beyond the call-of-duty

I also feel excitement, enjoyment, and sometimes euphoric exhaustion!

How does the project manager gain this state of sustainable high-performance? There is no single answer, but here are few ideas that I have personally seen succeed:

1. Leadership and Vision

The project manager should be the second-best advocate of the project – the first being the project owner. The PM needs to be absolutely bought-in to the business objective, and to be able to articulate it with enthusiasm at every possible opportunity.

2. Clearing Impediments

I’m deliberately using SCRUM terminology here – clearing impediments is the first responsibility of the ScrumMaster. And it is also applies to project management of any kind of project. The PM needs to be sensitive to anything that stands in the team’s way, and clear the obstacle. Is there an awkward process that needs to be side-stepped? Is there a budget deadlock that needs to be resolved? Does the team have a problem with desk space? No matter what the impediment, it needs to be tackled. And if it really can’t be fixed, then the PM needs to help the team accept the constraint and agree a coping strategy.

One of the biggest impediments in a demanding project is cynicism. Cynicism diverts energy, and destroy the team’s performance. Project managers can counter this with enthusiasm and sense-of-purpose. But sometimes decisive action is needed to remove a “bad apple”.

3. Self-Determination

Teams, sub-teams, and individuals should be encouraged to think through the challenges and devise their own solutions. Trust the team to come up with the best solutions for themselves. Not only will it (probably) be the best answer, but they will most certainly be fully committed to it.

Occasionally the project manager may know better – but not very often. And even when this is the case, you are likely to have more success with a sub-optimal approach that the team supports than a “perfect” solution that isn’t supported.

This is, of course, a coaching style of leadership.

4. Push and Challenge

It is amazing how hard people are prepared to work, if they are motivated! Don’t be afraid to set demanding targets. You are not being kind to a team by giving them an easy ride; most of us prefer to work hard than to be bored. Some people actually thrive on working long hours – but we’re not all the same in this area – so be sensitive (and also take account of health and legal constraints).

5. Celebrate Success!

Always remember that when the PM delivers an outstanding result, it is actually the team that deserves the credit, not (just) the PM. Be appreciative of good performance, recognise and reward it to the extent that you can, and always try to find some beer money for an occasional team event.

Posted in Project Management, Seven Essentials | Tagged , , ,

The Fourth Essential: Plan

I was once a team leader in a large project. At that time I wasn’t yet a project manager, but the project did indeed have someone with that title. I expected him to ask to see my plan, because that’s what project managers do, isn’t it?

His answer surprised me. “I’m not interested in your plan. But I’d like to help you produce one.”

I asked him what tools he would like me to use – again, isn’t that what project managers are supposed to do for a living? “I don’t care. Just invite me to your team meeting and we’ll do some planning.”

What happened next was a team workshop, in which we spent a lot of time coming up with a messy diagram on a whiteboard. It had activities, deliverables and arrows, and some dates. The PM challenged us to define the objectives, and constantly asked about dependencies. He didn’t do any “planning” that I could see – he just asked us tough questions.

At the end of the meeting we had a rather ugly diagram, but it was one that we were all happy with. I asked whether he would be turning it into an MS Project plan. “No, but you can if you want. As far as I’m concerned you’ve done the planning. You now have a high-quality plan that your team has bought into. As I said before I really don’t care how you document it.”

I learnt a lot from that PM – in fact, he became a role model for me. His point, of course, is that the planning process itself is what matters, and it matters far more than the plan. It matters because:

  • The team does the planning. Not the project manager.
  • The team thinks through the issues, and comes up with their own solutions.
  • The team now owns the plan, and are committed to delivering against it.

I wouldn’t personally go quite to the extreme of not caring about the subsequent plan. It is an important baseline – something to track against – and it is an essential communications tool.

When I look at a project plan, the things that interest me are:

  • Does it demonstrate how the project delivers against the project scope – is there a clear linkage?
  • Are the dependencies properly shown?
  • Is it likely to be understood by the intended audience (including team members and senior stakeholders)?
  • Is it up-to-date?

I also like to ask how the plan was produced, and how it is maintained. To what degree are the team involved?

The form of the plan doesn’t matter. It can be MS Project, Powerpoint, Excel, or a squiggly diagram on a whiteboard. Just as long as the team regards it as being their plan.

Posted in Project Management, Seven Essentials | Tagged , , , ,

Beethoven liked to go for a walk

Although I’m a strong advocate of following a project management process, this does not mean that there is no room for creativity in projects. Far from it. No two projects are the same, and because the human element is always a major factor, the project manager has to be versatile, adaptable and creative.

The Seven Essentials provides a framework, within which the PM can apply their creative skills. But project management is not a factory process.

Last week’s Horizon on BBC (available on iPlayer in the UK at the time of writing) looked at the creative process, and in particular the “aha!” or “eureka!” lightbulb moment. This is where the solution to a problem suddenly comes to mind, seemingly from nowhere. Of course, it doesn’t really come from nowhere; there are unconscious processes at work within the brain that are able to produce these remarkable results. Also, there are behaviours that can be adopted that increase the chances of lightning striking.

It got me thinking about how this applies to project managers. Certainly the ability to come up with creative solutions to a project challenge must be a strength, so what behaviours do we need to adopt?

The key, it seems, is to give the brain the bandwidth to carry out some background processing. It works best if the mind is somewhat active – not totally relaxed – but not too  busy either.

When I was doing A-levels, my sixth form tutor advised doing an hour or so of revision, and then to go for a walk and not really think about anything. Let it sink in. And then back to the revision. It worked for me, and to this day I find that going for a relaxed walk really helps my mental processes. The research described on Horizon shows that there is some science behind this.

For project managers, apart from going for a walk, here are some hints:

  • Don’t spend too much time stuck at your desk. Interact with people, face-to-face, as much as possible.
  • Don’t skip lunch – and don’t lunch alone. Apart from the social contact, those casual lunchtime conversations might give your mind the space to get on with some background processing.
  • Vary your tasks throughout the day. If you are more creative during the morning, as many of us are, then don’t squander that time on your email backlog. Turn off Outlook, and do something more interesting.
  • Spend non-work time with the team. Hold social events. Relax together. If you’re working away from home, hotel bar time sometimes generates useful ideas.

I try to write these blogs on a weekly basis, and almost always I start by going for a walk. Next comes a mind map, and then I write.

Beethoven didn’t actually write a blog, but according to Horizon whenever he was a bit stuck creatively, he went for a walk.

Posted in Project Management | Tagged ,

The Third Essential: Stakeholders and Communications

Thanks to the first and second essentials, we have by now established the reasons for doing the project. Next we need to consider the people affected by the project: the stakeholders.

Stakeholders are anyone impacted by a project, positively or negatively. That is a deliberately broad definition, as it encourages the project manager to think about executives, governance gatekeepers, team members, line managers, operations staff, customer services staff, and even… gasp!… customers.

Often when we loosely talk about stakeholders, it is actually the senior stakeholders that are meant. These are the executives directly involved in the project; typically members of the steering board.

There is a fundamental reason why stakeholders are important. It is that project success depends entirely on satisfying stakeholders. Stakeholders – and stakeholders alone – determine whether or not a project is successful. You may have thought that project management is all about delivering to time, cost and quality… but that is an illusion. The TCQ triangle is simply a proxy for stakeholder satisfaction; nothing more.

A project can meet its targets and yet it will be unsuccessful if the stakeholders are not satisfied. Conversely, a project can miss its targets, and still be successful if the stakeholders say it is successful. Accepting and working with this apparent paradox is the most important step in moving from being a project administrator to a true project manager.

Stakeholder management is one of the “soft” skills, which is short-hand for the people-oriented topics where ambiguity and uncertainty are part of the puzzle. This is in contrast to “hard” skills, such as being able to build a project plan in MS Project, that are deterministic and defined.

Junior project managers might typically devote 80% of their time on hard skills, and 20% on soft skills. For the most senior executive-level project managers, this is reversed: most of what they do on a day-to-day basis comes down to soft skills, and most of this is stakeholder management. Is it cause or effect? Is it that the top projects demand more in the way of soft skills, or is it that the project managers who concentrate on soft skills rise to the top of the profession? I think it is a combination of the two: the bigger the project, and the bigger the project manager, the more important it is to master stakeholder management.

There are many approaches to stakeholder management, but the one that I favour comprises three simple steps:

  1. Identify the stakeholders. List them, by name if possible, or at least by function.
  2. Categorise the stakeholders, using three tests: (1) How much power or influence do they have? (2) Are they supporters or detractors of the project? (3) Are they fully engaged, or disinterested?
  3. Manage the stakeholders accordingly.

Each possible outcome of the categorisation will lead to a different tactic. For example, someone that has high power and supports the project but is not engaged, needs to be brought in from the cold, as they will surely be an ally. Someone who is against the project but who lacks power needs to be converted to a supporter, or if not possible then they should be put in their place so as not to cause damage.

The Third Essential also covers communications for the good reason that stakeholders are the recipients of project communications. The task of the project manager is to plan the project communications in terms of who, what, how and when.

For example, a project status report may be issued formally to senior stakeholders on a weekly basis. At a minimum it is likely to contain information on project progress, planned next steps, and current risks and issues. Team communications are more likely to be verbal – perhaps in the form of a daily stand-up meeting. Informal communications can also be planned: how about a breakfast get-together with selected team members and senior stakeholders?

Stakeholder management and communications are both huge topics, and I have only scratched the surface here. Remember that the best project managers make time for stakeholder management. If this comes naturally to you, then great. But if not, then take time to practice the techniques.

Not all projects are successful in terms of delivering the entire scope. If the project manager is to escape with reputation intact – or even enhanced – then stakeholder management is the key skill to apply. 
Posted in Project Management, Seven Essentials | Tagged , , , , | 1 Comment

Coaching for Project Managers

This week I spent some time talking to a potential client about coaching and project management. The discussion was split into two parts:

  • Coaching of project managers. In other words how to set up a coaching and mentoring scheme to support the development of top PMs.
  • Coaching for project managers. How PMs can apply coaching skills in the their day-to-day work.

This blog focusses on the the latter. The former is an even bigger topic, that I will return to on another occasion.

The ability to apply a coaching style is a management skill, not just a project management skill. Actually, it is more than that – it is a life skill… and I know I’m at risk of sounding a bit too “new age”!

Coaching is about helping an individual to unlock their potential. From that definition it should be clear that this is a valuable skill for a sports team manager, a project manager, a line manager, and indeed for a parent.

Coaching in its purest form is “non-directive”, which means that it is the person being coached who takes the decisions and owns the outcomes. The coach simply facilitates the process. Sir John Whitmore illustrates this in a rather dated but still excellent video clip:

(The video requires a password that I don’t want to post here; please ask)

There is a difference between “coaching” and “coaching style”. Coaching is a formal arrangement where the roles are defined: the coach knows that they are being a coach, and the coachee knows that they are being coached. There are agreed boundaries to the coaching relationship.

Coaching style, on the other hand, is an approach to everyday conversations. The “coachee” is unlikely to notice that they are being coached, and even the “coach” may be acting instinctively without consciously thinking of it as coaching.

The best-know coaching model, and the one that I believe works best for project managers, is known as “GROW”, standing for Goal – Reality – Options – Will. It is a roadmap for a conversation.

Goal – What are we trying to achieve?

Reality – Where are we now?

Options – What are the possible approaches, and what are their relative merits?

Will – Having considered the options, what will we actually do, and how will we overcome any barriers?

This simple model is extremely powerful. With practice, it forms a mental checklist for many a challenging conversation. Here is an illustration:

Test Manager: I’m worried that we’re not going to get the testing done on time.

Project Manager (Goal): Remind me – what target are you shooting for?

TM: I need to get 100% of the testing complete by the end of the week if we are to make the schedule.

PM (Reality):  And what is the current position?

TM: At the current rate, we might just hit the target – but if we get just one more major error then it is going to slip a day or two into next week.

PM (Options): So what do you think we could do about it?

TM: We could release the product without the testing complete – but I don’t like that as we are supposed to be quality-driven company. Or we could continue as we are, and accept the slippage. Or we could add more resource and work into the weekend – that should be possible.

PM (Will): What do you recommend?

TM: I think we should continue as we are, and if we get lucky then we’ll meet the schedule. Meanwhile I’ll get some resource lined up for weekend working, just in case.

PM: That’s great, please go ahead, and keep me informed.

Okay, so that is rather simplified, but at least it illustrates the process. Notice that the PM didn’t actually need to issue any instructions- the Test Manager came up with and committed to their own entirely satisfactory solution.

Much more on the GROW model can be found in John Whitmore’s excellent book, Coaching for Performance.

In my experience it works with team members, it works in performance reviews, it works in meetings (if ever you’re adrift in a rudderless meeting, try asking some GROW questions) and it works with children – which is a great way to practice!

The secrets of success are:

  • Trust the process. It works.
  • Practice. Get comfortable and fluent with asking the right questions.
  • Listen to the responses. Really listen.
  • Be less directive, by empowering your team members to own their decisions.
Posted in Project Management | Tagged , | 4 Comments

The Second Essential: Scope and Quality

Scope should be so obvious to most project managers, that perhaps there isn’t much to be  said here. On the other hand, there is no harm in revisiting the basics and possibly uncovering some not-so-obvious aspects.

By having a well-defined scope, we can plan with certainty, execute with confidence, and deliver exactly what the stakeholders want. It’s a great idea, but have you ever seen it work like that? No, me neither.

More often, the initial scope is just that: a starting point. The destination may not be clear, but the initial scope points the direction. It may form a baseline for subsequent adaptation, under change control.

Nevertheless, there is tremendous value in attempting to define the scope at the outset, to whatever level of detail seems appropriate. Apart from anything else, it provides an opportunity for high-quality conversation with senior stakeholders – who may not be aligned, and may have completely different ideas of project success. So by writing down a proposed scope, along with accompanying project success criteria, the project manager can facilitate the process of convergence between stakeholders.

I was once given a project whose total initial statement of scope was “let’s do something about security”. Too loose a statement of scope? No, not a bit of it – that’s my kind of project! What an ideal opportunity to spend time with senior executives, as well as subject matter experts, to understand what security means to them, and to put together a programme of work that addresses their combined individual success criteria. Over time the detailed scope was developed, refined, agreed, and delivered.

Being able to work with ambiguity is not the same thing as being tolerant of scope-creep. The project manager always needs to know the scope, needs to manage within that scope, and must adapt in the light of new information or circumstances.

The Agile Manifesto favours “responding to change over following a plan”. Now, this statement is guaranteed to upset most project managers, especially those whose lives revolve around MS Project. But actually the statement is correct. Is it better to deliver the wrong thing well, or the right thing badly? Best of all would be to deliver the right thing well, of course!

The Seven Essentials links Scope with Quality, because each deliverable defined in the scope should have associated with it some quality parameters, i.e. acceptance criteria. Prince2 is particularly strong on this discipline – building the plan around the definition of deliverables (“products” in Prince2-speak) and their quality criteria. This is a great approach, but beware being too rigid too early in the project.

Why do we need quality criteria? I have recently been reading about the history of the First Transatlantic Telegraph Cable. What a great project! Unfortunately there was a quality criterion missing. After several failed attempts, the first working cable went live on August 16, 1858 – with much public ceremony and celebration. Sadly the cable deteriorated rapidly over the following days with insulation breaking down, and it failed completely within the month. If you had been the project manager, would you have claimed success for laying the cable, or would you have taken the blame for its failure?

So, in summary, when I’m reviewing a project and considering the Second Essential, here is what I’m looking for:

  • Is the scope defined and agreed with senior stakeholders?
  • Do the deliverables have defined quality criteria?
  • Is appropriate change control in place, and is it working?
Posted in Project Management, Seven Essentials | Tagged , , , ,