About Russell Whitworth

This author has not yet filled in any details.
So far Russell Whitworth has created 22 blog entries.

The Seventh Essential: Risks

Me: "Could you show me your risk register?"
PM: "There are no risks. This project is 100% safe."

Risks are all around us. There is a risk that I might get struck by a meteorite. There is a risk that I might win the lottery (yes, risks can have positive outcomes). In a project management context, a risk is something – anything – that might happen that has an impact on the project outcome.

Most project managers understand the basics of risk management, yet (in my experience) it is often a sadly neglected area. I have yet to see a project that didn’t have a plan of some description, but I have certainly seen quite a few that don’t have a risk register. Personally, given a choice of the two, it is the plan that I would ditch first!

The process of risk management is straightforward:

  1. Identify potential risks.
  2. Classify them, in terms of likelihood and impact.
  3. Identify some mitigation actions – to reduce the probability and the impact.
  4. Identify contingency actions – what will we do if this risk becomes realised?
  5. Review and repeat, frequently.

Identification is not just down to the project manager. The whole team should be involved. A risk review is an opportunity for a high-value discussion with the team members.

There is a reason why “risk” is the seventh and last of The Seven Essentials. It is because the other six are all possible sources of risk. So when reviewing risks, make sure you consider: Benefits, Scope and Quality, Stakeholders and Communications, Plan, Team, and Suppliers.

Also, look at past experience. Ever wondered what “Lessons Learnt” reports are for? Here’s your answer! Review what happened on earlier similar projects, and learn from the mistakes they made. If there isn’t a Lessons Learnt library, seek out PMs with relevant experience. Have your team members done anything similar before? What did they learn?

Estimation of probability and impact may not be an exact science – a “gut feel” may be all you have to go on – but your guess will surely be better than anyone else’s. That’s why you are the project manager. Of course, the result of classifying the risks is the ability to focus on the most damaging and most likely dangers, whilst being aware of but not wasting time on the noise.

Mitigation actions are things you do now to reduce the probability and/or impact of a future risk. Some risks might warrant multiple mitigations. They are actions. They need to be carried out. Put them in your plan. And you don’t have to do them all yourself… that is what the team is for.

Contingency plans are things you do in the future if a risk actually happens, i.e. if it turns into an issue. By having “if this, then that” sub-plans already thought through, you can react quickly to a change in circumstance, thus reducing the impact on your project.

It is no disgrace if a truly unforeseeable event sends your project off-track. But if something that could reasonably have been foreseen takes you by surprise… well, frankly, I would start to question your choice of profession.

None of this is particularly difficult, is it? Nevertheless, in the hundreds of projects that I have reviewed over the years, it is the area most commonly found wanting. Neglected risk registers, or none at all, set my mental alarm bells ringing: is this project manager really in control?

The conversation at the start of this article really happened to me during a project review. It was a high-profile and fairly sizeable IT project. What would your opinion be of the PM?

By | 2015-08-19T10:54:45+00:00 May 31st, 2013|Project Management|0 Comments

Project Management Accreditation (in a corporate setting)

My recent experience includes 9 years in a large corporate environment, where my responsibilities included running an accreditation scheme for project managers.

Why on earth would a company invest in doing something that – surely – is a problem that has already been solved? Wouldn’t it be better to send PMs on an external training course – PMI, or Prince2 perhaps – and have them sit the exams, and become fully qualified to an industry standard?

Well, perhaps – but there are also good reasons for keeping PM accreditation in-house:

  • The scheme can be designed to meet the company’s needs. This mainly means tweaking the syllabus to fit local practices and priorities.
  • If there is an in-house PM methodology (along with tools and processes), the training can incorporate suitable elements.
  • Weaknesses in external schemes can be overcome – for example, by incorporating more “soft skills” training and development than tends to be the case in more traditional schemes.
  • Accreditation levels can be aligned to job descriptions and career paths.
  • Practical on-the-job experience can be incorporated into the scheme, with full understanding of the environment, types of project, levels of seniority, etc.
  • Staff retention is improved, as the accreditation award is recognised and rewarded internally, but is less likely to attract the attention of head-hunters
  • Arguably it is more economical, as savings can be achieved by retaining a training partner and administering the scheme internally (although if the total internal effort is costed honestly, this argument can quickly break down).

The scheme I was responsible for was widely regarded as successful by both the participants and their managers. Typically, a project manager would participate for around 9 months, leading to an accreditation award at an appropriate level to their experience and seniority. During this time they would experience:

  1. Three 2-day training courses, run by an external training partner. At a junior level these would concentrate on the technical skills of project management: planning, scheduling, risk management, and so on. At a more senior level the balance switches to focus on soft skills: stakeholder management, team leadership, conflict resolution, etc.
  2. Peer coaching by a fellow PM, who will have been trained in coaching technique, with formal coaching sessions around once every two weeks.
  3. On-the-job experience of managing a project at the appropriate level, throughout the period. They should be applying the skills learnt in the training sessions, and working with the coach to improve their project delivery.
  4. Evaluation of the project manager through health checks (a minimum of three throughout the period) at which the PM should be able to demonstrate continuous improvement to reach the appropriate level. Also, senior stakeholder feedback is sought through interview, to determine whether the PM has gained the trust and support of managers.

The biggest challenge with the scheme was the “chicken-and-egg” problem of finding a suitable project at the appropriate level. A “learner driver” analogy is useful here – the learner PM is expected to drive a real car on real roads, with real dangers. There is supervision and coaching, but senior stakeholders may be reluctant to trust a “learner” with a business-critical top project.

Nevertheless the scheme operated successfully, and dozens of participants gained their accreditation. After it had been running for a few years, I was interested to find out which of the four components were most valued and which (if any) were disliked. A short survey of past and present participants, and their managers, showed that all parts were supported and highly-rated – much to my delight!

So I think we got it right. The PM Accreditation Scheme is something that am proud of from my time at that employer.

By | 2015-08-19T10:54:45+00:00 May 24th, 2013|Project Management|1 Comment

The Sixth Essential: Suppliers

When I have reviewed projects in the past, “supplier problem” is the most common reason I hear for projects running into difficulty. To some extent, this might be a convenient excuse: it is easy to blame something or someone outwith the project rather than admit failure within the project team. But the PM doesn’t get off the hook that easily, as there are techniques that will improve the chances of project success.

It is really difficult to generalise, as each project situation is different with respect to suppliers. Suppliers range from internal suppliers (such as a test team, office facilities, or HR) through to major sub-contractors supplying multi-millions of equipment and services.

Often, the internal suppliers are the hardest to manage. The problem is lack of accountability to the project manager. If the local IT department can’t provide enough working PCs for your team, what are you going to do about it? If the test team lets you down by rescheduling resources to a higher-priority project, who do you complain to? Best practice here is to establish Service Level Agreements (SLAs) with your internal suppliers. Agree the ground rules up front for critical internal suppliers, so that you know what to expect – and you then have clear grounds for complaint if the SLA is not met. Also, if I ever review your project, I will be more sympathetic to the “poor suppliers” excuse!

External suppliers are more normally governed by a contract, which will include penalty terms for non-conformance. Contracts are usually established by a procurement function – in itself an internal supplier to the project – and in my experience the service that they provide can vary enormously from a simple “standard terms” purchasing function through to taking a real interest in the project and tailoring the terms accordingly. The project manager needs to be fully engaged in procurement activities, to ensure that supplier contracts support the needs of the project.

Some procurement departments believe that their sole function is to buy at lowest price. Beware! If your supplier’s price has been pushed so low as to make the business marginal, then don’t expect to see much engagement from their best people.

The most important factor that a PM needs to think about is the assignment of risk. So in a “time and materials” contract the risk is mostly with the buyer, i.e. the project manager. If timescales slip, it can actually be to the supplier’s financial advantage, as the time and hence the price will increase. The PM needs to manager time & materials suppliers very closely.

At the other extreme, a fixed price contract specifies the deliverables (including quality and time aspects), and the risk of delivery rests with the supplier. If they do not deliver what they promised, on time and to the required quality, then there will be financial penalties to the supplier (usually referred to as “liquidated damages”). In this case, the PM needs to closely involved in defining the contract terms, but once the contract is signed then it is important to take a step back and let the supplier get on with it. Ask questions relating to progress, but leave them to make their own decisions. Changes to requirements may be welcomed by the supplier, as there will be a price tag associated with each change, and you can be sure that they will be looking for a higher profit margin than on the base contract!

Most of all with a fixed price contract, don’t try to interfere. If you, as PM, try to direct the way the supplier acts — no matter how well-intentioned — then in the event of targets being missed the supplier can use the interference as a legal argument to escape penalties.

An interesting and emerging trend is for “open book” contracts. In this approach, once a supplier has been chosen then the risk is shared. It is accepted that the supplier needs to make a profit margin at an agreed rate, and all of their costs are then fully revealed. The PM works with the supplier to agree cost/time/quality decisions with the best project outcome being the primary concern of both parties. If you can get to this situation, it is an ideal way to balance risk.

By | 2015-08-19T10:54:45+00:00 May 13th, 2013|Project Management, Seven Essentials|1 Comment

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

ScrumMaster

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.


 

Update March 2015

I’ve been reading Essential Scrum by Kenneth Rubin. Interestingly the book contains a very similar table, but using the PMI’s 9 knowledge areas from PMBOK Version 4 (since superseded by a slightly different set in Version 5). Here is Ken’s analysis:

Mapping of Project Management Responsibilities in a Scrum Organization

Project Management ActivityProduct OwnerScrumMasterDevelopment TeamOther Manager
Integration??
ScopeMacro levelSprint level
TimeMacro levelHelps Scrum team use time effectivelySprint level
Cost?Story/task estimating
Quality????
Team (human resource)?Formation
Communications????
Risk????
Procurement??
Source: Essential Scrum, by Kenneth S. Rubin (Addison-Wesley, 2013)
By | 2015-08-19T10:54:45+00:00 April 30th, 2013|Agile, Project Management|4 Comments

The Fifth Essential: Team

In the first four essentials 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.

By | 2015-08-26T15:34:12+00:00 April 16th, 2013|Project Management, Seven Essentials|0 Comments