Resource management: everyone is suffering

I was speaking at a PMI conference in Sweden, last March, which gave me the opportunity to sit in on a number of other sessions. This one is all about resource management, given by Peter Kestenholz.

If you are to be successful, you must have the right number of skilled people.

If you are to be successful, you must have the right number of skilled people.

A straw poll of attendees at the presentation found:

  • all work in a matrix organsiation;
  • 30% have clear resource management process;
  • 20% have tools to support resource management;
  • only 2% have been trained on the process and tools.

All of them had BIG issues with how resource management worked (or more accurately, didn’t work)  in their organisations. Some ignored it and others had enormous spreadsheets to try and get a grip on the issue of making sure the organisation has the resources to do the work that needs doing. By enormous, I mean at the limit of Excel as a tool. Yes, most use spreadsheets. It sounds dreadful!

Way back in 2010, Forrester said that there was a significant increase in investment of PPM tools specifically to:

  • Obtain an accurate view of resource usage;
  • Manage investment aligned to strategy.

Today, Gartner says the need for resource management is still one of the top three reasons companies invest in PPM tools. Not a lot has changed. The vision of many senior managers is that they should be able to “drill down” to get any information they need at the level they need it. . . . but few can do this.

Peter has been involved in helping a lot of organisations tackle the “resource issue” and went through a number of things to consider, namely:

  1. Have an executive sponsor define the business requirements for resource planning and transparency. Understand the rationale. Without this, don’t bother any further as this drives everything else.
  2. Be clear on what you mean by resource capacity. Net? Gross? Overtime? What is a FTE? What formula will you use for any calculation of resource capacity?
  3. Ensure, a person can have many skills associated with him/her.
  4. HR should own the Organisation Breakdown Structure; hold them to account for keeping it up to date. An out of date structure will break your process. Ensure any tooling can cope with the continuous churn of organisation structures and people allocations.
  5. Decide how many different jobs a person can be forecasted to work on. Be clear if people can be asked for by name? by role or by skill (or  any of these).
  6. Get rid of your spreadsheets! However, people are used to using these, so consider tools with a similar (and hence familiar) look and feel.
  7. Ensure your approach deals with leavers and joiners. For example, be able to forecast a person’s assignment even though they haven’t joined the organisation yet.

You can read more about enterprise wide resource management and tooling in Chapter 14 of The Programme and Portfolio Workout.

What is a “stage-gate”?

More management jargon?

Do you come across people using the term “stage-gate”? If so, are you sure they really understand what they are talking about? Do they understand what this term means and where it comes from? All too often, I find people use as the term as yet another piece of management jargon and don’t really understand it (just like “workstream”!)

This is the type of muddle people come up with:

Example A starts well, in that there are a number of stages depicted. Unfortunately we know nothing about where the decision points are. Where does the project start or end? Also, the stages are called “stage-gates”, further confusing things.

Bad practice A

 

Example B has the same issues as example A except that a number of decision points have been added. This, however, doesn’t clarify matters much, for example, is stage gate 1, the first stage of the project or the activity before the project starts?

Bad practice B

 

Example C has all the issues raised in examples A and B, except in this case it seems the decision points (gates) are labelled as “stage-gates”.  I wonder what the stages are called – gate-stages? Notice the numbering, which infers that the “gates” are decisions at the end of a stage, rather than decisions to start a new stage.

Bad practice C

Where it came from.
“Stage-gate” is actually a registered trademark devised by Robert Cooper, to describe his stage-gate process for new product development. If you do a web search for R G Cooper or “stage-gate” you’ll find lots of good articles. If you read them, you’ll see that there is no such thing as a “stage-gate”; it is simply the name he gave to his new process.  Like my own work on project management, he talks about “gates” and “stages” as being different but related.

Depicting project life cycles
In the Workout books I use circle, arrow and diamond icons to ensure that the above mistakes do not happen. This form of iconography is now enshrined in the British Standard (BS6079), international standard (ISO 21502:2020) and UK government standard (GovS 002). If you haven’t seen them, then you really should get a copy.

  • A circle depicts activities which happen before a project starts or after it is completed.
  • A diamond represents a gate.
  • An arrow represents a stage.

Like this extract from a figure in the Project Workout:

Extract from the Project Workout.

 

Summary

So, if you are designing a project life cycle for your project, don’t fall into the real-life traps highlighted in the bad examples above above; make sure you understand the difference between a gate and a stage; avoid “stage-gate” (you might have to pay royalties!) and make sure your depiction of the life cycle is clear and unambiguous.

More help?

  • Books: Chapter 4 of the Project Workout tells you all about project life cycles, helping you to design one that works for your situation. Chapters 6 to 12 describe the detail for each stage and then in Chapter 13 it tells you how you can tailor it. The Programme and Portfolio Workout covers this in Chapters 8 and 9
  • Articles: You’ll also find some articles you can download from the community pages of my projectworkout.com site, including one I did for AXELOS on PRINCE2 life cycles.
  • Video: Here are some mini-videos taking you through the project lifecycle in the Project Workout
  • Click for yourself: you can investigate the model in the video above yourself. Go to the Companion site page in my projectwout.com site.
  • Another blog on the topic: Lifecycles and fuzzy back-ends.

Do poor project sponsors drive failure?

I was speaking at a PMI conference early in Sweden in March, which gave me the opportunity to sit in on a number of other sessions. This one is all about programme and project sponsorship. It is a topic close to my heart and one I have blogged on before and no doubt will again . . . but is is a topic that business leaders actually care about?

In programmes and projects, sponsorship is not like sponsoring Tom to run a Marathon. Do too many business leaders believe it is someone else's job?

In programmes and projects, sponsorship is not like sponsoring Tom to run a Marathon. Do too many business leaders believe it is someone else’s job?

On the point of sponsorship, here are the key messages Peter Taylor gave out at his presentation on sposorship:

  • 85% of organisations had sponsors in place
  • 83% of organisations don’t train/support/guide sponsors
  • 100% of respondents believed that having a good sponsor was key to project success.

PMI’s recent Pulse of the profession showed that those organisations with active sponsors are more likely to have better project outcomes. This is supported by Colin Price’s research (McKinsey). Standish believes ‘The most important person in the project is the executive sponsor. The executive sponsor is ultimately responsible for the success and failure of the project’. I agree.
BUT most spend business leaders spend less than 5% of their time on sponsor related activity, yet this is all about making change happen – leading change. . . . and mismanaging change is the commonest reason CEOs get fired.
If you look at project failure, six reasons are cited and the top FOUR of those come under the accountability of the sponsor.

  • 40% Unrealistic goals
  • 38% Poor alignment of project and organisation objectives
  • 34% Inadequate human resources
  • 32% Lack of strong leadership
  • 21% Unwillingness of team members to identify Issues
  • 19% Ineffective risk management

So despite all this wealth of research and learning, many business leaders continue to ignore the issue or treat it informally. Everyone says they believe it is critical to project success and yet:

  • Sponsors are not ‘trained’ to be effective
  • Sponsors do not have the ‘time’ to be effective
  • Sponsors are just expected to ‘know’ how to do the job.

Is that right?
Is it even worth bothering about?

Peter then showed some broad-brush estimates of the value of good sponsorship:

  1. Meeting Project Goals +29% variance with good sponsorship in place
  2. Project Failure -13% variance without good project sponsorship in place

So if you have a £1bn portfolio, the range of benefits and costs is:
+ £290m
– £130m
Peter argues that those figures are certainly worth thinking about.I certainly agree. I also wonder that if senior leaders are only spending 5% of their time on sponsorship, what are they actually doing and who do they think is looking after the future of the business?

You can see Peter’s paper here – Project managers are from Mars, project sponsors from Venus

Change, communications and sponsorship

Since the Project Workout was first published, I have advocated projects as the vehicles for achieving strategic objectives or as I often say, projects are the vehicles of change. When I first wrote this in the late 90s, most people were still focused on deliverables and outputs, but, I am pleased to say the drive to towards benefits driven project management as standard is gaining momentum. This blog picks up on Steve Delgrosso’s views.
PMI’s Pulse of the Profession reviews are really starting to focus on the outcomes from projects being the most critical thing from senior management a senior management viewpoint (hurray!). Steve DelGrosso, from PMI, gives his views on what the priorities need to be, if organisations are to keep pace with the escalating rate of change. In his view, these are:

  • Priority One – communications
  • Priority Two – sponsor engagement

This mirrors McKinsey’s Colin Price’s findings about the essential role of the project sponsor in his book, Beyond Performance Management. It also mirrors the view that to be effective, senior management must not only have a vision, but also be able to communicate it.
A look at PMI’s research shows that organizations report that only 52 percent of their strategic initiatives are successful. The failure of strategic initiatives has a significantly greater financial impact than just project failure: they say that nearly 15 percent of every dollar spent on strategic initiatives is wasted–US$149 million for every US$1 billion spent. By comparison, PMI’s 2014 Pulse of the Profession® study finds that US$109 million is wasted for every US$1 billion invested in projects.

So, not much seems to have changed since David Munt, founder of GenSight, did a similar study in 2002. His research suggested between 35 and 50 per cent of all investment is directed to unsuccessful projects and that about 30 per cent of project investment by FTSE 100 organisations in 2000 actually destroyed shareholder value!
Strategic initiatives are the programmes and projects though which an organization’s strategy is implemented. By their nature, strategic initiatives drive change to transform an organization from current state to future state.
Failed projects can result in huge financial losses for an organization, but a failed strategic initiative has an impact far beyond just the costs of the initiative. When an organization embarks on change, it’s likely that systems, processes, vendors and perhaps even the overall organizational mindset (or mission) will be impacted. Failure to successfully enable sustainable change can lead to an organization losing its competitive advantage.

Select the right projects to support your strategy Selecting the right projects will help you achieve your objectives by realising benefits which support your strategy.

Select the right projects to support your strategy

I have a feeling there will be a lot more blogs on this topic as it challenges the prevalent “iron triangle” or “triple constraint” view of project management, and builds on it. Developers of standard and proprietary methods take note! In the meantime, have a look at The Project Workout, Chapter 3, page 50 and Chapter 15, page 198, in particular.

No white space = unhealthy company

In an earlier blog I talked about the three necessary conditions if you are to manage your resources effectively (see Link). Resource management is a hot topic in many companies and is the primary driver for them implementing programme and project management systems.

In this blog, I’ll talk about what I refer to as “white space” and why, if you haven’t got this, your company or organisation is in an unhealthy state.  So what is “white space”? The gap between what your resources are committed to and the total resource you have available is ‘white space.’ It is the resources that you have not yet committed to a given activity or project. If you fulfil conditions 2 and 3 from my earlier blog, you will know your white space:

White space = resources available – resources already committed

In the very short term this should be small. It will grow as you look further into the future.
White space is fundamental to a organisation’s on-going health. If you haven’t any in the short to medium term, you are paralysed. You have no one available to change the business to meet new threats or exploit new opportunities unless you withdraw them from previously committed work. White space gives you the resources to effect change in the future.
‘We are in a fast moving environment’ is the common mantra nowadays. If this is truly the case, then you need to ensure that you have ‘white space’ resources ready to meet future needs. You know the people will be required but you are not yet sure exactly what for. If you have no people to change things, things won’t change.

White space must cater for two distinct needs:

● First, it must cover the need to undertake initial investigations from new proposals. People must be available at very short notice to do these and must be highly knowledgeable if the investigations are to have any value.
● Second, you need the resources to undertake the future projects or work.

Compare the former to a company putting a bid together – if this is done by inappropriate people, the timing of when bid and what bids are needed is unpredictable, the bid may be lost or the company may have committed itself to a financial disaster. Just because business projects are  ‘internal’ it does not mean you need not apply the same rigour as you would with external matters. It’s your organisation’s future at stake in both cases.

White space

The figure represents ‘white space’ in graph form. It could apply to a complete organisation, a division, a function or whatever. However, unless you can build this picture you will be taking risks every time you need to set off another initiative.

One of the challenges I have found is that many organisations plan on an annual basis and the financial controllers insist that every work item for the year is itemised and budgeted for, believing that this will ensure efficiency; they simply won’t allow “white space” and expect managers to have 20:20 forecasting vision . . . even in a fast moving environment.  White space is what enables an organisation to be nimble, fast moving or agile (choose your own buzz word).

You can find out more about resourcing in Chapter 14 of the Programme and Portfolio Workout.
 

Portfolio management – the next frontier?

Earlier this month I was speaking at the “Passion for Projects” conference in Sweden. I must say it was a really well organised event and I was delighted to have been invited to speak there. The topic I chose to talk about covered portfolios, project, projects, matrices and maturity. I’ll go into it more in some later blogs. I’ll assume you know a little about portfolio management. Just to recap, portfolio management is all about making sure you pick the right projects to do.  In “The Project Workout” i call them “business programmes” as at the time I wrote the book, the term “portfolio” hadn’t really settled down in the way it has now.  So, in portfolio management you have to make decisions on what to do and which meet the following criteria:

  1. It is aligned to your strategy
  2. You have the resources to undertake it and operate its outcome
  3. The risks are acceptable  (i.e. robust business case)
  4. The portfolio, as whole is still balance if you take this on
  5. The organisation can absorb the change.

So, the decision makers need to be able to make those decisions and have the data available to verify the criteria.

I was asked a question about this: “If a programme has been approved as part of a portfolio, has the programme sponsor the authority to authorise the project within the programme, or do they all have to be referred to the decision maker at portfolio level?”

My instincts were that if the programme as a whole has been approved, then the programme sponsor should be able to make the decisions . . . however it is not that simple. It all comes down to shared impact. For example, if the programme team has all their own “ring-fenced” resources, then they can make decisions relating to criteria 2. If they share resources with other programmes or components of the portfolio, then they can’t. Similarly, if they are the only ones impacting a “target user group” (change absorbtion) then they can verify criteria 5. If niot, then the decision has been elevated.

Further, the degree of to which there is knowledge of the programme, its resources and impacts at the time it was approved also matters. It may be that the first chunks of work are pretty weel known and as long as these stay in the bounds expected, decision making can be at programme level.

As you see, what appears to be a simple question is actually very complex. The more you ring-fence resources, the greater you can delegate decisions to programme sponsors but, you lose potential efficiencies for using those resources on other work. It’s a balance. Whatever you choose, remember:

  1. What ever you do must align with your strategy
  2. There is little point in authorising work that cannot be undertaken – in fact it is really damaging
  3. You need to ensure the risks of adding this to your work-stack are acceptable
  4. You nee to ensure your portfolio remains balanced, when you add the new work in
  5. There is little point in doing work, which the operational teams, customer etc cannot accommodate in terms of change.

You can read a lot more about this in The Programme and Portfolio Workout. Many organisations are only just starting to “get it”; it’s all applied common sense.

Lessons from history

Korean fortressIf you read about the history of “project management” you will usually be told how it emerged in the early twentieth century in response to particular needs (blah blah blah).

However, at an ISO meeting last week, in Sweden, the South Korean delegate, Young Min Park,  brought us all to heel by showing a video. Basically, he took ISO 21500:2012 (Guidance on project management) and mapped it against the historical records of the construction of Hwaseong Fortress in Korea . . . and he found that most of the processes described in ISO21500:2012 were practiced all those years ago . . and there is documentary evidence to support this (have you done your post-project review yet?).

His video is a delight and shows that it is the practices that matter, not what we call them (although as you all know, having consistent words does help communication!). So sit back and enjoy the video; it’s only four minutes long, but is derived from the detailed project management records still held in the Royal archives in Korea.

Video: Historical project tells about project management

My thoughts:

  • It would seem my Korean edition of Project Workout is a few hundred years late!
  • If you want to see my cartoons on Roman project management (fictional, of course) and learn more about ISO21500:2012 and its successor ISO21502:2020, see the “Community” pages in my Project Workout web site.

Is a functional hierarchy fit for modern day businesses?

 

The functional hierarchy is not the only way to run a business.

The functional hierarchy is not the only way to run a business.

If what people do counts more than the function or department they belong to and if, for reasons of efficiency, you want to use people to best effect anywhere in your organisation, what is the role of the functions? You know that no change, which is significant to a whole business, can be made within a single function in an organisation. You generally require people from a number of areas contributing to the processes, activities and projects you are undertaking.

In the traditional hierarchy, each head of function decides not only the strategic direction of their function, but also what each and every one of his/her  employees will do and how it will be done. The danger, if functions are too dominant, is that they will drive the business as they see fit from their own perspective. This may not be in line with the drivers that the organisation’s leadership wants to effect. The outcome is that the organisation becomes out of balance.

For example, efficiency is often seen as a good goal. So is responsiveness to customer needs. However, the latter may require you to carry excess capacity in order to meet customer needs at short notice. If one function is driving ‘efficiency’ up by reducing capacity while another is creating a proposition around responsiveness there is likely to be a mismatch and dissatisfied customers.

The projects approach, like the trend towards cross-business processes, aligns all the required skills and capabilities around the attainment of a business objective. In the case of a process, the objective is better operations. In the case of a project, the objective is change for the better. Thus, the functions are not leaders in driving the business, but rather suppliers of people and expertise to projects and processes. The accountability of a head of function is to ensure that the right people are available in the right numbers to service the business needs. They will be accountable for pay, employee satisfaction and personal development. Other key roles will start to become apparent. There will need to be those, expert at particular disciplines, who will create strategy, develop and maintain technical architecture, manage projects, or manage people. However, they will not do this just in the context of a single function, but rather in the context of the complete organisation, working wherever needed across functional boundaries to achieve the business objectives . . . . and that is where project portfolio management (or what Project Workout calls “business programmes”) comes in.

 For more on resource management see The Programme and Portfolio Workout chapter 14.

Getting (and holding onto) your resources

The University of Southern California analysed 165 teams in a number of successful organisations to assess the effectiveness of team-work. Two reasons for teams failing to deliver were found:

●  Project objectives were unclear.

●  The right people were not working on the project at the right time.

In looking for solutions to these two issues, they found that using a ‘projects approach’ gave significant benefits in clarifying objectives (which is just as well or it would conflict with the message in the Project Workout!). On the question  of resources, they found  that having  visibility  of available resources and obtaining commitment for the required resources was key. In other words, if you haven’t got the right people at the right time (numbers and skills) you can’t expect to complete your project. It’s all rather obvious, isn’t it?

You need ALL your resources to succeed.

You need ALL your resources to succeed.

As I suspect many of you know, obtaining resources and holding on to them can be very problematic, especially in functionally oriented organisations, where the balance of power  is  firmly held  by line  management. In  these circumstances, resources are often committed to projects on the basis of good intention, rather than on good information. Consequently, they can be withdrawn by the owning department, at whim,  if it believes that its own need is greater than that of the project. The result is that resource and skill shortages do not become apparent until they are a problem.

An effective method of resource allocation and commitment is needed, therefore, which meets three conditions:

  • Condition 1 – you have a clear view of how resources are being consumed on a project by project basis.
  • Condition 2 – you have visibility of the resources available, or soon to be available, within the forecasting horizon of your organisation.
  • Condition 3 – commitment of resources should be based on clear information and forms the basis of an ‘agreement’ between the departments providing the resources and the projects consuming the resource.

Meeting these conditions will enable you to anticipate potential resource conflicts before they become a problem. How do you do that? Well, it all relies on how the governance for your organsation is designed, the project manager cannot normally solve this one.  I’ll cover this in later blogs, but in the meantime, you can find out more about resourcing in Chapter 14 of the Programme and Portfolio Workout.

Thoughts from the Gartner PPM Summit – risk

One of the key note speakers at the Gartner PPM Summit in London this year was Professor Bent Flyvberg of Oxford University. His talk was about “Why your IT project might be risker than you think”.  In this he summarised the outcomes of some research covering over 4000 projects, from a range of industries, with differing durations and sizes.  The first stunning finding was that, contrary to common belief, IT projects were no more risky that engineering projects – the median for cost overrun is about the same. “Good”, you might think. However that may be a premature conclusion to jump to. What they also found was that if an IT project goes out of control, then it really goes awry – big time. Further, IT projects were 100 times more likely to go out of control. It’s all to do the statistical distribution and “outliers”. Now this sounds more like the story our guts were telling us . . . . but worse.  These outliers are termed “black swans”, on the basis that you rarely see black swans (except if you live in New Zealand, of course).

Now all sectors have “black swan” projects, but the IT sector really seems to have some issues. Despite the projects being far shorter in duration, the IT “black swan projects” have significantly higher costs over runs.  This led the research team to look at a few more hypotheses:

Bigger projects are riskier than smaller ones – WRONG, they found that the risk of “cost” black swans decreased with project size.

Longer projects are riskier than shorter ones – TRUE, longer projects are riskier, especially after 3 years

Lack of benefits management is the single most important deficit in IT project performance management – TRUE, benefits management significantly reduces risk.

Using Agile methods lower project risks – TRUE .  . . but only for schedule risks, not for costs or benefit. (A bit obvious that one, as agile is predicated on a fixed timescale!).

The problem with the above is that the challenge is how to deal with the Black Swans, bearing in mind the significant impact they have. One approach is spot them early, but when is that? When is a “black swan” hatched.  Their research should four situations:

  1. As soon as a vendor has been contracted – watch those contract claims go through the roof! About a fifth are like this.
  2. When the system is being specified, after which the costs stabilise. This covers about a half of the black swan projects.
  3. Just under 10% look great right up until actual development starts and then the escalations come in.
  4. That leaves just under a fifth, which are actually starved to death.

The best early warning indicator is people insisting a project is really unique. “Unique” and “Black Swann” go together very well. Further the research indicates that the best time to look at a project is 15% of the way through; they believe that by this time the die is cast and a review may catch the renegade project before it does too much damage to the organisation.

Here is some advice and references if you want to take this further:

  • Benchmark against your previous projects, your perer industry and best practice.
  • Know your own uncertainty and risks
  • Improve resource allocation and eliminate knck on effects.
  • Scrutinize your plans.
  • Know how likely estimated costs, benefits and schedules are to actually materialise
  • Quantify project viability under different scenarios
  • Reduce the front end bias of your projects.
  • Identify and eliminate delusion, deception and black swan blindness
  • Quantify unknown unknowns
  • Think carefully about reducing scale
  • Reduce technical and social complexity
  • Learn from “master builders” who have a proven track record.

References:

  1. From Nobel Prize to Project management getting risks right. PMJ, 37(3) pp 5-15
  2. “Why your IT project might be riskier than you think” HBR, 89 (9) pp 23-25