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 portfolo, as whole is still balance if you take this on
  5. The organisation can absorb the change.

So, the decision makers need to bbe 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’ll find a lot more about this in The Project Workout, section 3. 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 (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 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:

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 Project Workout chapter 16.

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 16 of the Project 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

Project management excellence is not enough

Beware of doing too many projects, even if they do fit your strategy and have a good business case.

Beware of doing too many projects, even if they do fit your strategy and have a good business case.

The opening plenary sessions of the 2013 Gartner PPM and IT Summit in London, set the tone for a mind-set shift in how Gartner looks at “IT management”.  To date they have focussed in on “IT” and the “CIO”, and, in my view, perpetuating the gap between what they term “IT” and the “Business” . This year, to my delight, they were starting to talk about “the business” and IT’s part in it. It’s a brave thing to do, but the right thing to do. Most organisations still have their IT split off as separate organisational units ,with a separate strategy and loads of money, which tries to work out what “the business” wants and then all too often fails to meet those expectations. What is guaranteed though, is if you give an IT department money, they will spend it all, even if the business need is unclear. . . . that’s the “business’” fault!

Mike Langley from PMI was a key note speaker and gave his view on the all important question of “how do we ensure our (IT) projects fit our strategy?”  Notice I put “IT” in brackets – the department is irrelevant as we want all our projects to align with strategy . . . don’t we?

Mike based his talk on PMI’s recent “Pulse of the profession” survey.

We are all familiar with “strategy” and “execution” (sorry for using the “e” word, but when at an American conference, you can’t get away from it!).  The story is that the business leaders set the strategy and then the “business” implements it. If it goes wrong, it’s usually the fault of the business and their dreadful requirements and poor implementation!  What new research for Harvard Business Review is now talking about is that implementation is part of strategy and we should not separate them. (look out McKinsey and Bain!.) After all, if your strategy doesn’t include how to implement itself, then it’s a poor strategy.  The new buzz words for making this happen is “portfolio management”. This is a discipline of making sure that the programmes, projects and other activities that a business decides to do are the rights ones in terms of strategic direction, fit and balance in terms of risk and skills use. It’s all about selecting the right projects.

Mike says his research shows that organisations which are good at portfolio management are more agile, and have better project outcomes. Portfolio management is integral to how the top level leaders want to manage their business; it’s an integral part of business planning. Traditional business planning adds up costs of departmental budgets, checks against revenue and makes sure there is “interlock” if different departments need to work together.  Usually this is done a year or so in advance and is therefore totally pointless for organisations in fast moving environments. It is however a neat and simplistic way to blame people when things go wrong or costs to much. Hence, getting portfolio management working right is as much to do with mind-set as having the processes, systems and operating model.

Getting this right, means organisations can continuously tune their plans, not be tied to outdated annual budgets and use their people and money where the benefit is most attractive.  The money will follow the business need, not the department doing the work. Now that is what I call true organisational agility and if you have read the Project Workout, it will be very familiar to you.

This isn’t new as a concept, but it is something many organisations struggle with.  Have a look at this article: Excellence is not enough from the Project Workout “articles” web page.

The secrets of successful programmes

CranfieldI recently went to the International Centre for Programme Management (at Cranfield) for a forum on learning and knowledge management  and as part of that we were given a white paper called “Beating the odds – the secrets of successful programmes”.

The white paper describes the findings from a recent two-year study of 21 major programmes of many types, with varying levels of success in a wide range of organisations in Europe. Those findings explain many of the causes of the differeing levels of programme performance and how business leaders can improve the success rate for their own organizations.

Seldom do I read an article or paper with the words “Yes, yes, yes” ringing in my head. It is packed with useful insights and wisdom, gleaned for the programme teams who took part in the study. The wisdom in this paper won’t be found in methods and processes, they are more about how experienced and skilled people apply them and the issues they face.

I recommend this to any person who considers themselves to be (or aspires to be) a business leader. As expected, there is lots about vision, strategic alignment, business readiness, foggy objectives, stakeholder engagement, business cases, planning and behaviours. If, as a business leaders, you believe you have a great strategy, then good for you. On its own, however, that is not enough. You need to be able to convert your vision and your strategy into action on the ground. Do you have the right mind set, tools, methods to do this?  Read this article and decide for yourself.

This is the executive summary:

  1. Strategic alignment. From the programmes studied, those identified as integral to the future business strategy were all at least partially successful. It could be concluded that the ‘positive’ nature of the programmes’ intentions meant that there was little stakeholder resistance to the initiative and hence the organisation was able to deploy its most capable resources. Senior management and executive involvement was sustained throughout the programme. Conversely those programmes that had primarily ‘reductionist’ intentions, e.g. restructuring to reduce costs or eliminate inefficiencies, were less successful. Executive involvement in the programmes was weak and stakeholders’ commitment quickly waned.
  2. Need and readiness. Interestingly and perhaps counter intuitively, in most of the successful programmes the need was ‘high’ – clearly recognised as a business priority – but initially the readiness was ‘low’. In these the argument for investment and change was endorsed at executive level and time and effort spent at the start to achieve the buy-in of the rest of the organisation and develop the ability to undertake the changes. In the majority of those that were partially successful the readiness appeared to be ‘high’ as well as the need. Why they were not entirely successful is best explained as over-ambition or even over-enthusiasm; rather too many optimistic assumptions were made at the start with little assessment of the potential risks involved.
  3. Value drivers,benefits and business cases. The more successful programmes were also based on a clear strategic driver plus a strong financial business case. Those with weaker strategic drivers but good financial cases gained less commitment and were usually less successful. Very often financial benefits were overestimated, while the risks and the problems in making the changes were underestimated, perhaps because realistic estimates might have made it difficult to secure funds and resources. During the programme, as the scope becomes clearer, this inevitably leads to changes to the costs involved and the benefits that can actually be delivered, but only a minority of organisations revisit the business cases as programmes evolve.
  4. Foggy objectives. Programmes cannot be fully planned in advance and have to adapt to both changing business conditions and programme achievements. This is not necessarily a comfortable position for senior management and requires a knowledgeable, accountable and empowered governance group to oversee and, where necessary, adapt the programme. Rather than decrease during the programme, uncertainty can often even increase, especially due to changes in the external environment.
  5. Planning. Some organisations thought they may have ‘over-planned’ things at the start, due largely to the demands of some stakeholders for detailed plans, which were then not really used. However, the planning activities were seen as essential to bring stakeholders together and for reconciling their different priorities and interests. The process of planning was more important than the plans produced and helped address many of the initial uncertainties.
  6. vision and stakeholders. Having a clear vision of the intended future business and organisational models and then allowing compromises and trade-offs in the detail of how they are implemented, is more likely to achieve stakeholder commitment than imposition. The successful transformation programmes usually addressed the organisational, people and capability aspects first, before dealing with the process and technology aspects. The less successful tried to do the reverse.
  7. Learning and un-learning. Most ‘strategic’ programmes require the development or acquisition of new capabilities and knowledge in order to be carried out successfully. Management generally underestimate how much has to be learned by the organisation and individuals to define, manage and implement a major programme. Introducing new ways of working may also require considerable ‘un-learning’ by large numbers of professional people – not easy to achieve without actually removing the old processes. If the programme relies heavily on the capabilities of suppliers (especially IT suppliers), they may exert undue influence over what is done – the scope and achievable benefits – rather than on how the programme can be successfully delivered.
  8. Realising the benefits. Most business change programmes involve at least two distinct and different phases – first to create a new capability and second to exploit it. In most of the cases the new capability, for example a global HR database or Finance & Accounting Service Centre, was created, but not always used effectively, hence the benefits achieved were often less than those originally envisaged. While creating a new capability can be done ‘off-line’, separately from business as usual, using and exploiting it often competes with other operational priorities or can have negative effects on other aspects of operational performance, as was observed in some of the cases.
  9. Organisation and governance. Programme governance structures and staffing profiles are likely to change significantly over the life cycle. There seem to be three basic approaches to organising programmes: (1) a separate task force, (2) as part of business-as-usual (BaU), or (3) a combination (matrix). Not surprisingly the last of these proves most problematic. Some programmes have dedicated change managers, others have senior managers assigned to the programme, but they can find it difficult to reconcile achieving change at the same time as sustaining performance. Running change programmes in parallel with BaU causes tensions within the organisation and a clear statement of priority for which takes precedence is essential.
  10. Portfolio management. Few organisations, as yet, have the capabilities in place to manage multiple concurrent programmes with varying levels of uncertainty, competing for the same resources over extended periods. No organisation in the study had an effective mechanism in place for managing a combined large portfolio of ‘strategic’ programmes and more traditional projects – although some are trying to address this issue. Managing multiple programmes (Programme Portfolio Management) requires an additional governance structure or regular strategic and operational review and reconciliation at executive level especially if there are programme inter-dependencies or contention for critical and scarce resources.

Do you want to know more?

Cranfield had very kindly let me make the full article available to you here

So why was I saying “yes, yes, yes,” to myself? Many of the lessons are embedded in the Project Workout:

  • vision, strategic alignment: are covered in the gated approach to projects, from the very beginning(Chapters 3 to 11)
  • portfolio management is covered in Project Workout as “Business Programmes” in Chapters14 to 17.
  • business readiness,is a prerequisite for Project Workout’s Ready for Service Gate (page 118)
  • foggy objectives,are discussed in Chapter 12, along with other types of “Eddie Obeng” projects
  • stakeholder engagement,is covered in Chapter 19 as well as threaded throughout the book
  • business case, is at the heart of the Project Workout’s business led approach
  • planning in Chapter 19
  • behaviours are covered in Chapter 18

Of course, in the “real world” these are not isolated activities but happen in a complex network of cause and effect and that is why it is all so difficult to do in practice.

What to do about ineffective sponsors

The sponsor's behaviours set the tone for everyone but are they always beneficial?

The sponsor’s behaviours set the tone for everyone but are they always beneficial?

Research from Scott Keller and Colin Price (McKinsey’s) in their book,”Beyond Performance: HowGreat Organizations Build Ultimate Competitive Advantage,” points to programme or project sponsorship as being the most critical factor in achieving project success. I agree with them. Unfortunately in organisations with low maturity in programme and project management, this role is often  totally missing, misunderstood or the behaviours promote the wrong outcomes. This doesn’t seem to be an uncommon problem. But what can you do about it? One writer, Peter Taylor, proposes that a PMO could act as a surrogate “sponsor” and be used to help senior executives understand and perform that role better.

Have a look at his full article here, and see what you think.

Now imagine, if sponsorship was done well, what a difference that would make: programmes and projects would link to strategy, be prioritised on the basis of business benefit and only done if the need or opportunity is compelling . . . even if money is left over in the annual budget!!! Perhaps we could even go as far as the funds being assigned to the projects themselves, rather than to departments (cost centres) doing the work; now there’s a thought. CFOs, pay attention! Also consider, how can “portfolio management” work, if the role of the sponsor is not understood?

Let me know your thoughts on this. Are the programme and project sponsors in your organisation effective? If so, how did you achieve that? If not, how are you tackling the problem? I think that this is one of the great challenges to improving programme and project performance; there is only so much the “middle” can do, the “top” needs to play their part too.

See also my blog, “Enemies within” in which I argue senior management get the peformance they deserve. Controversial, eh?

Is your parrot (I mean project) dead?

A risk register is sometimes not enough.Dead Parrot

Projects are not simple things to manage, even when there is a book, like the the Project Workout, to help you.  So, how do you know if your project is “healthy” and likely to meet the business objectives it was set up to achieve? How do you know it’s not well and truly dead, like the proverbial Monty Python parrot?

Well, a quick look at the risk log may help, together with a view on the issues. The schedule plan updates should show you how you are doing against your baselined plan. (what do mean you don’t have a baseline?)

These are all good ways to gain a feel; they are your day to day instruments. Sometimes, though, it’s good to rise above all the detail of methods, tools, reports and logs and consider in an holistic way, “Will this project really do what we need?”.

The Project Health Check

This is where the project health check comes in. It asks five searching question on each of the following areas of project management:

Project plan
Resources
Ownership
Justifiable case
Expertise
Clear solution
Targeted control

If anyone of those is not adequately covered, then your parrot may indeed be dying.

Let’s have a look at the output from an example:

Example of an output from the Health Check

Example of an output from the Health Check

Overall the tool’s analysis suggests the project is medium risk. Well, you might say, that’s ok, isn’t it? However, if you look at the problem areas you can see they relate to:
Solution – we don’t know what we’re building
Resources – we haven’t got anyone to do whatever it is
Expertise – we don’t fully have the expertise we need.

Now this cluster makes sense. All the management stuff is okay, but if we haven’t got the expertise for the specialist work, then perhaps that’s why we don’t yet have a solution. Also, if there is no solution yet, you can’t really know what resources you need.

So is it okay? If you are in the investigative stages of the project then, yes, you could be okay, assuming you take action to fill the gaps. If however, you are in the development stages or later, then your parrot is probably going to die.

As with all these types of tools, they are there to help you think and self-delusion in answering the questions will reinforce any delusional opinions. For that reason, it’s often good to do this type of assessment in groups and gain a consensus; the value of the discussion will far out weight the paper result.

When would you use this?

I suggest that you use at as an input to every gate decision to provide the decision makers with a summary of the ares which need attention. You can also do it “ad-hoc” in response to any concerns which have been raised.

Is it worth it?

Yes. One company I work ed with employed some consultants to review 12 of their most critical projects. The consultants used their own, very extensive, tools and check lists. When they’d finished their work they took this tool and applied it to all twelve projects. The found a full correlation. In fact, they said if the company had applied this tool first, as a filter, they could have saved 60% of the consulting fee as most of the projects were fine.

You can find the tool in the CD which accompanies the Project Workout.

Functional thinking destroys business value

In my blog, Enemies within, I highlighted 10 reasons why projects continue to

People get cross with each other and, often, it's not their fault.

People get cross with each other and, often, it’s not their fault.

fail, despite all the methods, standards and training we throw at our people.  basically business leaders get the project performance they deserve as most inhibitors are institutional. This is what I said:

Functional thinking – not taking the helicopter, the organisation-wide view. This often happens when executives’ or individuals’ bonuses are based on targets which are at odds with the organisation’s needs, e.g. sales bonus rewarded on revenue, regardless of profit or contribution.

Let’s look at another aspect of this – cost management.  Most organisations set their annual budgets, top-down, based on an expectation of revenue and costs. The costs then trickle down to cost centres and managers of departments of functional specialists, or other segments of the organisation They have a budget for the year to work within. Sounds familiar? On top of that we put time recording and ever more rigorous (onerous?) procurement systems – after all, we must be hard nosed business people and make sure we only spend what is needed. Finance people then monitor the costs and do all sorts of jiggery-pockery to deal with their fiscal needs, accruals, internal transfers, prudence concept etc.

All this budget setting is done for a financial year, 12 to 15 months in advance.

Actually, that approach can work well for steady state bureaucracies, where next year tends to look rather like last year. It is what most people are familiar with and yet, how many people, nowadays, work in such a predictable, steady state organisation?  What if you are in a fast-moving, unpredictable sector where you are not sure what will make up your order book and what mix of resources you will actually need? They also realise that they need to deal with cross-functional projects and so they “interlock” the demands of the projects with the cost centre budgets.

A budget set to  12 to 15 months in advance on this basis looks rather optimistic. So what happens is this:

  1. department managers spend their all budgets (so they don’t lose it next year) regardless of the overall business need – after all they are targeted on their cost spend.
  2. projects get starved of resources, as the mix of resources and costs change as work is won (if customer facing) or initiated (if for internal transformation). This can be despite the “project budget” having enough funds, as all too frequently the departmental budget takes precedence.
  3. project managers get cross with functional managers who unilaterally withdraw their resources, despite the project budget being adequate
  4. department managers get cross with project managers for not predicting exactly what they will need up to 12 to 15 months in advance.
  5. it becomes a blame game
  6. the company and customer suffer

Managers:

  • who exceed their budgets are told they are bad managers
  • who undershoot their budgets are told they are bad at forecasting
  • who hit their budgets are told the budget was probably not stretchy enough.

So how can you deal with this?  The first thing is to realise that the above scenario describes a matrix organisation, where resources are shared across many projects and business activities. If you have a matrix organisation, the controls of the simple bureaucracy (cost centres) are totally inadequate – you need to have a full, matrix infrastructure in terms of portfolio, programme and cost management and for resource planning and assignment:

  1. Manage the business across the organisation not down the cost centres
  2. Allocate budgets and funds to projects (or other cross-company entities) not to cost centres.
  3. Create governance which crosses, the organisation, taking power off the costs centre managers
  4. Only give cost centre managers funds for training, management, holidays, sickness etc.
  5. Have a rolling monthly forecast, spanning financial years (“interlock” resets half yearly or even quarterly of often not enough).
  6. Let any person work on any work, anywhere in the company.

Done right, you will have a flexible, self correcting organisation, which is simpler to run and focused on business value not discrete costs centres. You will have tipped the balance of power away from the “silo” cost centres towards managing business value across the organisation.

Want to know more?

See the Project Workout, 4th edition:

  • Chapters 14 and 15 on matrix governance
  • Chapter 16 on resourcing
  • Chapter 17 on matrix systems to make it work