Monday

Category Archives: Value

Project or Management Failures?

Posted on March 25, 2012 by | 15 comments

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 FailureCause
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.

15 Comments

Posted in Governance, Value

Tagged , , , , , , , , , , , , , , ,

PDC Value Proposition

Posted on March 17, 2012 by | 2 comments

The only reason for undertaking a project or program is to create value through the realisation of benefits. Some projects generate significant intangible benefits such as reduced risk, enhanced prestige or in the case of regulatory requirements, the simple ability to keep trading; others are focused on generating a positive financial return, most generate a combination of financial and intangible returns.

A key element in Project Delivery Capability (PDC) is understanding the value proposition the project or program has been created to generate. Regardless of the way the ‘return’ is measured, no project should destroy value, unfortunately as discussed in Disappearing into the Zone far too many do!

The value proposition for developing an effective PDC (itself a business change program) is compelling. World-wide research undertaken by Jed Simms at the Boston Consulting Group in the 1990s defined five levels of PDC, and found that the return on investment (ROI) from projects increased substantially at each level*. These findings have been developed into a project delivery capability model by TOP – Totally Optimized Projects Pty Ltd. 

  • Level 1 capability is represented by executive complacency, project teams doing their own thing, no benefits management, and on average projects typically show a small negative ROI but results are wildly variable with some successes (which are always highlighted).
     
  • Level 2 capability sees the imposition of process focused on measuring activity rather than outcomes. The business imposes forms, requirements and check lists; ‘methodology police’ enforce a one-size-fits-all policy. The process of developing ‘approvable’ businesses cases and standardised project reporting creates more uniform outcomes but there’s little understanding of risk -v- reward and virtually no follow through to implementation and benefits realisation. As a consequence there is typically a neutral ROI – the value created eventually covers the costs despite the glowing promises in the business case.
     
  • Level 3 capability sees the organisation gaining sufficient experience and confidence to allow measured flexibility into its processes for managing projects. The basic disciplines are retained, but the way they are implemented is adjusted to suit the needs of the project. The executive view moves from imposing ‘controls’ towards an outcome focus using elements of portfolio management. However, project success still tends to be measured in terms of time, cost and scope at the end of the project rather than the benefits gained by the organisation; an output focus rather than an outcome focus. Organisations at this level generate a reasonable ROI measured at the project level but largely miss the potential for substantially enhanced business outcomes.
     
  • Level 4 capability introduces a paradigm shift in executive thinking. Rather than focusing on project outputs, the work of the project is seen as a key enabler of valuable business outcomes. This requires an integrated flow from the identification of a need or opportunity within the business through to implementing the changes required to deliver of the expected business outcomes to meet the need or exploit the opportunity. Ownership of this value chain is vested in the business, the role of projects and project management is to support this overall effort by delivering the outputs best suited to achieving the business objective. The model defined in PDC = Project Delivery Capability represents the PDC framework needed to support this level. Simms’ research suggests there is an increase in ROI to 2 to 3 times that achieved at Level 3 once the focus of organisation’s executives shift to achieving business related outcomes, measuring the benefits actually realised and the value achieved.
     
  • Level 5 capability expands on Level 4 with the whole PDC system focused on efficiently supporting the strategic objectives of the business. Effective strategic alignment linked to pragmatic risk management and simple but effective processes generates another significant increase in ROI!

Based on observation rather then measurement, it seems the majority of organisations in both the public and private sectors are currently operating at Level 2, typically with the PMO fulfilling the role of ‘methodology policeman’, a few more mature organisations, mainly private sector, are achieving Level 3 maturity whilst others remain at Level 1.

Very few have taken the step to Level 4 where the executive hold their business managers accountable for achieving the outcomes defined in the business case and invest in the PDC capability required to properly support their business managers.

Doing projects ‘right’ is a Level 2 phenomena, doing the ‘right projects, right’ is Level 3; the optimum is Levels 4 and 5 where the right projects are done for the right strategic reasons. PDC was forecast by Simms as the next competitive battleground in 2005 – I would suggest it is the competitive battleground in 2012!

* Source, Project Delivery Capability – the next competitive battleground, Jed Simms, TOP – Totally Optimized Projects Pty Ltd.

2 Comments

Posted in Governance, Value

Tagged , , , , , , , , , , ,

Unrealistic Expectations

Posted on October 30, 2011 by | Leave a comment

Unrealistic expectations are highly unlikely to be fulfilled. But, when a project fails to achieve the impossible it is branded a failure!

The Economist Intelligence Unit’s recent report ‘Proactive Response – How financial services firms deal with troubled projects’  highlights unrealistic goals as the most common cause of project failure in financial service firms, other causes of failure include poor alignment between project and organisational goals, the failure of the organisation to provide adequate resources and the project sponsor failing to get involved in the project sufficiently early, if at all.

15% of firms surveyed had no processes for dealing with troubled projects and 47% wait until the project has officially missed time and budget targets before taking any action despite 61% of the executives surveyed believing early action on troubled projects enables organisations to better use limited resources.

This survey reinforces many others over many years that clearly highlight executive governance failures as the primary cause of project failures. And this seems particularly true of large IT projects where a recent survey of 1500 large IT projects by the University of Oxford found one in six projects went over budget by an average of 200% or time by almost 70%. The Oxford conclusion was that many managers in charge of the projects did not have enough understanding of how to implement the technology, presumably leading to unrealistic expectations……

These findings support two conclusions; firstly, the program and portfolio management maturity levels in organisations are seriously deficient. A series of Portfolio, Program and Project Management Maturity Model (P3M3) audits of Australian government agencies with IT budgets of more than $20 million, showed scores averaging around 2 out of 5 with many lower and a trend towards portfolio management being the least effective area. These findings are similar to outcomes from OPM3 assessment I have undertaken in other types of organisation.

The second conclusion is that knowledge, insights and valuable information derived from project expertise is not being effectively communicated ‘up the ladder’ in a way that executives can understand and appreciate.

Projects are successful when the organisation realises the benefits it expected from undertaking the project. For more on the value chain see ‘Value is in the eye of the stakeholder’. To close this loop effectively, skilled project personnel including PMO staff, need to be able to communicate effectively with their organisations executives. The art of ‘advising upwards’ effectively requires skill and understanding (this is the focus of my latest book ‘Advising Upwards’), but it is also important for the whole project industry, at the association, organisation and individual levels to recognise that knowing what represents ‘good’ PPP management is only the beginning, the end game is most organisations, most of the time doing good PPP management; and this won’t happen unless the senior executive and ‘middle management’ levels of organisations understand both the processes and the benefits.

The surveys canvassed at the start of this blog suggest we still have a long way to go!

Leave a comment

Posted in Stakeholder Management, Value

Tagged , , , , , , , , , , , ,

Perceptions Matter

Posted on May 11, 2011 by | Leave a comment

The Australian Institute of Management and the Safety Institute of Australia have recently published a survey on the effectiveness of organisation’s occupational health and safety (OH&S) processes. The findings may be of value to another specialist area – project management!

Some of the key findings were:

  • 77% of CEOs and 56% of senior managers stated they put a ‘very high priority’ on workplace OH&S. Only 38% of OH&S personnel thought their organisation placed a ‘very high priority’.
  • 50% of CEOs said they strongly agreed their organisation had a well entrenched OH&S culture, only 18% of OH&S personnel agreed.
  • 88% of CEOs and 70% of senior managers said top level management ‘walked the talk’ when it came to OH&S but only 47% of OH&S staff agreed.

This intention of this post is not to focus on the OH&S practices and policies of organisations, rather to speculate on why there is such a significant difference between senior management perceptions and specialist management perceptions.

It would be too easy to pass off the difference simply based on senior management ‘saying the right thing’, unlike project management if there is a serious accident, senior managers are personally liable and can face substantial criminal and civil penalties. It I simply not in management’s interest to ignore or accept sub-standard OH&S practices, in many Australian States they can literally go to jail if there is a significant failure.

My feeling is the dramatic difference is driven by two key factors that overlap and support each other.

The first is differences in the degree of technical understanding. The OH&S expert’s know what is possible, needed and represents current best practice. General management would have been involved in direct supervision of workplaces probably 10 to 20 years ago; best practices and the law has changed dramatically in the intervening period. The senior managers may believe their organisations are doing well simply because they don’t know what best practice looks like from personal experience and involvement. The challenge is to educate senior management on best practice so they actually understand – how you fit this into a senior manager’s busy schedule is an interesting problem.

The second is appreciating the details. OH&S expert’s see all of the issues, problems and failings. They know what is not working! By the time information is summarised, sanitised and passed through several levels of middle management most of the nitty gritty nasties are filtered out and overall the organisation is shown to be doing OK. This filtering and summarisation process is a well recognised problem and was a primary cause of the Challenger Space Shuttle disaster; but again, how do you get the right information to executives without burying them in detail??

Now let’s look at our profession. Project Management is relatively new and has significant technical specialisations. Most executives have never worked as project managers or in a projectized workspace. Most project fail through a combination of small issues, problems and changes. There is not one big issue and most of the details are filtered out as information moves up the hierarchy. Rather then recognising the hidden systemic causes of failure, it is simpler to assume the people involved have failed and blame the project managers!!

Lastly, as with OH&S, effective project management requires the expenditure of resources to develop and maintain effective systems that prevent problems. But you cannot value the problems that don’t occur because you have effective systems! Any expenditure to improve systems has to be based on a belief the outlays deliver value, possibly backed up by some generic trend data. But to believe, you need to appreciate and understand the value; how can this be imparted to senior management???

Given OH&S has legislated conformance requirements and project management does not, it is quite likely your organisations executives believe the organisation is doing as good a job of managing its projects as they evidently believe they are doing with OH&S (and their perceptions are their reality). The challenge facing project management professionals is advising upwards to change these perceptions in a positive way. The key question is how?

The techniques of advising upwards are the focus of my new book, publication due in September (see more on the book) ).

Defining the message to be advised upwards is more complex:

  • Part of the answer is Cobbs Paradox (see the post )
  • Another aspect is valuing our processes (see the post)
  • The rest is likely to be a combination of persistence and performance.

What do you think?

Leave a comment

Posted in Communication, General Project Management, Governance, Stakeholder Management, Value

Tagged , , , , , , , ,

Valuing Project Procedures

Posted on April 5, 2011 by | 1 comment

I am frequently asked to quantify the value of improving an organisations project management capabilities or how to establish the ROI for a new PMO.

Whilst these questions are sensible they are nearly impossible to answer. Certainly there are strong indicators of the value generated by an effective PMO, this has been demonstrated repeatedly in studies by KPMG, PWC and others (Download the PMO studies).

OPM3 is more difficult. The most useful option is a comparison with CMMI.  The larger user base for CMMI makes statistical analysis possible and demonstrates a consistent value proposition for improving organisational maturity and capability (see more on OPM3).

The question is can the generic data generated by these studies be translated to a specific proposal in a single organisation. Unfortunately the answer is no.  On average an organisation can expect a significant return on monies invested in PMOs and improving project, program and portfolio management maturity but as risk practitioners know only to well, on average, nothing is average.  Some situations will fail, other will generate stellar returns.

This is not a new problem.  In June of 1962 the USA Dept. of Defense promulgated PERT/COST as a new general purpose management system for use on major military system acquisition programs. In 1964 a major study was undertaken by The Mitre Corporation to investigate the question of how to evaluate the design of the PERT/COST management system. This study still makes interesting reading today.

The overarching conclusions in the report were:

  • That there is no single, simple straightforward way of deriving value judgments as to the PERT/COST system design, or probably any other general purpose management system.
  • The interrelationships between a management system and the quality of its implementation operation (including the capability of the managers who use it), presents serious difficulties in the assessment of the value of the management system alone.
  • The value of the system is intimately related to both the quality of its implementation and the capability and willingness of the appropriate managers to use it.
  • An evolutionary approach is a good way to evolve the development of the system capability in an orderly fashion over period of time. It is ideal in cases where the ultimate capability to be required of the system cannot be precisely defined, but where the direction toward which increasing system capabilities should be oriented are predictable.

My post on Cobb’s Paradox asked the question why do executive managers allow poor quality systems to exist in their organisations. Possibly one answer is the difficulty of generating a simple investment proposition discussed in this post.

Better informed executives are capable of bypassing set minimum ROI values or payback periods, focusing instead on the demonstrated competitive advantage to be gained by selecting the right projects and programs to do, then doing them right!  The challenge for project management professionals in other organisations is making the necessary information available in ways that can be received and understood by the executives.

In conclusion, Harry S Truman said “The only new thing in the world is the history you don’t know.”  To help you avoid this problem, the 1964 Mitre Report, authored by R. L. Hamilton, can be downloaded from the link (Handle) on  http://oai.dtic.mil–AD0603425

1 Comment

Posted in Governance, Stakeholder Management, Value

Tagged , , , , , , , , , , , , , , , , , , , ,

Cobb’s Paradox

Posted on March 18, 2011 by | 9 comments

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.

9 Comments

Posted in Governance, Value

Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Thoughts on Collaborative Working

Posted on March 5, 2011 by | Leave a comment

The reason why trading goods, services and support creates value for all is simple – as long as there is a difference in abilities everyone wins…… A very simple example is where there are two things needed and two people need to have one of each. To make them:

  • Ms A is ultra efficient, she can product ‘X’ in one day and product ‘Y’ in 3 days.
  • Mr B is far less efficient but is good at ‘Y’. He can make ‘Y’ in 4 days but needs 6 days to produce ‘X’.

Overall to produce ‘X’ and ‘Y’ on their own Ms A would take 4 days and Mr B 10 days.

Now let’s introduce trade supported by specialisation. Ms A makes two ‘X’ and Mr B two ‘Y’, then they exchange one ‘X’ for one ‘Y’; so both end up with one each of the needed ‘X’ and ‘Y’.

The total time invested by Ms A becomes 2 days, a saving of two days and a 50% increase in efficiency.

The total time invested by Mr B becomes 8 days a saving of 2 days and an increase in efficiency of 25%.

Everyone is better off even before the advantages of specialisation are taken into account.

Archaeologists believe one of the key differentiators between Homo sapiens and Neanderthal man was Homo sapiens traded from very early in their evolutionary development, Neanderthals did not. Based on this simple example, collaboration can definitely pay dividends even in the 21st Century and may help you and your team avoid extinction.

Leave a comment

Posted in Value

Tagged , , , , , , , , , ,

Methodologies

Posted on August 6, 2010 by | 3 comments

Methodologies define a step-by-step process for delivering projects. Each methodology will describe each step in adequate depth, so that the project team understands what has to be done to deliver their project. This is quite different to a standardised knowledge framework such as the PMBOK® Guide (for more on this see: PMBOK -v- Methodology).

By using the same steps for every project the organisation undertakes risks and uncertainty are minimised and there is likely to be an overall saving of time and effort on projects.

Defining ‘your’ methodology

The key steps to follow are:

  • Define what it is that you want from your methodology, the type of content it should contain and the way in which it will be used.
  • Create a set of specific requirements. Some options include defining:
    • How much of the project lifecycle needs to be incorporated
    • How much detail should be included? What practical templates and examples are needed to help to complete the step quickly and easily?
    • Should it follow one of the worldwide project standards such as the PMBOK® Guide?
    • Can/should the system be easily customised suit all project types and sizes?
  • Determine the best methodology to use:
    • Review the methodologies used currently by your organisation and compare them to your requirements to see if there is a good fit.
    • Review the commercially available methodologies to see if there is a good fit.
    • Select the option with the best fit to your requirements
  • The best methodology is still only likely to have a 90% fit (or less), this is normal. Make sure you can customise the remaining elements to meet your requirements.
  • Ensure adequate flexibility for the range of projects in your organisation.

Implementing the methodology

The key steps are:

  • Create an Implementation Plan supported by a change management plan. Implementing a methodology is a significant organisational change.
  • Run the implementation as a change management program, including customising the methodology for your environment. Stakeholder engagement is vital to the overall success of the initiative.
  • Train the users and support staff in the methodology and ensure ongoing support.
  • Ensure the methodology is followed.
  • Start improving the methodology (for more on measuring and improving the organisations project management maturity see Mosaic’s OPM3 home page).

Improving the methodology

Processes are always capable of improvement. Observing the actual implementation of the methodology will define actions and outcomes within the following matrix.

Unauthorised, unproductive activities need to be stopped and authorised productive processes supported. The two zones for process improvement are refining or removing elements of the methodology that do not add value to the overall management of the project and incorporating unauthorised processes that are not in the methodology but that are being used add value.

The easiest and most important area for action is rectifying the unproductive processes already in the methodology. Care need to be taken to ensure the definition of ‘unproductive’ is understood. Most planning processes don’t produce anything and consume effort; superficially they can be classified as ‘unproductive’. In reality, effective planning contributes significantly to the efficient delivery of the project and its value to assist in the efficient execution of the work being planned is significant.

Excessively detailed planning though is usually counterproductive. Value judgements are needed to assess the point at which adding more detail or rigour becomes ‘planning overkill’ reducing the overall value of the process and conversely, how much detail can be safely removed from a planning processes to improve overall productivity before insufficient planning starts to cause problems.

Ensuring the methodology is seen as ‘productive’ is essential for it to be generally accepted and supported by your stakeholders.

Once the existing methodology is optimised and firmly in the ‘authorised and productive’ segment, the next area is to examine unauthorised processes that aid productivity and progressively incorporate these into your methodology. The ‘unauthorised and productive’ quadrant is where you find genuine innovation and opportunities for organisational gain.

Summary

No methodology works ‘out of the box’ they all need customisation and tailoring. However, the effort is worthwhile. OPM3 has demonstrated standardised processes that incorporate best practices can provide significant benefits to an organisation (see more on OPM3).

The challenge is balancing systemised processes with the need for adequate flexibility to deal with the circumstances of each unique project. An effective project management methodology needs core components, scalable components and optional components designed to meet the needs of your organisation.

3 Comments

Posted in Governance, Project Controls, Value

Tagged , , , , , , , , , , , , , , , , , , , , ,

Defining Project Management Terminology

Posted on July 17, 2010 by | Leave a comment

This is the end of a busy week in Rio de Janeiro working with the ISO PC236 committee drafting ISO21500 – Guide to Project Management. My particular area of interest is terminology and one of the more interesting debates was around what’s produced and created by a project. The Dutch delegation started the ball rolling with a very well thought out proposal, this is my personal views on what makes sense at the end of a long week discussing this and a wide range of other comments and issues on the standard.

The first line of discussion was around the creation of the projects ‘outputs’, both deliverables and project management outputs.

  • Processes transform one or more inputs into one or more outputs by applying tools of techniques. This applies to production processes used to create deliverables and project management processes used to manage the work of the project. Therefore:
  • Outputs are created by a process. Most outputs are inputs to other processes; many project management outputs are used within the project to manage the work.
  • Deliverables are the final outputs that are transferred to a third party outside of the project, usually either the customer or the performing organisation.

The second, more important line of discussion focused on understanding the project’s goals and objectives. The way these elements interact are:

  • Project Goals describe the overarching purposes for which the project was created. They tend to be wide reaching and related to the expectations of senior managers and clients. The ultimate success of the project is dependent on achieving its goals. There are two broad types of goals:
    • Goals focused around the realisation of the benefits the project was created to enable. Projects rarely deliver benefits directly, see: Value is in the eye of the stakeholder
    • Goals linked to the project achieving is stated objectives.
  • Project Objectives are the direct responsibility of the project manager. He or she should be assigned the authority, responsibility and necessary resources to achieve the defined project objectives. Objectives fall into two broad categories:
    • Objectives that are achieved by undertaking the project work in an appropriate way. These include objectives such as safety, sustainability, workforce development and stakeholder management.
    • Objectives that are achieved as a consequence of successfully completing the project, the deliverables. These include enhancements to the Organisational Process Assets (OPA) of the performing organisation and the assets transferred to the customer.

The successful delivery of ‘deliverables’ includes achieving technical requirements such as time, cost and scope; plus stakeholder requirements such as value and usefulness (see more on stakeholder management).

Whilst benefits realisation it is usually outside of the objectives that can reasonably be assigned to the Project Manager, the project team are responsible for making sure what they deliver is what is needed to facilitate the organisation (or client) in achieving the overall goals the work of the project is central to achieving; see: Avoiding the Successful Failure!.

The question is, does this structure work in for you? Your comments will be appreciated.

Leave a comment

Posted in General Project Management, Governance, Stakeholder Management, Value

Tagged , , , , , , , , , , , , ,

Taking the Myki (or should that be Mickey)?

Posted on January 23, 2010 by | 3 comments

Myki is another $billion plus government IT project that is years late, $100s of million over budget and that has been de-scoped to the point where there is almost no point in continuing.

Mickey or Myki??

The city of Melbourne, Australia, desperately needs an updated public transport ticketing system. Several years ago a grand scheme was developed that became Myki. Myki was intended to be the key to city living; acting as a cash card, transport ticket and fulfilling a range of other useful functions for the citizenry.

Because of its wide scope, existing public transport ticketing systems in use around the world were deemed not acceptable; the Government needed a brand new special system designed for the unique needs of Melbourne.

Several years and $100s of millions later a majorly de-scoped Myki that is purely a public transport ticketing system may eventually be launched and actually work. The latest commitment made this week is for the system to be working by the end of 2010. This is identical to the commitment made mid 2009 after an earlier commitment for the system to be working by mid 2009 slipped.

I am sure there will be books written on this project and it may even contribute to the demise of the current Government at the elections next year but for now I want to take a quick look at some of the common governance failures Myki seems to have suffered from.

  1. The NIH problem – an amazing number of organisations seem to believe that the only acceptable solution is something developed exclusively for them. NIH = Not Invented Here; if it’s not NIH, it cannot be any good. Generally the arrogance associated with NIH is closely aligned with the pride before a fall.
  2. The internal SES problem. SES = Simple, Easy, Safe. This is a very dangerous and surprisingly common problem particularly in government and defence bureaucracies. To obtain funding approval, the bureaucrats promoting a project need to convince a risk shy decision maker (typically a Cabinet) that the project is simple and well understood, easy to implement and there are no significant risks to time, budget and performance parameters.
  3. The external SES problem. SES = Simple, Easy, Safe. To win the work, the successful contractor has to convince the client’s decision-making team, that the project is simple and well understood, easy to implement and there are no significant risks to time, budget and performance parameters and their bid can be relied upon.
  4. The intrinsic knowledge problem. SES can only flourish in an environment of ignorance. This may be wilful ignorance where people do not wish to hear or organic where senior decision makers simply do not know what they do not know. SES also needs an organisational culture that prevents more knowledgeable junior staff from properly informing their seniors of the real issues. Typically in these circumstances senior decision makers will take the advice of external advisers who have a vested interest in promoting their version of SES over the opinion of internal expert’s who are too junior.

The first interesting decision around Myki was the selection of the company to deliver the ‘project’. None of the organisations world-wide who had real, current knowledge of developing and installing ticketing systems were successful. They probably understood the challenges and issues and priced accordingly. The winning contractor and the government would appear to have happily accepted SES!

As a consequence of SES, everyone has continually talked about the Myki project, with a fixed timeframe and budget. As originally scoped Myki was a major program of work. Managed as a program with the progressive delivery of value by a series of carefully scoped projects the outcome may have been very different. However, accepting Myki as a program would have meant there could be no pretence of certainty concerning the overall timeframe or budget. The Government would have had to accept there was uncertainty (risk) and managed the overall program to create value for the tax payers and transport users.

This level of risk management maturity may be impossible in a political environment. The consequence though is cost overruns, time overruns and a major reduction in value through de-scoping. However, if proper value management systems were in place within a program management framework, many of the ‘bright ideas’ from Senior Ministers and bureaucrats that moved in and out of scope cold have been far more effectively assessed, managed and where they contributed value, implemented.

Effective project and program governance is not about eliminating risk, this is never possible; it’s about understanding and managing risk. One of the key conclusions in my paper The Meaning of Risk in an Uncertain World was that the client bears the ultimate risk for any project, if the project fails, the client pays the costs. Contracts rarely provide protection against the consequences of a fundamental failure!

The first critical step in effective and ethical program and project governance is to fully understand the parameters of the work (see: Eddie Obeng’s typology in Projects aren’t projects – Typology), and then managing the risks and delivery mechanisms appropriately. My prediction is the post-mortems on Myki will show root cause of most of the issues was a treating a ‘Walk in the fog’ program to resolve a problem as a simple ‘Painting by numbers’ project. If this prediction holds true it will demonstrate a fundamental failure of governance.

Watch this space for more…… in the meantime I have applied for my Myki card and do expect to use it sometime in the not too far distant future.

3 Comments

Posted in Stakeholder Management, Value

Tagged , , , , , , , , , , , , , , , , , , , , , , ,