The Evolution of Project Management

The publication of the PMBOK® Guide sixth edition at the beginning of September[1], and the decision last week by ISO committee TC258 to revise ISO standard 21500 should mark the end of an era in the development of project management. For most of the last 50 years, the dominant view of project management associations has been that project management is a generally transferable skill. This has resulted in the view that ‘project management’ can be represented by a single ‘BoK’ (Body of Knowledge), a single ‘competency baseline’ and capability can be demonstrated by passing a single credential or certification. However, whilst the PM professional associations have advocated this view, the job market has always retained a focus on different industry experience – you don’t get an IT project manager’s job without IT experience.

As outlined above, from the emergence of ‘modern project management’ in the 1960s[2] the predominant view of the professional associations and most academics and practitioners has been that ‘project management’ is a single discipline with transferrable skills. A single qualification framework is appropriate and the skills and techniques are generally applicable across all industries.  However, in the years between the 1960s and the 2000s, as different industries and disciplines progressively adopted the concept of ‘project management’ this holistic view has become increasingly stressed.

The future suggested in this post still sees project management as a single discipline focused around some high-level objectives; but rather than having a single set of generally accepted good practices applicable to most projects most time, the emerging discipline needs to be capable of embracing a range of different approaches to project management and a diverse toolbox of techniques that can be mixed and matched to optimise the creation of the project’s deliverables.

Project management literature has identified at least three key dimensions to project management:

1. An ‘adaptive/agile’ approach -v- a disciplined structured approach.
2. The size, scale, and difficulty associated with the work of the project.
3. Simple relatively predictable projects -v- complex projects with emergent properties.

In addition to these parameters (mapped in the diagram above), there is also the degree of certainty associated with the work, the technical complexity of the product, and the attitude of the stakeholder community[3].

It’s time for a change.

The project management techniques needed to manage different types of project vary enormously; for example:

• The optimum approach to managing a relatively small, simple project to upgrade a website may benefit from an adaptive/Agile approach to managing the work and should only require a ‘light touch’ to control the work;
• Contrast this to the disciplined approach needed to design and build a new chemical plant where not only do complicated parts need to be manufactured to precise dimensions months in advance and shipped halfway around the world, but the work has to be carefully managed and the parts assembled in a precise sequence to allow all bits to be fitted together properly in a safe working environment.

Both these endeavours are projects, but the project management techniques needed for success are dramatically different. Even within the one project, some elements may benefit from an ‘agile’ approach to the work (eg, systems integration), while other elements of the work will require a very disciplined approach to achieve success – building space rockets really does require ‘rocket science’.

The challenge facing the project management profession and project management academics is first defining the common core of project management, and then adapting the approach to developing and documenting the overall project management body of knowledge in a way that recognises the core commonality of being ‘a project’ whilst allowing different approaches to the management of the work. And once these foundations are in place, flowing these concepts through into documented standards, knowledge frameworks and certifications. In the 21^st century a ‘one size fits all’ approach to the management of projects is no longer appropriate.

PMI has started down this path, they have agile certifications and have included both tailorability and agile concepts into the 6^th edition of the PMBOK® Guide. Developments in the ISO space are also moving towards this integrated but separated approach to managing different types of projects. ISO 21500 Guidance on Project Management, is being updated and transformed into a higher level ‘management standard’, if this development is successful, in the future a series of implementation guides can be foreseen focused on different types, sizes and phases of project development and delivery.

What’s missing at the moment is a holistic and agreed understanding precisely what a project actually is[4] (this will segregate project management from other forms of management), and then a framework for distinguishing the different types of project that exist within the overall frame of being ‘a project’, but requiring different styles of project management. Some of the multitude of factors that need to be considered include:

• The inherent size of the project usually measured in terms of value;
• The degree of technical difficulty in creating the output (complication) caused by the characteristics of the project’s work and its deliverables, or the time-frame the deliverables are required within;
• The degree of uncertainty involved in the project;
• The degree of complexity associated with the work and the stakeholder relationships;
• The difference between client project management and contractor project management;
• The various methodologies and strategic approaches to managing the project and developing the product (Agile, PRINCE2, etc);
• The maturity of the environment in which the project is being delivered (developing economies/organisations -v- mature economies/organisations); and
• The difference between project, program and portfolio management.

The common core

The core element of all projects is the intentional ‘temporariness’ of the team (organisation) set up to deliver the project. The ‘temporary organisation’ is given an objective to create a deliverable for a client and then to shut down efficiently; in addition, there is an intention on the part of most key stakeholders to treat the work as a ‘project’. This means the project has to be started (initiated), the work planned, then undertaken, and on completion the temporary organisation has to be closed – and of course, all of these activities need monitoring and controlling.

Where 21^st century project management needs to diverge from the doctrines of the last century is in the way these overarching objectives are achieved – defining 44 or 49 processes as ‘generally accepted best practices’ is no longer appropriate.  The concept of ‘project management’ needs to be able to adapt to very different approaches, allow the project team to select from a toolbox of ‘useful techniques and methodologies’ and then encourage the teams to craft the processes they actually use to optimise the delivery of the project’s outputs to its clients.

Achieving this will require a different approach to developing standards, a different approach to training and qualifying practitioners and the creation of very different communities within the profession that encourages cohesion whilst embracing diversity of practice.

It will be interesting to see if our profession is up to the challenges.

_____________________________

[1] PMBOK® Guide 6^th Edition available in Australia: https://mosaicprojects.com.au/shop-pmbok-guide-6th-ed.php

[2] For more on the origins of ‘modern project management’ see: http://www.mosaicprojects.com.au/PDF_Papers/P050_Origins_of_Modern_PM.pdf

[3] For more on the dimensions of project management see: http://www.mosaicprojects.com.au/WhitePapers/WP1072_Project_Size.pdf

[4] For more on defining a project see: https://mosaicprojects.wordpress.com/2016/08/11/seeking-a-definition-of-a-project/

Workflow Management

Many projects involve repetitive elements of work that take some inputs, run them through a series of processes and deliver an integrated output.  Standardising these elements of project work can create efficiencies and minimise errors.   A couple of examples include normal ‘sprints’ in an Agile project and the monthly updating of the plans and reporting in a major project. Workflow management sit one step above individual processes (particularly standard operating procedures) linking them into an optimum sequence of work.

Workflow management means to oversee the creation of a deliverable from beginning to end. The management aspect is to be able to identify the people who need to be involved in each process within the work flow and to ensure the ‘flow’ allows for input from all required parties in the right sequence. The key questions that need answering to create a productive workflow are:

• What is the optimum sequence of processes?
• Who needs to be involved in each process? This includes knowing what inputs are required to start the work and what outputs are produces to finish the work.
• How to keep the momentum going within each process and the overall workflow (and the timely identification of blockages)?

A workflow can be simply designed on a piece of paper (or white board) to show the flow, who is responsible for each process and how the tasks are accomplished; or automated.

 

An example of an automated workflow management tool from http://www.comindware.com/tracker/

The key advantage of developing and using a workflow is you can expect similar results from the accomplishment of the work at each iteration, even if the people involved change. It reduces errors and provides consistent results.

Agile projects use the concept of ‘done’ at the end of a sprint. A common definition of done ensures that the increment produced at the end of sprint is of high quality, with minimal defects. Teams define the series of steps needed to reach ‘done’, and implement them routinely through each sprint. The steps to get to ‘done’ may include:

• Code Complete
• Unit tests written and executed
• Integration tested
• Performance tested
• Documented (just enough)

Build these steps into a workflow and everyone benefits – particularly if the workflow is reviewed and updated to incorporate learned experience on a regular basis. The art is to keep the workflow as simple as possible but not so simple that it becomes simplistic.

So next time you wade through the tasks needed to create your monthly report or any other repetitive job within the overall management of a project think about documenting the work flow – it will pay dividends over time.

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.

Project or Management Failures?

Google ‘reasons for project failure’ and you get nearly 5 million responses! The question this blog asks is how many project failures are caused by project management shortcomings and how many failed projects were set up to fail by the organisation’s management?

The Project Delivery Capability (PDC) framework described in our White Paper Project Delivery Capability (PDC) offers a useful lens to separate the failings generated by project performance from those imposed on the project, inadvertently, or otherwise by organisational management.

The list below separates the root cause of failure into four categories based on this model:

Initiation: failures associated with project identification, business case development, requirements definition and portfolio selection; including establishing initial realistic time and cost budgets based on pragmatic risk assessments.

Project: failures associated with the project team failing to apply effective project management processes as defined in resources such as the PMBOK® Guide, ISO 21500 and PRINCE2

Support: failures associated with the lack of effective senior management support to the project (Capability Support), including inadequate sponsorship, failing to provide appropriate resources, inadequate business inputs, lack of direction/decisions and allowing excessive change.

Benefits: the failure to realise the intended value from the project’s deliverables associated with poor organisational change management, end use adoption and cultural resistance (for more on the overall scope of change see our White Paper, Organisational Change Management).

The table below is based on an amalgamation of dozens of lists found through a Google search.

Reason for Failure	Cause
Inadequate business case A good business case will clearly demonstrate the business benefit of delivering a project and define the objectives, requirements and goals.	Initiation
Undefined objectives and goals This is always a problem, if the organisation does not know what it wants, it is impossible to scope a project to deliver the ‘unknown’.	Initiation
Inadequate or vague requirements This is only a problem if the organisation fails to allow adequate time and appropriate contingencies in the overall scope of the project to define and firm up requirements. Defined requirements are essential for the project to be able to deliver a successful outcome.	Initiation
Unrealistic timeframes and budgets; unachievable objectives Fact free planning is always a problem. Initial ‘rough order of magnitude’ estimates need appropriate contingencies in the initial business case. The project outputs need to be feasible.	Initiation
Lack of prioritisation and project portfolio management Causing competing priorities leading to inadequate support and resourcing for projects.	Initiation
Estimates for cost and schedule are erroneous Estimates should be based on solid foundations. Unrealistic targets are unlikely to be achieved.	Initiation / Project
Failure to set and manage expectations Unrealistic expectations are unlikely to be fulfilled. From the start of the initiation through the life of the project effective communication to set and maintain realistic expectations is vital.	Initiation / Project
Business politics Lack of discipline within executive/senior management. Only present is the organisation is poorly governed and lacks a rigorous portfolio management process. Selected projects should be supported by management.	Initiation / Benefits
Cultural and ethical misalignment Misalignment between the project team and the business or other organization it serves will inevitably cause problems.	Initiation / Benefits
Lack of a solid project plan The failure to develop an effective project plan guarantees the project will fail. The type of planning required depends on the project methodology. Some specifics are included below	Project
Poor estimating Failing to use historical information, formulae, and questions to make sure that the estimate is not a GUESStimate.	Project
Poor processes/documentation Appropriate processes and documentation are essential for project success.	Project
Poor risk management All projects are inherently risky. Effective risk management reduces the degree of uncertainty to an acceptable level.	Project
Overruns of realistic schedule and cost estimates This is a project failing. Either due to poor management/motivation of the project team or poor risk assessment (leading to inadequate contingencies) or poor estimating.	Project
Failure to track progress Tracking progress against the plan and adapting performance is central to effective project management.	Project
Poor Testing Failing to adequately test project deliverables; including: – Poor requirements which cannot be tested – Failing to design a testable system – Failing to develop a realistic and effective test plan – Failing to test effectively with skilled staff – Inadequate time and budget allowed for testing.	Project
Poorly defined roles and responsibilities The organisations management is responsible for defining roles and responsibilities in the overall management stakeholder community; the project manager is responsible for the organisation within the project team.	Project / Support
No change control process / Scope creep A lack of effective change management processes is primarily a project failing, however, organisational management should require effective change management to be in place and support the change management processes.	Project / Support
Team weaknesses – Inadequate / incorrectly skilled resources Having people who are ill-prepared to complete a task can be worse than not having anyone. The organisation is responsible for providing adequate internal resources for the project, the project is responsible for defined training and procuring appropriate contracted resources.	Support / Project
Lack of user input The organisation is responsible for organising the necessary input from end users. The project is responsible for requesting and defining its needs and making appropriate use of the information provided.	Support / Project
Lack of management commitment / Lack of organisational support The organisation is responsible for properly supporting the projects it has initiated.	Support
Ineffective or no sponsorship Ineffective project sponsorship is almost a guarantee of failure.	Support
Poorly managed – project manager not trained/skilled The organisation is responsible for appointing an appropriate project manager and providing him/her with appropriate support, training and coaching.	Support
Inflexible processes and procedures, templates and documentation Any imposed process needs to be as light  as practical to meet the governance needs of the organisation without inhibiting the work of the project.	Support
Insufficient or Inadequate resources / lack of committed resources (funding and personnel) The organisation is responsible for properly resourcing the projects it has initiated. If the resources don’t exist or are already fully committed elsewhere, this is an initiation failure; if they are simply not made available it is a support failure.	Support / Initiation
Poor communication / Stakeholder engagement People tend to fear what they don’t know, therefore effective communication with stakeholders is vital if the project is to capture their support, and keep it. The project is responsible for project based communications; the organisation change manager (sponsor) is responsible for communication in support of the overall change initiative.	Benefits / Project
Poor or ineffective organisational change management The organisation has to implement, accept and use the project’s deliverables to generate value. Failures at the organisational change level mean most of the planned benefits cannot be realised.	Benefits
Stakeholder conflict The organisation is responsible for properly supporting the projects it has initiated. This includes the ‘through life’ management of stakeholders starting prior to initiation and continuing through to the realisation of the benefits.	Benefits
Inability or unwillingness to stop a project after approval ‘Death march’ projects destroy value. A key element of effective portfolio management is to stop wasting money and resources on projects that can no longer contribute value to the organisation.	Benefits

Of the 29 causes of failure outlined above, only 7 are exclusively the province of project management. The other 76% involve or are exclusively the province of the organisation’s general and executive management as part of an overall ‘Project Delivery Capability’!

This overall capability of an organisation to realise value from an investment in a project starts with selecting the right project to do for the right reasons, then doing the work of the project effectively and efficiently, and then making effective use of the project’s outputs to create value. Mess up any of the early stages and there are no benefits to manage. If the organisation fails to implement the changes effectively, the potential benefits are not realised.

The project manager is only responsible for the bit in the middle – the ‘doing of the project’, a steering committee, sponsor or other management entity is responsible for the beginning and end parts of the overall process involved in PDC. Even the 24% of failures assigned to project management have a link back to the role of the Project Director within PDC. The organisation should provide oversight, training and support to ensure effective processes are used by their project managers and teams. Conversely, a skilled project manager may be able to overcome some of the organisational failings identified above; by managing upwards and operating effectively within the organisation’s political systems a skilled project manager can cover some failings, others are fundamental and will result in a failure regardless of the efforts of the project team.

Therefore based on this table, it is reasonable to determine PDC is an executive and general management responsibility. The ‘project governance’ requirement within PDC is for the Board to ensure executive and general management accept this responsibility and excel in creating value for the organisation.

Based on this assessment, my personal feeling is we as project practitioners need to stop referring to ‘project failures’  every time a project fails to deliver the expected value and start talking about ‘business failures’ when the organisation’s  management fails to effectively manage or support the work and as a consequence, fails to achieve the intended/expected value.

PDC = Project Delivery Capability

My last couple of posts have identified a gap in the overall management of projects and programs that is present in most organisations. This ‘Zone’ covers a range of organisational capabilities from the innovation and assessment of ideas that may develop into projects through to achieving the value the project was created to enable; see: Disappearing into the Zone.

Effective project or program management cannot save a project that has been set up to fail by the organisation. Doing the wrong project ‘right’ or doing the right project as ‘right as possible’ with inadequate funding, resources, skills and management support may reduce the extent of the disaster but cannot prevent failure; see: Cobb’s Paradox is alive and well.

The solution to this perennial problem, first identified by Cobb in 1995, is for the organisation’s leadership to demand that their executive create an effective project delivery capability (PDC). This name is suggested to place focus on the delivery of value to the organisation as a result of doing the ‘right’ projects ‘right’. Managing the selected projects effectively is just one step in this overall value chain.

PDC includes all of the aspects of project delivery discussed in our White paper PPP Taxonomy and outlined above, with a focus on realising value for the organisation.

Implementing an effective and rigorous PDC structure will require a major change effort in many organisations and will challenge existing cultures, particularly the tendency to focus on ‘project failure’ rather than ‘organisational failure’ when the organisation fails to adequately manage the management of its projects. The extent of this challenge is outlined in our White Paper Organisational Change Management.

The three layers of PDC are defined above:

• Governance – the organisations directors / leaders have to set the right strategy, ask the right questions and require the right answers from their executive.
• Executive management (Purple) are responsible for creating the capability and culture of accountability needed to deliver projects successfully and realise the intended benefits. A key element in this is developing a rigorous portfolio management capability to select the best projects to fulfil the organisation’s strategy, based on consideration of each project’s feasibility and viability, within the organisational constraints of capability and capacity.
• Organisational support processes (Orange) including opportunity identification and assessment, plus developing and enhancing the organisation’s project delivery capability including: organisational enablers, support systems, oversight systems, change management systems and value realisation.

Program management can fulfil some of these support functions where several projects are being managed in an integrated way to maximise benefits. However, where programs are used by the organisation, the organisation’s overarching support processes need to be capable of supporting and overseeing the work of the programs as well as other independent projects.

PDC reframes the project delivery/success paradigm. Change is needed, the approaches currently used in many organisations are generating project failure rates in excess of 50% and to keep doing the same thing, expecting different outcomes is, to quote Einstein, ‘the definition of insanity’!

Focusing on developing an effective PDC will enable organisations to improve the way they manage the ‘doing of their projects’ and as a consequence increase the success rate resulting in increased value for their stakeholders. The ROI from improving an organisation’s PDC should be significant!

Project and Organisational Governance

One of the themes running through several of my recent posts is the importance of effective Governance. Both organisational governance and its sub-set project governance.

Good governance is a synonym for ‘good business’, structuring the organisation to deliver high levels of achievement on an ethical and sustainable basis. This requires the optimum strategy and the right approach to risk taking supported by sufficient processes to be reasonably confident the organisations limited resources are being used to achieve the best short, medium and long term outcomes.

Project governance focuses on the portfolios of programs and projects used by the organisation to deliver many of the strategic objectives. This process focuses first on doing the right projects and programs constrained by the organisations capacity to undertake the work – Portfolio Management; secondly, creating the environment to do the selected projects and programs right- developing and maintaining an effective capability; and lastly systems to validate the usefulness and efficiency of the ongoing work which feeds back into the selection and capability aspects of governance.

 

Within this framework, portfolio management is the key. Strategic Portfolio Management focuses on developing the best mix of programs and projects to deliver the organisations future within its capacity to deliver. This means taking the right risk and having sufficiently robust system in place to identify as early as possible the ‘wrong projects’, so they can be either be reframed or closed down and the resources re-deployed to other work.

It is impossible to develop an innovative future for an organisation without taking risks and not every risk will pay off. Remember Apple developed the ‘Apple Lisa’ as its first GUI computer which flopped in the market, before going on to develop the Apple Macintosh which re-framed the way we interact with machines.

Apple Lisa circa. 1983

Obviously no organisation wants to have too many failures but good governance requires ‘good risk taking’. Apple had no guarantees the i-Pod and its i-Tunes shop would succeed when it started on the journey of innovation that has lead to the i-Phone, i-Pad and Apple becoming one of the largest companies in the world based on capitalisation. As Richard Branson says – ‘you don’t bet the company on a new innovation’ but if you don’t innovate consistently, obsolescence will be the inevitable result.

The balance of project governance focuses around creating the environment that generates the capability to deliver projects and programs effectively, effective sponsorship, effective staff development, effective and flexible processes and procedures, simple but accurate reporting and good early warning systems to identify issues, problems and projects no longer creating value (a pharmaceutical industry saying is that if a project is going to fail it is best to fail early and cheap!).

Good questions outrank easy answers! Every hour and dollar spent on governance processes is not being spent on developing the organisation. The challenge of good governance is to have just enough reporting processes embedded in an effective culture of openness and accountability to provide an appropriate level of assurance the organisation’s resources are being used effectively; whilst at the same time allowing innovation and development. Restrictive and burdensome governance processes are simply bad governance – they restrict the organisation’s ability to achieve excellence.

To help organisations understand these key governance processes we have updated our two White Papers on the subject:
Corporate Governance: http://www.mosaicprojects.com.au/WhitePapers/WP1033_Governance.pdf
Project Governance: http://www.mosaicprojects.com.au/WhitePapers/WP1073_Project_Governance.pdf

For more discussion around the subject of governance see the previous posts on this blog.

Cobb’s Paradox is alive and well

In 1995, Martin Cobb worked for the Secretariat of the Treasury Board of Canada. He attended The Standish Group’s CHAOS University, where the year’s 10 most complex information technology (IT) projects are analysed. The high level of failure led Cobb to state his now famous paradox: “We know why projects fail; we know how to prevent their failure—so why do they still fail?”

In 2011, another report into the management of IT projects asks the same question! This time the report was prepared by the Victorian Government Ombudsman, in consultation with the Victorian Auditor-General, it documents another series of failures largely created by executive management decisions. The report entitled Own Motion Investigation into ICT – Enabled Projects, examines 10 major Victorian Government ICT projects that experienced difficulties such as budget and timeframe blowouts or failure to meet requirements.

Portfolio Management
Problems identified by the Ombudsman in the area of Portfolio management and governance include a lack of effective leadership, accountability and governance. He was particularly concerned about poor project governance, the lack of accountability of project stakeholders and a lack of leadership — a reluctance to take tough decisions.

These failures contributed to poor decision making, and an inability or reluctance to make difficult, but necessary decisions. Leaders lead and determine governance practices; the resources needed to implement these facets of effective Portfolio management are readily available including:

• PMI’s The Standard for Portfolio Management – 2nd Edition, available in Australia from http://www.mosaicprojects.com.au/Book_Sales.html#PMI, elsewhere from http://marketplace.pmi.org
   
• The Association for Project Management’s Directing Change, a guide to the governance of project management: Download the booklet

Project Definition
It is impossible to deliver a project successfully if the decision to proceed is based on inaccurate assessments in the business case. The Ombudsman commented on the inadequacy of business cases, the failure to fully define requirements for new systems, a general reluctance to change business processes to better fit with off the shelf products (to reduce cost and risk) and a ‘tick the box’ approach to risk management (ie, avoiding any real assessment of risks and opportunities).

Linked to this lack of definition major project funding decisions were announced publicly before the business case was fully developed (representing either wishful thinking or a wild guess?), and high risk decisions being made to only partially fund some projects.

The solution to these issues is a robust and independent PMO that has the skills and knowledge needed to validate business cased before they go forward to management for decisions. Many years ago, KPMG released a series of reports that highlighted the fact that organisations that failed to invest in effective PMOs were simply burning money! The Ombudsman’s report shows that ‘burning public money’ is still a popular pass time.

For more on PMOs and to download the KPMG reports see: http://www.mosaicprojects.com.au/Resources_Papers.html#Proj_Off

Risk Management
Many of the factors identified above and in my view the primary cause of most bad decisions is the abject failure of senior management to insist on a rigorous risk management process. Risk management is not about ‘ticking boxes’, it is about having the ethical courage to objectively explore the risks and then take appropriate actions to either mitigate the risk or provide adequate contingencies within the project budget. This failure was manifest by an inconsistent approach to contingency funding. There are many examples of high risk decisions being made without any contingency provisions:

• The Myki ticketing system was let to an organisation that had never delivered a ticketing system before. No contingencies were made for this high risk decision and the project is years late, $millions over budget and will only deliver a small part of the original scope.
   
• Agencies preferred to be on the leading edge rather than leveraging what had been done by others elsewhere. This may be justified but not without proper risk assessment, mitigation and contingency.

Government agencies are not alone in failing to effectively manage risk in ICT procurements. The same problem has been identified in major infrastructure projects, in a series of reports by Blake Dawson; see: Scope for improvement

There are always difficulties in transferring project risks to vendors, and dealing with large vendors who may be more experienced in contract negotiation than their agency counterparts. Whilst modern forms of contract provide opportunities to adopt innovative procurement processes that could significantly reduce project risks for vendors and customers these were not used.

As our paper, The Meaning of Risk in an Uncertain World  and the Blake Dawson reports clearly demonstrate, not only is it impossible to transfer all of the project risk to a vendor, it is totally counterproductive to try! Organisations that try to transfer ‘all of the risk’ end up with a much poorer outcome than those organisations that actively manager the risks in conjunction with their vendors.

Large ICT projects are inherently complex and necessarily involve some significant risks. But these can be mitigated to some degree by taking heed of the Ombudsman’s observations, lessons learnt in other projects and the implementation of robust and independent systems.

The PMI Practice Standard for Risk Management provides  good starting point.

Recommendations
The Ombudsman’s recommendations on how to address these issues can be applied to ICT and other projects undertaken by other state, local and Commonwealth government agencies, and in the private sector: Download the report.

In my opinion, the primary cause of these failings, referenced but not highlighted by the Ombudsman, is cultural. Executives and senior managers overtly preferring the status quo and the current power structures they have succeeded within over leading the implementation of change that will deliver improved outcomes for their organisations but make people more accountable and redistribute organisational power. This was the focus of my last posting; Culture eats strategy for breakfast 2!

As Martin Cobb observed in 1995, “We know why projects fail, we know how to prevent their failure — so why do they still fail?” Unfortunately this is still a valid question more that 15 years later and, without leadership from the very top, I expect the effect of this report will be little different to the dozens of similar reports generated over the years and we will still be asking the same question in 2020.

The answer is culture and leadership – to change the culture within senior management ranks, the owners of organisations need to take actions similar to the Australian Federal Government and mandate effective processes and then measure performance in their implementation and use. The implementation of the Gershon Report that is being forced through the federal government departments is a Cabinet level initiative. It is still too soon to judge wether the initiative will be successful, effective culture change takes years to embed in major organisations, but at least the push has started at the right level. My feeling is that if the pressure is maintained for another 3 or 4 years (the original report was released in 2008) there may be some real benefits. To avoid similar reports to this one in the future, the leaders of other organisations need to take similar robust, strategic action tailored to the needs of their organisation.

Project professionals can help by effectively communicating to your top-level executives the real benefits of effective project governance. For many ICT and other technical/engineering professionals this represents is a whole new set of skills to learn, my book Advising Upwards may help!

Lessons Learned

The London Olympic Delivery Authority’s Learning Legacy is designed to facilitate the dissemination of the lessons learned from the London 2012 construction project for the benefit of future projects and programmes, academia and government with the intention of raising the bar within the construction sector.

The ODA are on the verge of delivering a massive program of works on-time and on-budget, the learning from this major undertaking can benefit everyone.  To browse and download the 250 documents see: http://learninglegacy.london2012.com/

There are four types of reports:

• Micro reports: Short examples of lessons learned, best practice and innovations from the construction programme.
• Case studies: Peer reviewed papers on lessons learned, best practice and innovations from across the Programme.
• Research summaries: Summary reports of research projects undertaken by academia and industry on the London 2012 construction.  These organisations will also publish full research papers as they are finalised throughout 2012.   Over 600 interviews were undertaken by researchers on the ODA and its supply chain as part of the learning legacy research.
• Champion products: Examples of tools and templates used successfully on the programme.

The reports have been classified into 10 themes:
• Programme and project management;
• Design and engineering innovation
• Equality, inclusion, employment and skills;
• Health and safety;
• Masterplanning and town planning;
• Procurement and supply chain management;
• Sustainability;
• Systems and technology;
• Transport;
• Archaeology.

This is a highly recommended rich source of information.

ISO 21500 Guide to Project Management

The Draft International Standard (DIS) of ISO 21500 has been released for comment. The Australian committee MB12 is seeking input from Australian project management professionals to help formulate the Australian response to the international committee.

Information on how to sign up for this review or to simply track progress through to the final publication, the Australian committee has launched a web site at http://www.mb12.org.au/. Mosaic will be continuing to support the development of this standard through to publication.

Readers of this post from other nations should contact their national standards authority if they wish to comment.

Cobb’s Paradox

Cobb’s Paradox states, ‘We know why projects fail; we know how to prevent their failure – so why do they still fail?’  PMI has recently published its latest Pulse of the Profession survey which shows some improvements on the 2008 and 2006 results but not much. Nearly half the projects surveyed in 2010 still failed to meet time and cost targets.

However, the PMI survey did highlight a stark difference between high performing organisations with a better than 80% success rate, and low performing organisations with a greater than 40% fail rate. And, the survey also clearly showed the processes typically used by the high performing organisations (and ignored by low performing organisations) are straightforward to implement and use; they include:

• Using standardised project management processes.
• Establishing a process to mature project, program and portfolio management practices.
• Using a process to increase project management competency.
• Employing qualified project managers.

Most of these elements coalesce around an effective project management office (PMO). Simply by standardising project management processes, the survey shows an organisation can expect a 25% increase in project success.

None of this new is new, KPMG demonstrated exactly the same point in its 2002 and 2003 surveys, supported by similar findings by PwC in 2004 (see: http://www.mosaicprojects.com.au/Resources_Papers.html#Proj_Off).

What’s worrying me is the large number of organisations whose middle and senior management are simply failing their stakeholders by not implementing these simple pragmatic steps. The question that should be asked is WHY?

The stakeholders whose rights are being ignored include the owners who have a right to expect efficient use of resources entrusted to the organisation and the people employed on the failed projects whose work life is made unnecessarily stressful.

As Deeming pointed out in the 1950s, quality is a management responsibility. Therefore, allowing poor quality project management processes to exist in an organisation is a management failure. To quote another mantra: quality is designed in not inspected in. Workers and project managers cannot be expected to retrofit quality into defective systems; systemic failures are a failure of management.

What makes the situation even more worrying is that the tools to develop a quality project management system are readily available. Models such as CMMI, P3M3 and PMI’s OPM3 maturity model has been around for years and are regularly updated.

PMI has recently moved to improve the availability and support for its OPM3 Self-Assessment Module (SAM). This basic assessment system is now sold and supported by organisations such as Mosaic that are qualified to deliver the full range of OPM3 services and help businesses achieve the best return on their investment (for more see: http://www.mosaicprojects.com.au/OPM3.html). OGC have similar arrangements for P3M3 as does CMMI.

So, given the tools are available, the knowledge is available, and the value has been consistently demonstrated; why are organisations still prepared to squander $millions on failed projects rather than investing a fraction of that amount in simple systems that can significantly improve the value they deliver to their stakeholders?
I would be interested to know the answer.