Complex Decision Making Explained

Complex decision making is a vital project management skill; required not only by the project manager but also by the project’s sponsor and client / customer among others.

Some of the key areas involving complex decisions include risk management, many aspects of planning (particularly optimising choices) and dealing effectively with issues and problems in a range of areas from scope and quality to cost and performance.

There is an underlaying assumption in project management (derived from traditional scientific management) that decisions will be based on a rational assessment of the situation to optimise outcomes. Unfortunately this is not true! As complexity increases assuming a ‘rational decision making paradigm’ becomes increasingly unrealistic. Human decision makers become ‘predictably irrational’.

Understanding the built in biases and ‘predictable irrational’ decision making processes used by people confronted with complex decisions can help managers requiring optimised decisions to craft strategies to minimise suboptimal outcomes. But where can busy project managers access this information?

I have just finished reading the most amazing paper on the subject that canvases the whole spectrum from risk aversion to behavioural economics in a practical, easy to read format; and it is free!

Behavioural economics and complex decision making: implications for the Australian tax and transfer system has been written by Andrew Reeson and Simon Dunsttall of the Australian national science agency, CSIRO. The report was commissioned by the ‘Henry Review’ into the Australian taxation system and is published on their web site. Whilst you can safely skip the last section which focuses on applying the knowledge to our tax system. The preceding 7 sections are focused on how people make complex decisions in any sphere and are just as relevant to complex project decisions as to complex investment and taxation decisions.

You can download this free resource from the review panel’s website: download the paper (a copy is also on the Mosaic web site on the assumption the Government site is temporary and will close once the Henry Review has reported: download from Mosaic).

If you find the report useful and you don’t live in Australia, you can buy the next Australian you meet a beer; it was his or her taxes that paid for this amazingly useful report. I know I will be keeping my copy handy for a very long time to come.

The Effective Management of Time in Complicated Construction Projects

The CIOB is finalising the publication of ‘The Guide to Good Practice in the Effective Management of Time in Complex Construction Projects’ with a public consultation period planned before Christmas leading to publication in 2010.

The primary purpose of this Guide is to set down the standards of project scheduling necessary to facilitate the effective and competent management of time in construction projects by defining the standard by which project schedules will be prepared, quality controlled, updated, reviewed and revised in practice.

Before embarking on the guide, the CIOB conducted a survey between December 2007 and January 2008 of the state of time management in a range of UK construction projects. The outcome of the survey was surprising. On simple construction projects, the range of outcomes (late, on time, early) were more or less the same regardless of the use or non-use of effective time management processes.

However, as the projects became more complicated, the difference between projects with an effective time management system and those without became significantly more noticeable. Projects with a well defined time management system were far more successful than those without!

The definition of simple and complicated derived from this study is:

• Simple Projects comprise those in which construction has the following characteristics:
  • design work is completed before construction starts;
  • single building or repetition of identical buildings;
  • less than 5 stories high;
  • without below-ground accommodation;
  • carried out to a single completion date;
  • without phased possessions or access;
  • with services not exceeding single voltage power, lighting, telephone, hot and cold water and heating;
  • a construction period of less than 9 months;
  • with a single contractor; and
  • with less than 10 sub-contracts.
• Complex Projects comprise those in which construction comprises, one or more of the following characteristics:
  • design work is to be completed during construction
  • more than one building
  • more than 5 stories high
  • with below-ground accommodation
  • with multiple key dates and/or sectional completion dates
  • with multiple possessions or access dates
  • with short possessions
  • with services exceeding single voltage power, lighting, telephone, hot and cold water and heating.
  • accompanied by work of civil engineering character
  • a construction period greater than 12 months
  • with multiple contractors
  • with more than 20 sub-contracts

This opens the question why? I would suggest the likely answer, transferable to any project and any industry, is in two parts; both related to stakeholders and communication.

The initial benefit of the process of developing the schedule on a complicated project is the insights the act of creating the schedule gives to the project management team. It is impossible to effectively communicate to the project team and other stakeholders what has to be done when if the project management group don’t have a very clear idea themselves.

‘Simple projects’ are small enough and routine enough to be mapped out in an experienced managers mind. The person intuitively knows what needs to be done. As the project becomes more complex the analysis and serial decision making inherent in the schedule development process creates insights, new information and allows the testing hypothesis until an acceptable solution is devised. At the end of the planning process, a way forward has been determined, optimised and agreed.

The greater benefit though is likely to be in the area of coordination and communication during the work of the project. No schedule is ever perfectly correct. But having an agreed schedule that everyone works towards achieving minimises coordination issues and as elements of the work occur out of alignment with the schedule, the schedule and the variance information provide the foundation for proactive discussion and decision making.

A final intangible benefit of having a schedule has been identified in new research by Jon Whitty. It would appear that simply having a schedule is important for the credibility of the project manager. The project manager’s managers expect the PM to have a schedule and consequently give more credibility to communications from the PM if the schedule is present.

The challenge facing both PMs and their managers as a consequence of these findings is to determine for their industry the difference between simple projects where minimal systems are needed and complicated project where not having a reasonably sophisticated system to help manage time, and other elements of the project, is a distinct liability.

It would seem size does matter! And the old saying ‘if you fail to plan, you plan to fail’ really only applies to the larger more complicated projects. 

Mosaic has developed a range of papers on the art and science of planning and scheduling available from Mosaic’s Planning and Scheduling Home Page.

Project Management 2.0

Project Management 2.0 (PM 2.0) seems to be going the same way some Agile anarchists are trying to take software development which is essentially not to do project management and hope a group of people with good will and good luck will create something useful.

Not doing ‘project management’ is a really good idea if you and your client have no idea what’s needed, when its required, or how much budget is available. Journeys of exploration can be fun and can be highly creative but are nothing to do with managing projects.

Wikipedia (retrieved 27/9/2009 from: http://en.wikipedia.org/wiki/Project_management_2.0) lists the following differences between PM 2.0 and ‘traditional’ project management.

PM 2.0 -v- Traditional PM

Whoever wrote this has absolutely no idea what good traditional project management looks like and has probably never worked on a successful major project. Good traditional project management differs from this highly subjective and biased list in many ways:

• Control is not centralised, authority and responsibility are devolved to the appropriate management levels.
• All good project management is based on collaboration.
• All good project management requires open access to the plan both as an input to its creation and to know what needs doing during delivery.
• Access to information is vial when and where needed.
• Open and effective communication is critical.
• Project are,  by definition, separate management entities – a holistic approach (ie, not doing projects) is called general management.
• Tools, see: A fool with a tool is still a fool, and you need the right tools for the right job. Amateurs try to do jobs with inappropriate tools. Easy to use and flexible are fine if you know exactly what you are doing, it is a recipe for wrong information and wrong decisions if you don’t.

The table is correct in so much as project management involves a degree of top down planning. Project management is about delivering a required output to the specifications requested by the client. The product or service is a failure if it does not meet the quality requirements set by the customer; which may include time, cost and scope parameters.

It is also correct in respect of the implied structure – projects work because there is an implied structure that sets a framework for collaboration. If you don’t know who is doing what it is nearly impossible to collaborate. Even Wikipedia and Linux have structure in their collaborative frameworks.

I have emphasised good project management throughout this post. Bad project management involves excessive attempts to ‘control the future’, lack of stakeholder involvement, excessive bureaucracy, and many other problems. These traits are bad management full stop.

One comment on the Wikipedia article is important though: PM 2.0 is good for small jobs. This is consistent with a survey of construction projects in the UK undertaken by the Chartered Institute of Building, focused on time management, which found that on ‘simple projects’ there was no difference in performance between those projects with a properly developed and managed schedule and those without. The same proportions finished early, on time and late.

However, as soon as the projects became ‘complex’; there was a marked difference in performance. Projects with effective schedule control performed significantly better than those without, and the bigger/more complex the project, the more significant the difference. ( I will put up a post on the CIOB’s work and its new practice standard for scheduling in a few days).

The CIOB’s findings and a closer look at many of the blogs and comments on both PM 2.0 and Agile seem to fit this trend. I would suggest two conclusions could be drawn:

1. If the work is small, simple and easy to understand there is no need for much in the way of traditional project controls. Knowledgeable people know what needs to be done and can just get on with the work.
2. If the required output is not capable of being determined by the client and the objective is to ‘create something wonderful’ it is very difficult to apply too many project management techniques – basically you don’t know what needs to be planned, costed and scheduled, etc. Time and cost are secondary to creativity and the exploration of problems.

In both of these circumstances traditional project management may not be appropriate. In fact I would question if either circumstance is actually a project given the definition of a project is to produce a defined product, service or result that meets the needs of a customer.

The challenge for senior organisational management is recognising the threshold where PM 2.0 and ‘free form Agile’ cease to be appropriate and more traditional forms of project management are needed. Traditional project management does not mean ridged control, the type of project influences what’s needed (see: Projects aren’t projects – Typology) but appropriate systems do help optimize cost, time and quality to deliver client satisfaction.

This does not mean dumping the new ideas, rather melding them into an improved project management process. Agile software development fits in nicely to ‘rolling wave’ planning. Similarly some aspects of PM 2.0 can really help enhance team communication and collaboration. Used wisely, these ideas and technologies simply help improve the way projects work to deliver quality outputs to their clients. This change is really no different to the shift from faxes and carbon copy paper to emails. Good project management has always adapted to use improvements in processes and technology to improve the quality of service provided to the project’s clients. This next wave of improved technologies should be no different.

However, be wary of the zealots suggesting the ‘old ways’ don’t work and should be abandoned and use examples of really bad project management to prove their point. This is even more important if the zealots also advocate employing them to solve all of your problems for a fee. Management fads come and go – modern project management has been generally successful in achieving positive outcomes for well over 50 years now and continues to evolve and improve. For further comment see Glen’s post on: Herding Cats

Stakeholder Management with apologies to Dr. Seuss

When beetles battle beetles in a puddle paddle battle and the beetle battle puddle is a puddle in a bottle…
…they call this a tweetle beetle bottle puddle paddle battle muddle.
Excerpted from: Tweetle Beetles, ‘The Fox in Socks’, by Dr Seuss

The connection between a book written to be read to under 5s and business stakeholder management is the ‘puddle muddle’ otherwise known as the stakeholder pool. The challenge of managing stakeholders is a factor of the disturbance caused by dozens if not hundreds of battles most of which, the person attempting to efficiently manage his or her stakeholders has no control over whatsoever.

Most stakeholder management methodologies start by assessing the stakeholder from the perspective of the work. This is not unreasonable but can easily miss many important factors.

Figure 1: The Stakeholder Pool

Figure 1 shows ‘the stakeholder’ in the overall stakeholder pool being influenced by the ripples created by your battle in your part of the pool (your puddle). Unfortunately the stakeholder pool is a much bigger, more turbulent place.

Figure 2: the Stakeholder Pool with turbulence

Show some of the other disturbances in the pool and you start to see the stakeholder buffeted by waves and impacts from all directions, in Figure 2. ‘The stakeholder’ is continually being buffeted by waves from other projects, the organisation and many other influences. These other waves are one of the prime reasons stakeholder responses to your perfectly reasonable needs or suggestions are frequently so unpredictable. All of these influences, both current and past have helped shape the stakeholders perceptions and attitudes towards your industry, your organisation and ultimately, you.

Consequently, a single view point is really not sufficient! Effective stakeholder management needs an organisational approach. Successful stakeholder management requires all of the influences perceived by the stakeholder to be coordinated and authentic. And this can only be achieved by the organisation as a whole adopting mature, ethical stakeholder management as a core discipline.

Very little has been written about mature organisational stakeholder management until recently. To date, the focus of most papers have been one dimensional focusing on CRM and the ‘customer experience’ or one dimensional focusing on the relationship between the stakeholder and a project (or other organisational activity).

A new book, Stakeholder Relationship Management: A Maturity Model for Organisational Implementation, by Dr. Lynda Bourne takes this next step to define the interaction between the organisation as a whole and its stakeholders using the Stakeholder Relationship Management Maturity (SRMM®) model.

Effective and ethical stakeholder management cannot happen overnight and cannot happen in isolation. The preconceived perceptions of stakeholders towards your work are based on multiple experiences over an extended period of time, and the stakeholder-to-stakeholder conversations that occur outside of your hearing or control. To actively improve these conversations and create a positive and supportive stakeholder environment needs a long term consistent effort, organisation wide.

Bourne’s SRMM model offers a practical framework that can be used by organisations to build from ad hoc, single project attempts to manage stakeholders to a situation where stakeholder management is a core skill used by the organisation as a whole to maintain a competitive advantage. As with any culture change, this cannot happen overnight but at least Dr. Bourne’s new book provides a road map organisations can use to improve their management of stakeholder relationships to the benefit of both the stakeholders and the organisation.

Stakeholder Relationship Management: A Maturity Model for Organisational Implementation is published by Gower, ISBN: 978-0-566-08864-3

High Performance Project Management

I have just seen some information on a 2007 survey undertaken by the PMO Executive Council (part of the Corporate Executive Board: http://www.executiveboard.com/). This snapshot survey, Attributes of a High Performance PM - 2007, found very little correlation between project management certification and project management effectiveness, or the number of years a person has been in project management roles and project management effectiveness.

The survey found the drivers for project management effectiveness were behavioural attributes such as problem solving and the ability to relate effectively with key stakeholders. Whilst many people may initially want to disagree with these findings, they are consistent with many other trends and on reflection quite logical.

Firstly, the survey did not look at the PM’s track record, merely the time the PM had been in project roles. It is reasonable to assume highly effective PMs will have a relatively short PM career and then move on and up the organisational hierarchy. Less effective PMs are likely to stay in their PM role focused on process and technology.

Secondly, whilst PM credentials such as PMP remain very effective tools in the job market; passing your PMP does not make you an effective project manager (see more on PMP). The PMP knowledge framework gives you the knowledge to be an effective project manager. Being effective requires you to become a competent project manager.

Competency has three aspects, knowledge, skills and behaviour:

• what you know,
• your ability to apply the knowledge (essentially personality traits) and
• your willingness to use the skills effectively (essentially behavioural traits).

Qualifying project managers based on behavioural competencies is in its infancy. The Australian Institute of Project Management (AIPM) has recently moved its professional certification program (RegPM) from a procedural view of competency (eg, do you have a project schedule – the artefact?) to a behavioural view of competency (how effectively do you manager the schedule on your project?). This is ground breaking work.

PMI have adopted a different, but similar approach in their program management certification (PgMP) with a 360 degree review testing how effective the candidate is in the workplace. These trends have a long way to go but are likely to be the next step in project certification.

Of more direct interest in the short term is the demonstrated link between how effectively a project manager engages with his/her key stakeholders and high performance outcomes. These skills are a core element in a number of workshops we run including Successful Stakeholder Management and The Science and Art of Communicating Effectively, and are supported in part by our Stakeholder Circle® methodology and tool set.

Learning how to apply the skills in the workplace though is not quite as simple as attending a workshop or buying a set of tools. Soft skills are very hard to acquire and use. My feeling is they are called ‘soft’ because they change shape and texture depending on the environment they are being applied within. The calculations for EV or CPM are universal; the best way to engage a senior stakeholder is totally dependent on the culture of the organisation. Some elements remain consistent (eg, the need for an effective relationship) but the way this is achieved varies.

Developing these advanced skills that are the attributes of high performance project managers requires context sensitive coaching and mentoring rather then formal courses (see: Executive PM Coaching & Mentoring). Ideally organisations seeking to develop high performance PMs will move beyond certification towards implementing internal mentoring systems – it’s the best way to ensure they are contextually relevant.

However, where we differ from the survey findings is that we believe certifications such as PMP are still relevant. Passing a PMI credential such as PMP or CAPM (see more on the PMI credential framework) is a positive demonstration of the initial knowledge component of competency; it’s just that knowledge alone is not sufficient.

Achieving this next level of high performance PMs will also require organisational competence in at least two domains. Process competence measured by tools such as PMI’s OPM3® framework and relationship management maturity measured by tools such as my SRMM® framework.

These are definitely interesting times for our profession.

Agitating Agile

I have been involved in a series of posts on both my SRMM Blog (see post) and the PMI Voices on Project Management blog (see post) that have stirred up sections of the agile software development community.

Despite the Agile Manifesto focusing on providing excellence to stakeholders, many Agilists seem intent on advocating their rather extreme view of agile including no documentation, little planning or architectural design and less control. The mantra is ‘give the software developers free reign and you will get better software’. Whilst this may be true (although I somehow doubt it in anything but the smallest and simplest projects) it ignores the needs of the project’s key stakeholders.

Most IT projects exist to enhance the capability of the organisation. Consequently the software development is only one part of an overall project to change the organisation, deliver new capabilities or similar. In these typical circumstances, the IT component needs to meet predetermined requirements; any change in the IT capability delivered requires changes in other parts of the project. In fact the best IT solution may turn out to be an unacceptable business solution.

Meeting the needs of the businesses key stakeholders demands discipline and communication not just within the ‘scrum’ or XP team but to the customer’s managers. This needs at the very least a minimum of documentation to prove the IT team and its immediate customers understand their scope of work and other constraints and know how they will achieve the outcomes needed to support the business. Adequate documentation and effective communication are essential.

This post is not suggesting a return to Waterfall or other heavily documented software development process (they don’t work very well anyway – refer the Standish reports) but rather for an appropriate level of documentation to meet the genuine needs of senior management stakeholders. Saying ‘trust me’ is not enough and is not good stakeholder management.

Identifying the key stakeholders, assessing their requirements and expectations and then managing these key relationships so the stakeholders realistic expectations can be realised definitely involves up-front planning and effort, needs tools and methodologies such as the Stakeholder Circle® and involves on-going monitoring and control but is, I would suggest, worth the effort. Your project is unlikely to be seen as successful if the stakeholders expectations are not realised!

In most aspects of life the long term enjoyment of real freedom required a significant measure of self discipline. The agile extremists may do well to consider this and focus on meeting the needs and expectations of all of the stakeholders involved in their work.

Short termism -v- long term survival

Since being elected a Fellow of the Australian Institute of Management earlier this month, I have been receiving an interesting flow of new information. Two items in today’s reading are the results of an AIM survey that indicates 51% of managers believe that ‘short termism’ is a major issue of concern, 63% thought companies had a relatively short life span and 15% of company board members and CEOs surveyed were not confident their organisation would be in existence in 5 years time (source: AIM Surveys).

Contrast these views with the approach taken by one of Australia’s largest and oldest companies, BHP Billiton. BHP is preparing to spend $15 billion in South Australia to add an open-cut phase to its existing Olympic Dam underground mine. This development will involve digging more than 1 million tonnes of dirt a day for six years, before getting a dollar back. Certainly the production capability at the completion of the development in 16 years time will be massive. The ultimate aim is to boost annual uranium production at the mine from 4,500 tonnes a year to 19,000, copper from 235,000 tonnes to 750,000 and gold from 100,000 ounces to 800,000. Silver, produced as a by-product, will rise from 800,000 ounces to 2.9 million a year. At current prices that works out to annual mineral production valued at $6.2 billion (source: Forbes Asia Magazine dated July 13, 2009).

This raises two interesting thoughts. Firstly BHP must have immense confidence in the ability of its project and program managers to consistently deliver over the next 16 years. There is no easy exit point in the project – the pit needs to be 300 meters deep before encountering any of the ore body (the first six years work) and then there is the need for a series of expansions over the following 10 years to reach maximum output.

The second is the relationship between BHP and its stakeholders. The level of trust needed to accept the investment of $15 billion over 6 years in anticipation of a payback in later years is enormous. The only way this level of trust can be developed is through a long term process of effective stakeholder management linked to a track record of successfully delivering value (ie, keeping your promises).

I would suggest there are some interesting lessons to be learned from juxtaposing these two items. What do you think?

The collaborative management paradigm inherent in Agile – a new frontier

The Agile software development methodology has a fascinating range of ideas that can provide valuable learning’s to traditional project managers and in the wider sphere of stakeholder management.

Over the last few months I have been publishing a series of posts on this topic on the PMI Voices on Project Management blog. The key posts with a brief summary and links are:

Agile: The Great Debate
An overview of the Agile software development methodology and its impact on project management.

Creating Trust in Agile
Managing upwards, the trust and communication needed for Agile to succeed.

The Role of Agile Advocates
Agile advocates (AAs) need to understand their key stakeholders and empathize with their perceptions, fears and requirements.

The Gentle Art of Managing Agile
Applying the PMBOK to managing Agile projects.

Learning From Agile
The importance of customer engagement and going ‘light and lean’.

I invite you to read these posts and think on your project management and/or stakeholder management practices.

Managing Upwards

I am collaborating with Bob McGannon to develop a workshop for the PMOZ conference in Canberra (August 10-12) – Avoiding Project Manglement: Advising Upwards. The workshop brings together three streams of thought; my work on stakeholder management, a collaborative paper with Ken Farnes, From Commander to Sponsor: Managing Upwards in the Project Environment (PMI Denver 2008) and Bob’s work on Intelligent Disobedience.

The workshop will provide a forum for those interested in developing new techniques for managing the expectations and perceptions of important senior managers. The three components of the workshop are:

• Being ready, willing and able to communicate effectively with senior management.
• Being heard.
• Being extraordinary! (for more information visit the PMOZ website…)

If the workshop is as successful as we hope, the ideas will roll forward into a new book planned for 2011.

Travel Update – Tokyo

It has been 3 long weeks on the road…….

First port of call was Boston USA for the PMI College of Scheduling conference. The conference attracted well over 200 people; the numbers were down from 2008 in Chicago but not bad for the middle of a recession. My paper Scheduling in the Age of Complexity was well received and there was a wide range of other papers and key note addresses of interest. The College’s work on its Scheduling Excellence Initiative (SEI)  was progressed and is moving towards the completion of the first stage.

Second stop was the UK for 2 key meetings and some family time. The first meeting was with the CIOB manager developing their guide to scheduling good practice – this standard will have significantly more focus on the practice of scheduling than the current PMI Practice Standard. Whilst the standard will be specifically aimed at the construction industry, my feeling is the content will have wide application. More on this later….

My second UK meeting was with Gower Publishing Ltd to discuss the marketing of Dr. Lynda Bourne’s book, Stakeholder Relationship Management: A Maturity Model for Organisational Implementation. The book will be available in September and pre-publicity will commence soon.

This last week has been in Tokyo as part of the Australian delegation contributing to ISO 21500: A Guide to Project Management. Multi-national committee work can be frustrating but the feeling at the end of 5 intense days was good progress had been made building consensus and the body of the standard was close to being technically complete. As soon as the contents are signed off, the team I work on will finalise the language and glossary and subject to a vote of all of the nations involved, move the standard forward to a formal committee draft. Developing an ISO standard is a slow process, the likely date for publication will be late 2012 by the time the standard has moved through all of the drafts needed to ensure international acceptance. ISO 21500 is designed as an overarching standard to help bring coordination and commonality to the various underlaying national and industry standards such as the PMBOK® Guide.

Now all I need is a quite flight back to Australia and its back to the backlog of mail and business. More later.