PMBOK #5 standardises its approach to planning

The PMBOK® Guide has always been designed for large projects, and assumes intelligent project teams will scale back the processes appropriately for smaller projects. The 5th Edition keeps this focus and introduces a standard process to ‘plan the planning’ at the start of each knowledge area. This concept has been embedded in earlier editions of the PMBOK, it’s made explicit in the 5th Edition.

Why plan the planning?

As a starting point, on larger projects there will be a significant team of experts involved in developing various aspects of the project plan, on $ multi-billion project frequently more than 100 people so their work needs planning and controlling the same as any other aspect of the project. With a budget of several $ millions and the success of the rest of the project dependent on the quality of the project planning this is important work.

But planning the planning and developing an effective strategy for the accomplishment of the project’s objectives is critically important on every project. If you simply do what you’ve always done there is very little likelihood of improvement. Spend a little time overtly thinking about what needs to be done to first develop the best project plan and then to manage the project effectively can pay huge dividends.

The overriding consideration in developing the plan is Juran’s quality principle of ‘fit for purpose’ you need a plan that is useful and usable that has been developed for the lowest expenditure of time and effort.

To facilitate this, the PMBOK now has process to ‘plan the management’ of: Scope, Time, Cost, Quality, HR, Communication, Risk, Procurement and Stakeholders. These planning processes develop outputs that are integrated within the overall project management plan and describe how each of the specialist areas will be managed. The management plans include the policies, procedures and documentation required for the planning, developing, managing and controlling of each discipline.

Less well developed are two key aspects that can contribute significantly to project success:

• Within the ‘PMBOK’ there is a real need to coordinate and integrate different aspects of the planning. Decisions in one area frequently impose constraints on other disciplines and managing these constraints across multiple sub-teams is vital if the objective of a coordinated and integrated project plan is to be achieved. The project core team need to set parameters for the specialists to work within, possibly at a ‘planning kick-off meeting’ and then manage issues as they arise.
• On a more general level, and applicable to projects of all sizes, there is a need to formulate the project delivery strategy before any realistic planning is possible. Answering the question ‘what’s the best way to achieve our objectives?’ frames the project planning and later the delivery. In software development choosing ‘agile’ over ‘waterfall’ as the delivery strategy changes everything else (for more on managing Agile see: Thoughts on Agile). The project objective of functioning software can be achieved either way, which strategy is best depends on the specific circumstances of the project (See our earlier post on project delivery strategy)

Certainly asking the team to think about what is needed to optimally plan, develop and deliver each knowledge area, will contribute to project success. Maybe the 6th Edition will take the integration of these processes forward.

See our other posts on the PMBOK® Guide 5th Edition.

To buy a copy in Australia see: http://www.mosaicprojects.com.au/Book_Sales.html#PMI

What’s the Probability??

The solution to this question is simple but complex….

There is a 1 in 10 chance the ‘Go Live’ date will be delayed by Project 1
There is a 1 in 10 chance the ‘Go Live’ date will be delayed by Project 2
There is a 2 in 10 chance the ‘Go Live’ date will be delayed by Project 3

What is the probability of going live on March 1st?

To understand this problem let’s look at the role of dice:

If role the dice and get a 1 the project is delayed, any other number it is on time or early.
If you role 1 dice, the probability is 1 in 6 it will land on 1 = 0.1666 or 16.66% therefore there is a 100 – 16.66 = 83.34% probability of success.

Similarly, if you roll 2 dice, there are 36 possible combinations, and the possibilities of losing are: 1:1, 1:2, 1:3, 1:4, 1:5, 1:6, 6:1, 5:1, 4:1, 3:1, 2:1. (11 possibilities)

The way this is calculated (in preference to using the graphic) is to take the number of ways a single die will NOT show a 1 when rolled (five) and multiply this by the number of ways the second die will NOT show a 1 when rolled. (Also five.) 5 x 5 = 25. Subtract this from the total number of ways two dice can appear (36) and we have our answer…eleven.
(source: http://www.edcollins.com/backgammon/diceprob.htm)

Therefore the probability of rolling a 1 and being late are 11/36 = 0.3055 or 30.55%, therefore the probability of success is 100 – 30.55 = 69.45% probability of being on time.

If we roll 3 dice we can extend the calculation above as follows:
The number of possible outcomes are 6 x 6 x 6 = 216
The number of ways not to show a 1 are 5 x 5 x 5 = 125

Meaning there are 216 combinations and there are 125 ways of NOT rolling a 1
leaving 216 – 125 = 91 possibilities of rolling a 1
(or you can do it the hard way: 1:1:1, 1:1:2, 1:1:3, etc.)

91/216 = 0.4213 or 42.13% probability of failure therefore there is a
100 – 42.13 = 57.87% probability of success.

So going back to the original problem:

Project 1 has a 1 in 10 chance of causing a delay
Project 2 has a 1 in 10 chance of causing a delay
Project 3 has a 1 in 5 chance of causing a delay

There are 10 x 10 x 5 = 500 possible outcomes and within this 9 x 9 x 4 = 324 ways of not being late. 500 – 324 leaves 176 ways of being late. 176/500 = 0.352 or a 35.2% probability of not making the ‘Go Live’ date.
Or a 100 – 35.2 = 64.8% probability of being on time.

The quicker way to calculate this is simply to multiply the probabilities together:

0.9 x 0.9 x 0.8 = 64.8%

These calculations have been added to our White Paper on Probability.

Value is created by embracing risk effectively

The latest briefing from the real ‘Risk Doctor’, Dr David Hillson #75: RESOLVING COBB’S PARADOX? starts with the proposition: When Martin Cobb was CIO for the Secretariat of the Treasury Board of Canada in 1995, he asked a question which has become known as Cobb’s Paradox: “We know why projects fail; we know how to prevent their failure – so why do they still fail?” Speaking at a recent UK conference, the UK Government’s adviser on efficiency Sir Peter Gershon laid down a challenge to the project management profession: “Projects and programmes should be delivered within cost, on time, delivering the anticipated benefits.” Taking up the Gershon Challenge, the UK Association for Project Management (APM) has defined its 2020 Vision as “A world in which all projects succeed.” The briefing then goes on to highlight basic flaw in these ambitions – the uncertainty associated with various types of risk. (Download the briefing from: http://www.risk-doctor.com/briefings)

Whilst agreeing with the concepts in David’s briefing, I don’t feel he has gone far enough! Fundamentally, the only way to achieve the APM objective of a “world in which all projects succeed” is to stop doing projects! We either stop doing projects – no projects – no risks – no failures. Or approximate ‘no risk’ by creating massive time and cost contingencies and taking every other precaution to remove any vestige of uncertainty; the inevitable consequence being to make projects massively time consuming and unnecessarily expensive resulting in massive reductions in the value created by the few projects that can be afforded.

The genesis of Cobb’s Paradox was a workshop focused on avoidable failures caused by the repetition of known errors – essentially management incompetence! No one argues this type of failure should be tolerated although bad management practices mainly at the middle and senior management levels in organisations and poor governance oversight from the organisation’s mean this type of failing is still all too common. (for more on the causes of failure see: Project or Management Failures )

However, assuming good project management practice, good middle and senior management support and good governance oversight, in an organisation focused on maximising the creation of value some level of project failure should be expected, in fact some failure is desirable!

In a well-crafted portfolio with well managed projects, the amount of contingency included within each project should only be sufficient to off-set risks that can be reasonably expected to occur including variability in estimates and known-unknowns that will probably occur. This keeps the cost and duration of the individual projects as low as possible, but, using the Gartner definitions of ‘failure’ guarantees some projects will fail by finishing late or over budget.

Whilst managing unknown-unknowns and low probability risks should remain as part of the normal project risk management processes, contingent allowances for this type of risk should be excluded from the individual projects. Consequently, when this type of risk eventuates, the project will fail. However, the effect of the ‘law of averages’ means the amount of additional contingency needed at the portfolio level to protect the organisation from these ‘expected failures’ is much lower than the aggregate ‘padding’ that would be needed to be added to each individual project to achieve the same probability of success/failure. (For more on this see: Averaging the Power of Portfolios)

Even after all of this there is still a probability of overall failure. If there is a 95% certainty the portfolio will be successful (which is ridiculously high), there is still a 5% probability of failure. Maximum value is likely to be achieved around the 80% probability of success meaning an inevitable 20% probability of failure.

Furthermore, a focus on maximising value also means if you have better project managers or better processes you set tighter objectives to optimise the overall portfolio outcome by accepting the same sensible level of risk. Both sporting and management coaches understand the value of ‘stretch assignments’ – people don’t know how good they are until they are stretched! The only problem with failure in these circumstances is failing to learn and failing to use the learning to improve next time. (For more on this see: How to Suffer Successfully)

The management challenge is firstly to eliminate unnecessary failures by improving the overall management and governance of projects within an organisation. Then rather than setting a totally unachievable and unrealistic objective that is guaranteed to fail, accept that risk is real and use pragmatic risk management that maximises value. As David points out in his briefing: “Projects should exist in a risk-balanced portfolio. The concept of risk efficiency should be built into the way a portfolio of projects is built, with a balance between risk and reward. This will normally include some high-risk/high-reward projects, and it would not be surprising if some of these fail to deliver the expected value.”

Creating the maximum possible value is helped by skilled managers, effective processes and all of the other facets of ‘good project management’ but not if these capabilities are wasted in a forlorn attempt to ‘remove all risk’ and avoid all failure. The skill of managing projects within an organisation’s overall portfolio is accepting sensible risks in proportion to the expected gains and being careful not to ‘bet the farm’ on any one outcome. Then by actively managing the accepted risks the probability of success and value creation are both maximised.

So in summary, failure is not necessary bad, provided you are failing for the ‘right reason’ – and I would suggest getting the balance right is the real art of effective project risk management in portfolios!

Why are schedules failing?

There seems to be fairly wide consensus that the modern practice of scheduling is not delivering the results needed to help projects succeed.

My feeling is that with a few notable exceptions the underpinning ideas of the Critical Path Method (CPM) of scheduling developed in the 1950s and 60s have been forgotten and most software and most scheduling practice uses ideas from the 18th century.

The concept of Bar Charts was developed in the 18th century (or possibly earlier). Joseph Priestley (1733-1804) published his ‘Chart of Biography’:

He is quoted as saying “…a longer or a shorter space of time may be most commodiously and advantageously represented by a longer or a shorter line.”

A few years later a full range of modern charts were published by William Playfair (1759-1823) in his ‘Commercial and Political Atlas’ of 1786:

By the end of the 19th century sophisticated barcharts appear to have been in general use (at least in Europe – the project below was built in 1910):

For more on the early development of scheduling see A Brief History of Scheduling.

Henry Gantt developed his production management systems for factories in the early part of the 20th century with a range of charts designed as production monitoring and control tools:

Importantly Gantt did not use simple bar charts and had no interest in one-off projects. He was focused on machine shop efficiency and production quotas:

For more on his work see: Henry L. Gantt – A Retrospective view of his work.

CPM and PERT were invented in 1957 as computer based analytic models:

Importantly, in both systems, planning the logic and entering the information into the computer precedes calculating the schedule. Both CPM and PERT used ADM networks:

The ‘precedence diagram’ (PDM) network was published in 1961 as a simplified manual process to make CPM available to people without access to expensive mainframe computer time – in the PDM system as published drawing the logic diagram also precedes calculating the schedule.

There is no question CPM offered significant advantages over the traditional bar charts that had been in use for more that 100 years. In my view, the major advance that generated the improved project outcomes was the need to think through the work logically, focusing on the activities and sequence of work before any attempt to schedule the project was possible. This was equally true of both the mainframe systems and the manual systems in use through the 1960s and 70s. James Kelley (co-inventor of CPM) had a very similar view.

The same concept of good practice is embedded in the PMBOK® Guide. The separate processes in the 5th Edition are:
6.1 – Plan schedule
6.2 – Define Activities
6.3 – Sequence Activities
6.4 – Estimate Resources
6.5 – Estimate Durations
6.6 – Develop Schedule
6.7 – Control Schedule

CPM was recognised as an improvement on bar chart planning! So my question is: If CPM scheduling is supposed to be a logical process why do so many scheduling tools default to, and planners work from, 250 year old Bar Charts? Is this the cause of scheduling failures?

There are tools around that default to creating the schedule logic in a network diagram but they are in the minority. I will be discussing one of these at the Construction CPM conference in New Orleans later this month (see: http://www.constructioncpm.com/). Micro Planner X-Pert is a true CPM System that supports the PMBOK® Guide schedule development process:

And lets you chose the networking style PDM or ADM:

For more on Micro Planner see: http://www.microplanning.com.au/

But back to the key question, is scheduling failing through lack of skills and training, a lack of knowledge, poor techniques focused on 250 year old bar charts or some other reason?

The 15,000 articles a month downloaded from our planning resource page, suggest a strong interest in planning and scheduling but this interest does not seem to be reflected in the status or planners or project outcomes. I look forward to the discussions….

Communication!

The recently released Sixth edition of the APM-BoK consists of four major sections: context, people, delivery and interfaces. Typical ‘hard’ project management processes such as scope, schedule, cost, resource, risk, integration and quality comes in the section focused on delivery. This is after the section concerned with people and interpersonal skills and the first area featured in the APM-BOK under the people area is communication. The APM-BoK recognises that communication is fundamental to the project management environment, and makes a very powerful statement: “None of the tools and techniques described in this body of knowledge will work without effective communication”.

To an extent the PMBOK is playing ‘catch-up’ with other key standards including the Association of Project Management (UK) Body of Knowledge (APM-BoK) 6th Edition and ISO 21500. The good news is all three standards now see identifying the important stakeholders in and around a project or program and then communicating effectively with each stakeholder as the fundamental driver of success.

The recently released Sixth edition of the APM-BoK consists of four major sections: context, people, delivery and interfaces. Typical ‘hard’ project management processes such as scope, schedule, cost, resource, risk, integration and quality comes in the section focused on delivery. This is after the section concerned with people and interpersonal skills and the first area featured in the APM-BOK under the people area is communication. The APM-BoK recognises that communication is fundamental to the project management environment, and makes a very powerful statement: “None of the tools and techniques described in this body of knowledge will work without effective communication”.

The PMBOK® Guide 5th Edition has followed PMI’s standard practice of retaining existing chapters and adding new sections at the back so the positional prominence in the APM-BoK is not possible. However understanding the changes between the 4th and 5th Editions and comparing these to ISO 21500 does show the extent of the increased focus in the PMBOK on communication and the stakeholders you communicate with.

MANAGE STAKEHOLDERS

This is a new section in the PMBOK® Guide 5th Edition (Chapter 13). It is based on two processes moved from the communication section of the 4th edition and has been expanded.

Identify stakeholders is a beefed up version of the same process in the 4th Edition, focused on understanding who the project’s stakeholders are.

Plan Stakeholder Management is a new process that describes how the stakeholder community will be are analysed, the current and desired levels of engagement defined and the interrelationships between stakeholders identified. It highlights the fact that levels of engagement may change over time.

Manage stakeholders remains basically the same as in the 4th Edition and is similarly defined in ISO 21500.

Control Stakeholder Management is a new process that ensures new stakeholders are identified, current stakeholders are reassessed and stakeholders no longer involved in the project are removed from the communication plan. The process requires the on-going monitoring of changes in stakeholder relationships the effectiveness of the engagement strategy, and when required, the adaption of the stakeholder management strategy to deal with the changed circumstances.

As with ISO 21500, the early parts of the PMBOK discussing the management or projects in organisations also has a strong emphasis on stakeholders (Chapters 1, 2 and 3).

COMMUNICATIONS MANAGEMENT

This section of the PMBOK® Guide 5th Edition has been consolidated and expanded and is very similar to ISO 21500 in its effect.

Plan Communications remains basically unchanged, the key input is the stakeholder analysis.

Manage Communications is a new process that amalgamate the 4th Edition processes of Distribute Information and Report Performance, and in doing so removes a lot of unnecessary confusion. This new process goes beyond the distribution of relevant information and seeks to ensure that the information being communicated to project stakeholders has been received and understood, and also provides opportunities for stakeholders to make further information requests. ISO 21500 has an interesting additional function (not in the PMBOK) which is the management of the distribution of information from stakeholders to the project in order to provide inputs to other processes such as risk management.

Control Communications is a new process that identifies and resolves communications issues, and ensures communication needs are satisfied. The outputs are accurate and timely information (resolved communications issues) and change requests, primarily to the communication plan.

Summary

Communication is the means by which information or instructions are exchanged! Communication is the underpinning skill needed to gather the information needed to make project decisions and to disseminate the results from all of the traditional ‘hard skills’ including cost, time, scope, quality and risk management. Good communication makes these processes effective, whereas poor communication leads to misunderstood requirements, unclear goals, the alienation of stakeholders, ineffective plans and many other factors leading to failure.

The common theme across all three standards is that communicating the right information to the right stakeholders in the right way (and remembering communication is a two-way process) is fundamental to success. The basic requirement is to deal effectively and fairly with people, their needs, expectations, wants, preferences and ultimately their values – projects are done by people for people and the only way to influence people is through effective communication.

Project communication skills include expectation management, building trust, gaining user acceptance, stakeholder and relationship management, influencing, negotiation, conflict resolution, delegation, and escalation.

What’s really pleasing to me is how similar these ‘standard’ requirements are to the ideas embedded in my Stakeholder Circle®methodology, books, blogs, White Papers and tools. I have no idea how much influence my writings have had on the various standards development teams but it is pleasing to see a very common set of ‘best practices’ emerging around the world. Now all we need is the management will to implement the processes to improve project and program outcomes.

Who Manages Benefits?

I attended the Benefits Realisation Summit in Sydney earlier this week which was focused on two significant ‘launches’ – the Australian launch of Managing Benefits, the official reference guide for the APMG qualification of the same name and the launch of the Maximiser benefits management software:
- See more on Managing Benefits
- See more on Maximiser

Managing Benefits will require a couple of posts over the next couple of months to cover the depth of information available to organisations to achieve the best return on their investments in projects and programs, and my contribution to the Benefits Realisation Summit was focused on understanding the links between stakeholders, the overall value chain, and the organisation’s project delivery capability (download the presentation).

The area of discussion I found most interesting at the summit was around the roles and responsibilities of the different managers involved in realising benefits and creating value. As a starting point there was a very good definition of the stages involved in creating value, based on the concept of developing a new retail shop:

• The output from the project to build the shop is a fitted out facility.
• The outcome from the staffing and stocking of the shop is a shop selling goods to customers.
• The benefit realised from the shop is the monthly profits from sales.
• The value created by the new business is its potential ‘sale price’ which is usually calculated as a multiple of the annual earnings (typically somewhere between 5 and 12 times the annual profit).

The realisation of the value outlined above requires a ‘chain’ of decisions and management actions:

• The chain starts with decisions around the type of shop, its location, size, etc. The overall value chain is discussed in The failure of strategic planning and the front end processes in Linking Innovation to Value.
• Once the optimum project has been selected, the organisation then needs to be capable of efficiently delivering the project and creating the required output. Project Delivery Capability (PDC) is discussed in White Paper WP1079.
• Once the project’s outputs are created, the requirement to make efficient use of them within the organisation requires effective organisational change management; this facet of the value chain is discussed in WP1078.
• Then, assuming the original concepts used in the business case were accurate, the intended benefits are realised and value is created.

Within all of these stages, the key to creating the intended value is effective benefits management; this is the focus of the Managing Benefits book and the objective of the Benefits Realisation Summit.

Maximising the benefits realised from a project or program is not a solo effort, it requires the effective cooperation of a number of managers with defined roles and responsibilities operating effectively as a team:

Each of the managers above has a distinct role to play:

• The Senior Management Grouphave ultimate responsibility for generating value from the organisation’s investment in a project:
  • The role of senior management and portfolio management in the pre-project phase is ensuring the right projects are selected for the right strategic reasons
  • Once the project has transitioned its output into operations, the senior management group responsible for the operation of the organisation’s business-as-usual processes need to make effective use of the deliverable to realise benefits and as a consequence, generate the intended value.
• The Sponsor is the senior manager responsible for taking ownership of the business case, approving the Project Charter once the organisation has agreed to fund and resource the project and ensuring the project’s outputs are effectively transitioned into operations and used effectively. The role of the sponsor is discussed in WP1031. From a benefits realisation perspective, the Sponsor (or Senior Responsible Owner – SRO) is the manager with primary responsibility for ensuring the intended benefits are realised. The sponsor may fulfil the role of benefits owner personally, or liaise with the designated benefits owners to ensure the benefits are realised (the benefits owner is the person responsible for the realisation of a specific benefit).
• The Sponsor is supported by two specialist managers:
  • The Project Manager responsible for the efficient delivery of the project and
  • The Change Manager responsible for managing the organisational change needed to make use of the new product, process or service.
• The role of the Benefits Manager is partially advisory, and partly an assurance role. The Benefits Manager should be responsible for developing an effective set of metrics supported by a system for identifying and measuring benefits (planned and realised) and should also be responsible for validating the realised benefits (see more below).

The relationship between the project and change managers
Change management and project management are different skills requiring different training and different personality types. Both roles are critical and should support the sponsor in achieving the best possible transition of the project’s outputs into operations.

During the life of the project the project manager is assisted by the change manger to ensure the project delivers the most useful output, the change manger also works on preparing the organisation for the change. The focus is creating the ‘right’ outputs as efficiently as possible and this is primarily a project management function.

During the critical transition phase the focus changes, the project manager’s role should shift to focus on helping the change manger to ensure the projects deliverables ‘work’ in the organisational setting. The project manager will also be working on project closure during this period but this should be secondary to ensuring the planned benefits are capable of being realised.

Throughout the whole process, the change manger is primarily responsible for facilitating the organisational change aspects of the initiative including of all of the processes involved in embedding the new product, process or service within the organisation and supporting its adoption through to the point where it is functioning as a normal part of the organisation’s ‘business-as-usual’ capabilities. This may require some level of support for two or three years after the project has finished.

The effect of programs and program management
Programs are created to manage the work of several projects in a coordinated way, may include some operational work for a period and many are set up specifically created as organisational change agents. The different types of program are outlined in WP1022.

If a project is a component of a program, the program manager is responsible for creating the project and is usually acts as the project’s sponsor. The program is responsible for the change management processes as part of its core integration and coordination functions and the program sponsor has overall responsibility for the return on investment in the program.

The roles and responsibilities of the Benefits Manager
The concept of a Benefits Manager is relatively new. The Benefits Manager provides a benefits realisation support service to sponsors, program managers, change managers and benefits owners. Some of the functions include:

• Develop, maintain and progressively enhance the benefits measurement system used by the organisation.
• Provide scrutiny of each business case to assure the organisation the benefits claimed are realistic and achievable within the proposed timeframes.
• Lead the benefits identification and mapping processes for project and programs.
• Assisting with the development of the benefits realisation strategy and plans for projects and programs.
• Help with the identification and optimisation of additional benefits, dis-benefits and assess the impact of changes from the benefits realisation perspective.
• Tracking and reporting on the actual realisation of benefits by the organisation.

This is an important role both from the facilitation perspective and the assurance perspective. People with a vested interest in the value of benefits proposed or realised should not be the people measuring their value; this is an untenable conflict of interest. The Benefits Manager provides independent assurance that the benefits proposed in the benefits realisation plan have been achieved to the extent defined in the plan, at the time defined in the plan and any variances are identified and explained or understood. For more on assurance see WP1080.

Conclusion
Benefits cannot be managed directly; they are a consequence of other management actions and decisions. An organisation will maximise the benefits actually realised by maintaining a focus on benefits from the early stages of project initiation right through to the point where they are fully realised by the operations of the changed organisation.

Productivity decline should generate more projects

Projects and programs are the key organisational change agents for creating the capability to improve productivity through new systems, processes and facilities. But only if sensible projects are started for the right reason.

Declines in productivity seem to be widespread. In Australia, labour productivity in the market sectors of the economy increased at 2.8% per annum between 1945 and 2001, reducing by 50% to an annual rate of 1.4% between 2001 and 2001.

• The measure of Labour Productivity is the gross value added per hour of work.
• The ‘market sectors’ measured exclude public administration, education and healthcare where measurement is almost impossible.

Some of this change can be attributed to macro economic factors, there were massive efficiency gains derived from the shift from paper based ‘mail’ and copy typist to the electronic distribution of information, improved global transport systems (particularly containerisation) and the restructuring of manufacturing post WW2. These massive changes in the last half of the 20th century are not being replicated in current.

Whilst this decline in the rate of improvement in labour productivity is significant, the capital inclusive index is a more telling statistic. The multi-factor productivity index which includes the capital invested in production, giving a purer measure of the efficiency with which labour and capital are combined to produce goods and services. In the six years leading up to 2001, this measure of productivity grew by an average of 1.5% per annum, in the decade between 2001 and 2011 this reversed and productivity fell by 0.4% per annum.

Around 40% of the decline in the last decade can be explained by massive investments in mining and utilities that have yet to generate a return on the capital invested. The other 60% represents the massive cost of ‘new capabilities’ in general business for relatively small, or no improvement in productivity.

One has only to look at the ever increasing number of ‘bells and whistles’ built into software systems ranging from high definition colour screens to features that are never used (and the cost of upgrading to the ‘new system’) to understand the problem. 90% of the efficiency gain came with the introduction of the new system many years ago, the on-going maintenance and upgrade costs often equal the original investment but without the corresponding improvement in productivity. Another area of ‘investment’ for 0% increase in productivity is compliance regimes. Whilst there may be good social arguments for many of these requirements, the infrastructure and systems needed to comply with the regulations consume capital and labour without increasing productivity.

In Australia general management have been rather slow to appreciate the challenge of declining productivity, the impact being cushioned by a range of other factors that helped drive profitability. But this has changed significantly in the last year or so. There is now an emerging recognition that productivity enhancing organisational change is an imperative; and smart management recognise this cannot be achieved through capability limiting cost reductions.

Organisations that thrive in the next decade will:

• Enhance customer satisfaction and service,
• Enhance their engagement with their workforce, the community and other stakeholders,
• Enhance their products and capabilities, and
• Improve their labour productivity.

Achieving a viable balance across all four areas will require an effective, balanced strategy supported by the efficient implementation of the strategic intent through effective portfolio, program and project management capabilities that encompass benefits realisation and value creation.

The three key capabilities needed to achieve this are:

• The ability to develop a meaningful and practical strategic plan.
• An effective Project Delivery Capability (PDC); see: WP1079_PDC.
• An effective Organisational Change Management Capability; see: WP1078_Change_Management.

Improving productivity is a major challenge for both general management and the project management community; and the contribution of stakeholder management and project management to the overall effort will continue to be a focus for this blog.

Linking Innovation to Value

In a recent post looking at the The failure of strategic planning  and the overall value delivery chain centred on projects and programs, the link between innovation and the strategic plan was raised briefly. The purpose of this post it to take a closer look at this critical ‘front end’ of the value chain because it does not matter how well you do the wrong projects! The ability to generate sustainable value for an organisation’s stakeholders requires the right projects to be done for the right reasons; and yes, they also need to be done right!

The section of the ‘value chain’ leading into a portfolio management decision to select a project or program as a viable investment is far more complex than the section after. Once a project or program has been selected, it needs to be accomplished efficiently, the outputs transferred to the organisation and the organisation adapt to make efficient use of the ‘deliverables’ to realise the intended benefits and generate value. This flow of work is primarily the responsibility of the project/program sponsor initially supported by project and program management, and then by organisational ‘line management’ until the final transition to ‘business as usual’ operations.

Developing a business case to the point where it can be accepted for investment is more complex, involves a wide spectrum of managers and potentially involves a number loops.

The three elements in this section of the overall ‘value chain’ are a viable strategic plan, a realistic business case that supports an element of the strategy and an effective portfolio management system to optimise the overall portfolio of projects and programs the organisation is capable of investing in.

The key is an effective and viable strategic planning process that is capable of developing a realistic strategy that encompasses both support and enhancements for business as usual, and innovation. Strategic planning is a complex and skilled process outside of the scope of this post – for now we will assume the organisation is capable of effective strategic planning.

The sign of an ineffective, unresponsive strategic planning process is seeing business cases fired off by business units without any reference to the strategic plan or worse projects being started without strategic alignment. The option to bypass the strategic planning may be valid in an emergency but not as a routine option. In a well disciplined value creation process, the portfolio management team simply reject business cases that cannot demonstrate alignment with the organisations strategic intentions. The red arrow in the diagram above simply should not be allowed to occur in anything other then an emergency situation.

The Portfolio/Strategic link (blue arrow)
There is a close link between the portfolio management processes  and strategic planning – what’s actually happening in the organisation’s existing projects and programs is one of the baselines needed to maintain an effective strategic plan (others include the current operational baseline and changes in the external environment). In the other direction, the current/updated strategy informs the portfolio decision making processes. The strategic plan is the embodiment of the organisation’s intentions for the future and the role of portfolio management is to achieve the most valuable return against this plan within the organisation’s capacity and capability constraints.

Routine inputs to the Strategic Plan (light green arrows)
The routine inputs to the strategic planning process come from the ‘organisation’ and include requirements, opportunities, enhancements and process innovations (eg, new software releases). These basic inputs are the core information required for strategic planning and form the majority of the new information in each update of the strategy.

The Innovation / Strategic Plan loop (light blue arrows)
This is the first of the more complex spaces – innovative ideas can come from anywhere in the business and are actively encouraged by leading organisations such as Google and 3M. Conversely, an organisational objective may require innovation to allow it to come to fruition. One of the most challenging objectives in recent times was Kennedy’s commitment to “before this decade is out, [land] a man on the moon and return him safely to earth.” The amount of scientific innovation required to achieve this objective was incredible.

The organisation’s governance processes and strategic development processes need to both encourage innovation whilst recognising that not every innovative idea will be appropriate for the overall development of the organisation. This requires the implementation of systems to encourage innovation, collect and sort innovative ideas and move the ‘right’ ideas into the strategic plan, where necessary revising and changing the plan to grab the innovative advantage.

The Feasibility loop (orange and yellow arrows)
Having innovative ideas and creative business cases is one thing, validating the feasibility of an idea is altogether different! The ability to test, validate and work-up innovative ideas into practical project specifications is a critical organisational capability. On mega projects the pre-feasibility and feasibility studies may in fact be significant projects in their own right involving considerable expenditure, feeding back to a gateway or portfolio management process to allow the next stage of the project to commence.

Several of the ‘gateways’ defined in most standard ‘gateway processes’ precede the commissioning of the main project and the organisation needs the capability to make informed decisions based on good quality information. This aspect of the value creation chain is industry specific and may be a central function or distributed across different business centres. What matters is the capability exists with the necessary skills to validate ideas and design projects ready for the more traditional project management processes to take over once the project is formally authorised.

Conclusion
The long term viability of any organisation depends on its ability to innovate. Traditional project and program management focus on doing the selected projects/programs ‘right’. But it is the ‘front end’ processes discussed in this post leading up to the investment decision that determine if the ‘right’ project is being selected for the ‘right’ reasons!

The effective governance of an organisation should require its management to invest sufficient skills and resources in these ‘front end’ processes to ensure a steady flow of innovative ideas, feeding into an effective and flexible strategic planning system, linked to a disciplined portfolio management process; to ensure the optimum mix of ‘right’ projects and programs are commissioned and supported.

The failure of strategic planning

Projects struggling for management support are one of the key indicators of a sub-standard value creation system that is failing to make full use of the deliverables created by projects and programs. But the problem is likely to be much deeper; surveys consistently show that between 15% and 80% of projects undertaken by organisations cannot be linked to the performing organisations strategy. These ‘ferrel projects’ are either symptoms of inadequate governance, or symptoms of inadequate strategic planning!

In many organisations, and particularly in business areas focused on system support such as IT the typical path taken by an innovative idea through to some confused delivery of value is a straight line from the innovation, to a business case, to a project that has to seek management support and the surviving projects eventually deliver their outputs to a bunch on unprepared and unwilling end users. The generation of value is far from certain!

Over the last few years, Portfolio Management has started to emerge. Portfolio management should have a strategic focus and make selections based on strategic priorities but in most current implementations tends to be a process oriented, stand alone function. Certainly by applying capacity constraints the number of projects that fail due to lack of organisational resources will be reduced but the focus on value creation is minimal. Management support and organisational change are not central to the process. There is literally a ‘fence’ between the executive ‘strategic planning’ processes and innovation within the organisation.

Most authorities describe project and programs as the ‘change agent’ responsible for creating the ability to implement strategic initiatives to grow and improve the organisation. For this to occur, the strategic planning system needs to be far more engaged with the organisation and central to the process of innovation, guided and supported by the organisations executive!

Within a value driven framework, the strategic planning process should be central to innovation, initiating work to develop prospective ideas, and receiving all of the innovative ideas to enhance the organisation from every source. Innovative organisations such as Google actively encourage innovation and experimentation within parameters but have careful selection processes before burning money on significant projects. They are also prepared use the innovative ideas to inform strategy, and to take significant strategic risks if an innovation warrants the speculation on a ‘whole new future’ for the organisation.
Within this framework, the evolution of the strategic plan is a cyclical process, possibilities and ‘blue sky’ ideas are communicated to the governing body, who formulate, review and update the overall strategic guidelines as new ideas and possibilities emerge.

However, my feeling is there is a tactical level missing from strategic thinking that will be needed for this process to work effectively. The overarching ‘strategic guidance’ needs to be fairly stable and take a long view and only be updated as needed (possibly twice a year). Based on this strategic guidance, a detailed strategic plan is developed at a ‘tactical level’, to frame the current implementation of the strategy. This process needs more rigour and more flexibility (the two are not mutually exclusive) compared to the high level plan, should only take a medium term view and be updated continuously. Based on this plan, feasible ideas that support the strategy are authorised for the development of a value oriented business case.

The creation of this flexible but rigorous tactical-level strategic process would place the ‘plan’ at the forefront of processes such as Portfolio Management and virtually eliminate ferrel projects.

Portfolio management also has a central role to play in developing strategy. The current strategy informs the portfolio selection process, and information on current projects and programs, the viability of assessed business cases and other consolidated information is absorbed back into the strategic planning process. Based on these factors, the key job of the portfolio managers is to select the most strategically important business cases, within the capability and capacity limitations of the organisation, for initiation as projects or programs, and cancel or modify projects that no longer align with the evolving strategic plan.

The role of management is firstly to implement the executive guidance by supporting the Portfolio Management processes and the selected projects. More importantly, management is also responsible for managing the organisation so that the necessary change initiatives are implemented to make effective use of the project deliverables to generate valuable returns over the life of the initiative, frequently a period of many years!

Developing a value driven system similar to the one described in this post is primarily a governance issue. The organisations directors and executives need to lead the process and be closely involved in the strategic management of the organisation.

Strategic planning also needs to evolve from a fluffy ‘high level’ process to a far more useful function that actually sets the strategy for the organisation’s management to implement. Within this framework, the organisations governance systems and leadership need to ensure their management support the process and are focused on creating value.

The Value Chain

However, the value creation chain is only as strong as its weakest link, which includes effective strategic planning supported by effective governance that ensures management support for the overall process. A clear indication the strategic governance processes are not working is when projects and programs have to fight to receive executive support to ‘exist’ and the organisation’s measure of success is limited to the ‘iron triangle’ of time, cost and scope focused at the end of the project.

Successful organisations focus on the more difficult, but more important measures of benefits realised and the value created for the organisation as a result of the project deliverables being used by the organisation to support its strategic initiatives and generate lasting improvements.

Most of the work needed to make this process work is in management areas outside of the traditional Portfolio, Program and Project management (PPP) arena. But no organisation will achieve the optimum results from its PPP initiatives without the front and back ends of the overall value chain being of equal ‘strength’.

This is not rocket science, many successful organisations, particularly in mining and engineering achieve this type of integration in their core business. For more on the governance aspects see: Mosaic WP1073 – Project Governance.  

For more on the overall project delivery capability see: Mosaic WP1079 – Project Delivery Capability.

Project Assurance

Effective project and program governance requires a carefully measured balance between prudent and effective risk taking, allowing skilled project teams the flexibility to tailor and improve processes to enhance success and effective surveillance to ensure the organisation’s objectives are being achieved.

An excessive focus on ‘due process’ stifles innovation and improvement and can easily lead to ‘process induced failure’ where every one focuses on producing the correct document in preference to dealing with the information contained in the document… There is absolutely no point in being able to say that ‘every risk that adversely affected the project had been identified in the risk register’, if the risks could have been avoided by proactive management.

Good project management, good business management and good governance requires appropriate and timely action to mitigate or remove risks that can sensibly be managed, and recognition of the fact that the decision to take action is risky because there is no certainty the risk being mitigated would have occurred anyway: there is always a probability a risk won’t occur! Similar issues requiring balanced decision making occur across the full spectrum of project and program management.

Balancing the cost of action against the possible cost of inaction requires good business judgement; the definition of ‘good judgement’ being, ‘you are right more often than you are wrong’; not the ridiculous expectation of perfect foresight (it does not exist), nor systems that are biased in favour of ignoring preventative actions until it is too late.

The role of project surveillance systems should be focused on this type of issue assuring the organisation’s senior management and other stakeholders that their project and program management teams are making the best decisions to protect and enhance the overall value of the projects and programs to the organisation. ‘Due process’ is important, but only to the extent it either assists the decision making process or provides information that is required by law or regulation.

Our new White Paper ‘Proactive Project Surveillance’ looks at the different types of review and the way they can be structured to both assist the projects and programs being reviewed to generate value for the organisation whilst providing assurance to the organisation’s executives and stakeholders that the projects and programs are being managed effectively.

You can download the White Paper from: http://www.mosaicprojects.com.au/WhitePapers/WP1080_Project_Reviews.pdf