4

A lot of the skills I've picked up as a Lean / Agile coach seem to be relevant to project management, and I've started getting offers of PM work from agencies. Since I coach PMs, I feel like I ought to have a go at actually managing a project at some point.

My people-related skills are pretty good and I have a thorough grounding in both Lean and Agile (including the many places they fail). I've seen projects through from creation to iterative release, coached different roles within projects, and have a good understanding of risk with tools and courage enough to identify and manage it. I'm also into Systems Thinking.

What's the difference between a good coach and a good PM? What additional skills will I need to adopt in order to successfully manage a small project? Do you recommend any particular books or training courses?

4

It sounds like you have actually been managing projects already. The single biggest skill you'll need to be mindful of is learning - make sure you reflect on your progress in the new role of managing projects. Daily at first then weekly self-catch-ups will probably help.

I also recommend finding a great mentor - a project manager you admire and who is sufficiently experienced for you to be able to bounce ideas off and ask for advice.

Self-awareness and awareness of the differences between being the mentor and the mentored will help as you swap roles and go "back to school".

Finally, you'll need resilience to deal with the real-world stresses that exist on projects that you may or may not have been subject to in your role as a coach.

Remember the old quote: "Grant to us the serenity of mind to accept that which cannot be changed; courage to change that which can be changed, and wisdom to know the one from the other"

  • Thanks, Matt. Of all the answers, this was the one I found most reassuring and encourages me to go ahead and give it a go when the next opportunity arises. I'll also make sure I have a mentor on hand! Thank you! – Lunivore Apr 9 '11 at 15:19
4

I'd say that much depends on a type of project you're going to manage. If the project is run in an agile way internally there's little more to learn. The biggest difference is the role of coach is kind of hit-and-run. Coach doesn't live long life with result of their advices. Coach doesn't fight an uphill battle to sustain changes which have just been implemented, etc. But then if the organization has reasonable approach the effort should be spread over whole team and it shouldn't be responsibility of PM only.

The bigger difference is in outside world. Even agile organizations often work for clients who aren't agile whatsoever and it's PM's role to map these two worlds back and forth. So basically you need to learn the way the client work and find a way to make them happy and at the same time build bridges to your teams approach to project. The former may mean working on project in a very formal way, preparing extensive documentations up front, analyzing whole thing at the beginning, little feedback from the client along the way, managing every change in a very formal way, etc. It may also mean difficult discussions with the client even if that's not what you'd prefer to do - if you work within budget constraints not every change should be embraced as not every client understands what it takes to eat the cake, i.e. they aren't getting it.

Then we have projects and organizations which are formal/very formal. Usually the first thing is to learn local office politics as in such organizations it is often required just to have a chance to succeed, let alone achieving a success. Then it's a bit like adopting to the way client works but on the other side. Whatever the current organizational culture is you're probably going to learn and accept it, at least to some point. If you're out of luck it won't be aligned with what you believe is right and it usually takes long, long time to change the culture even if you have much power.

To summarize that somehow I'd say that the main role of a PM is delivering a project while the main role of a coach is improving the organization. It doesn't mean one shouldn't do both but they should know where their priorities are. So if you ask about specific skills I'd go with adaptation. And if you ask about specific books I think it's more important to learn local specific than to look for generic answers in generic books.

2

A good coach (external consultant) can use directive and non-directive approaches with trying to influence change. A PM (internal employee) will have system constraints they may just need to deal with (IE: those useless status reports are reality in many organizations, may not make sense to swim against those organizational currents). A change agent that moves into a PM or any full-time team role, IMO, has a better opportunity to influence change.

  • Thanks, that's reassuring and matches my experience of working as a developer last year. Changes were influenced indeed. – Lunivore Apr 8 '11 at 12:24
2

Based on my personal observations as a team lead, as a coach, and in my brief ill-fated attempt to merge architect with PM, there are only a few major areas of difference:

  • Budget - Coaches and technical team leads are rarely responsible for managing the project's budget, especially when it comes to the staffing and people aspects. While agile makes it easer (burn rate * expected number of sprints), that doesn't take away the need to track, manage, and otherwise own and report on the budget.
  • Scope - Agilists are happy to say "vary scope". We're also very happy to say "we'll solve business problem X". We're not very good at saying "we'll solve business problem X in 5 sprints or less" when it's a big problem. On one hand, this opens the door to incremental funding models and all sorts of fun things in that direction. On the other hand, it opens the door for very stressed out project managers as they try to understand and explain what's going on in a way that doesn't get the project cancelled.
  • Staff - Scrum, at least, assumes a properly cross functional team. Somebody has to be responsible for building one (or more) of those before the project starts, ensuring it survives without killing itself, and generally make sure that the people are available and paid. Many times, this falls on the project manager either to put in the req to a functional silo or to hire directly.
  • Politics - the nature of the politics seems to change from the coach's "art of the possible" to the PM's "art of keeping the project alive". I don't have a good feel for the details of this aspect personally, but the sort of politics that needs played seems to be different between the roles.

As you mentioned in your question, many of the people that are great coaches already have most of the interpersonal and communications skills to be effective PM's. These are the bits I see that are "new" skills for coaches.

1

I guess the biggest practical difference is in the client-facing aspects of a typical PM role. Coaches (once the gig is won) tend to work with internal folks (the team, and others inside the team's host organisation). Not a hard-and-fast rule, to be sure, but worth considering?

PM's can often be expected to be a Product Owner or PO proxy, too.

And then there's the whole mindset thing. Can e.g. Agile folks (especially coaches) tolerate a classically "Analytic" organisation (the natural home of all PM's), which might be regarded as dysfunctional in many respects, compared to a synergistic organisation, or team, environment?

BTW Knowing you, I can't believe you'd be anything but super, great in a PM role! But would you enjoy it? Hair shirt?

HTH

Cheers

Bob @FlowchainSensei

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.