Tag Archives: complexity

The limitations of root cause analysis

Learning lessons from projects is not as simple as you may think! Projects are complex adaptive systems linking people, processes and technology – in this environment, useful answers are rarely simple.

Certainly when things go wrong stakeholders, almost by default, want a simple explanation of the problem which tends to lead to a search for the ‘root cause’. There are numerous techniques to assist in the process including Ishikawa (fishbone) diagrams that look at cause and effect; and Toyota’s ‘Five Whys’ technique which asserts that by asking ‘Why?’ five times, successively, can you delve into a problem deeply enough to understand the ultimate root cause. The chart below outlines a ‘Five Whys’ analysis of the most common paint defect (‘orange peel’ is an uneven finish that looks like the surface of an orange):

These are valuable techniques for understanding the root cause of a problem in simple systems (for more on the processes see WP1085, Root Cause Analysis); however,  in complex systems a different paradigm exists.

Failures in complex socio-technical systems such as a project teams do not have a single root cause. And the assumption that for each specific failure (or success), there is a single unifying event that triggers a chain of other events that leads to the outcome is a myth that deserves to be busted! For more on complexity and complex systems see: A Simple View of ‘Complexity’ in Project Management.

Complex system failures typically emerge from a confluence of conditions and occurrences (elements) that are usually associated with the pursuit of success, but in a particular combination, are able to trigger failure instead. Each element is necessary but they are only jointly sufficient to cause the failure when combined in a specific sequence. Therefore in order to learn from the failure (or success), an approach is needed that considers that:

  • …complex systems involve not only technology but organisational (social, cultural) influences, and those deserve equal (if not more) attention in investigation.
  • …fundamentally surprising results come from behaviours that are emergent. This means they can and do come from components interacting in ways that cannot be predicted.
  • …nonlinear behaviours should be expected. A small change in starting conditions can result in catastrophically large and cascading failures.
  • …human performance and variability are not intrinsically coupled with causes. Terms like ‘situational awareness’ or ‘lack of training’ are blunt concepts that can mask the reasons why it made sense for someone to act in a way that they did with regards to a contributing cause of a failure.
  • …diversity of components and complexity in a system can augment the resilience of a system, not simply bring about vulnerabilities.

This is a far more difficult undertaking that recognises complex systems have emergent behaviours, not resultant ones. There are several systemic accident models available including Hollnagel’s FRAM, Leveson’s STAMP that can help build a practical approach for learning lessons effectively (you can Google these if you are interested…..)

In the meantime, the next time you read or hear a report with a singular root cause, alarms should go off, particularly if the root cause is ‘human error’. If there is only a single root cause, someone has not dug deep enough! But beware; the desire for a simple wrong answer is deeply rooted. The tendency to look for singular root causes comes from the tenets of reductionism that are the basis of Newton physics, scientific management and project management (for more on this see: The Origins of Modern Project Management).

Certainly starting with the outcome and working backwards towards an originally triggering event along a linear chain feels intuitive and the process derives a simple answer that validates our innate hindsight and outcome bias (see WP1069 – The innate effect of Bias). However the requirement for a single answer tends to ignore surrounding circumstances in favour of a cherry-picked list of events and it tends to focus too much on individual components and not enough on the interconnectedness of components Emergent behaviours are driven by the interconnections and most complex system failures are emergent.

This assumption that each presenting symptom has only one cause that can be defined as an answer to the ‘why?’ is the fundamental weakness within a reductionist approach used in the ‘Five Whys’ chart above. The simple answer to each ‘why’ question may not reveal the several jointly sufficient causes that in combination explain the symptom. More sophisticated approached are needed such as the example below dealing with a business problem:

The complexity of the fifth ‘why’ in the table above can be crafted into a lesson that can be learned and implemented to minimise problems in the future but it is not a simple!

The process of gathering ‘lessons learned’ has just got a lot more complex.

Linking Innovation to Value

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Defining Complex Projects

There has been a lot written about ‘complex project management’ over the last few years much of which as confused projects with programs, complexity with big and complexity with complicated technology. For an overview of complexity theory see: A Simple View of ‘Complexity’ in Project Management.

A sentence in the paper ‘Translation and Convergence in Projects: An Organisational Perspective on Project Success’ (Project Management Journal, Sept.2011) triggered this post and sums up project complexity nicely: “The key difficulty with complex projects is that those managing them will often be ‘feeling their way’ towards a solution rather then following a reliable blueprint or project plan”.

Our view has consistently been that complexity is a function of complexity theory and it is a dimension of every project and program. This means every project has a degree of complexity in the same way that it has a defined size, a degree of technical difficulty and a degree of uncertainty, and all 4 dimensions interact and affect each other. These four dimensions are discussed in the Mosaic White Paper at: http://www.mosaicprojects.com.au/WhitePapers/WP1072_Project_Size.pdf.

What the thought from the paper above highlighted is the very close linkage between complexity which we see as being primarily a function of the project’s stakeholder community and the degree of uncertainty associated with the project outcome. Our blog post, Projects aren’t projects – Typology outlines one way of measuring uncertainty based on a model by Eddie Obeng.

I’m not sure how to measure this empirically yet, but I do have a feeling there is a need to define a measurement system that incorporates the type of uncertainty within the overall matrix of stakeholder engagement and supportiveness already embedded in the Stakeholder Circle® methodology – any thoughts will be appreciated.

See our earlier posts on Complexity.

Black Swan Risks

A black swan???

Black swans are becoming popular in far too many places! Not too many people would confuse Daffy Duck with a black swan but when it comes to risks, it seems too many people are prepared to accept anything with black feathers is a black swan….

I have just finished a really interesting discussion with Bob Prieto on the subject. Bob’s article in January’s PM World Today discussing ‘black swan risks’ and my letter to the editor in the February edition set the framework (the PMWT website has closed).

The key definition of a ‘black swan’ proposed by N.N. Taleb is that the ‘black swan’ was unpredicted and unpredictable, but in hindsight it appears that it should have been foreseeable. Birds have a range of different plumages, there is no reason not to presume swans could not have other colours but equally, but in the 18th century, there was no reasonable basis to assume swans would be anything but ‘white’ (view links to further discussion).

Another black swan...???

Following on from the debate, the challenge I see facing management is in two parts firstly providing sufficient rigour in the assessment of risks to encapsulate most of the reasonably foreseeable risks and making appropriate decisions based on a proper understanding of the issues. The key issue in the 2000 Ericsson semiconductor factory fire highlighted in Bob’s article was not the fire, it was the single source of supply, creating a critical single point of failure. Many events: fire, earthquake, industrial, environmental and dozens of other causes could have shut down the factory. Add all of the individual low risk occurrences together and the likelihood of the factory being out of business starts to increase. This seems to be exactly the same scenario that played out in the BP Deepwater Horizon disaster. The compounding effect of multiple individual decisions caused the disaster. Any one decision on its own was probably OK, the combination was not. Understanding the whole cannot be based on rigid rules the interactions are far too complex, Practical Wisdom  is needed.

The second is building adequate resilience into an organisation to cope with both the accepted high impact low probability risks and the unknowable unknowns that are genuine ‘black swans’. This involves having some spare capacity and some rehearsed disaster management processes. This may not be 100% cost effective but the damage caused by having no capacity to deal with major problems is far worse.

Real black swans

The final thought is ensuring you have an effective system for watching the environment to identify as early as possible the emerging problems. As Josh Billings said “It ain’t so much the things we don’t know that get us into trouble. It’s the things we know that just ain’t so!”  The idea of Black Swans is a valuable concept that warns us to expect the unexpected even after we have implemented effective risk management! The only certainty is uncertainty, and we need to remember that we will continue to be surprised even if we have implemented the most effective risk management strategies. For more ideas and resources, visit our Practical Risk Management page.

Guide to Good Practice in the Management of Time in Complex Projects

Wiley and the Chartered Institute of Building have just published a new book, the Guide to Good Practice in the Management of Time in Complex Projects. The primary purpose of this Guide is to set down the standards necessary to facilitate the effective and competent management of time in complex projects. It defines the standards by which project schedules will be prepared, quality controlled, updated, reviewed and revised in practice and describes the standards of performance which should reasonably be required of a project scheduler.

Delayed completion affects IT, process plant, oil and gas, civil engineering, shipbuilding and marine work contracts. In fact it affects all industries in all countries and the bigger the project, the more damage delayed completion causes to costs, to reputation and sometimes, even to the survival of the contracting parties themselves.

In simple projects, time can be managed intuitively by any reasonably competent person, but complex projects cannot and a more analytical approach is necessary if the project is to succeed. Although much has been written about how to apportion liability for delay after a project has gone wrong there was, until recently, no guidance on how to manage time pro-actively and effectively on complex projects.

The Guide has been developed as a scheduling reference document capable of wide application. It is a practical treatise on the processes to be followed and standards to be achieved in effective management of time. It can be used in any jurisdiction, under any form of contract, with any type of project and should be identified as the required standard for the preparation and updating of contract programmes, progress reporting and time management.

I may be biased, my partner was part of the team that developed The Guide and it recognises the importance of involving stakeholders in the development of the schedule, but I feel it has a lot to offer project planners and schedulers on any type of project.

For more information;
in Australia see: http://www.mosaicprojects.com.au/Books.html#CIOB_Guide elsewhere, http://eu.wiley.com/WileyCDA/WileyTitle/productCd-144433493X.html

Using a Risk Management approach for Assessing Claims

One of the more difficult management decisions is how hard to pursue a contract claim. The claim will inevitably have a deleterious impact on a key stakeholder relationship and any significant claim will have proportionally high costs associated with legal and other expenses. Balancing the inevitable costs against the possible gains is a difficult but necessary decision before moving forward. Usually, the potential yield of a claim is given as a subjective assessment based on experience.

Dr. John Lancaster of Hill International has recently published a paper that seeks to remove the subjectivity from the assessment of which claims are worth pursuing (see 1 below). Lancaster proposes using a risk assessment approach to determine the likely range of outcomes and which claims contribute the most to the likely settlement. He suggests using the following factors:

  • Entitlement confidence:
    • The strength of the contractual argument for entitlement; and
    • Contractually compliant notices.
  • Magnitude confidence:
    • The quality and quantity of supporting records;
    • The quality of the project schedules (and any necessary corrections and/or repairs), cost records, etc; and
    • The certainty with which the effect/s of each event is known.

Applying a percentage weighting to these factors and using Monte Carlo analysis the likely range of cost and time outcomes can be assessed and the key claims identified.

It is important that the right people complete this assessment: the entitlement confidence categories should be assessed by counsel and the magnitude confidence categories assessed by the domain experts with input from the project staff.

The results of this analysis will identify:

  • The likely outcomes under the prevailing entitlement and magnitude confidence ratings;
  • The probabilities of securing different outcomes; and
  • Identifying the claims that are the most important to the overall claim and which ones require more work.

Based on this assessment and after factoring in the costs and consequences of making the claim, pragmatic decisions can be made on:

  • whether or not to pursue a claim;
  • where to set negotiation limits (see 2 below); and
  • which of the claims, with more work on establishing entitlement and/or substantiation, could contribute the most to a robust claim.

In an ideal world effective stakeholder relationship management would remove the need for contractual claims. When they become necessary, Dr. Lancaster’s ideas will help remove much of the unnecessary ‘heat’ from the assessment process and provide a pragmatic baseline for managing any claim in a professional and business like way.

  1. Lancaster, John, “The use of risk analysis techniques to evaluate potential delay claim outcomes,” Project Control Professional: The Journal of the Association of Cost Engineers, February 2010. The full article is available on request from johnlancaster@hillintl.com.
  2. For more on dispute management and negotiating see: http://www.mosaicprojects.com.au/WhitePapers/WP1049_Dispute_Management.pdf

Command or Control?

The military doctrine of ‘command and control’ heavily influenced the structural approach to management characterised as ‘Scientific Management’ and the works of Taylor (1911). Scientific management assumes, amongst other things, that ‘supervision must be achieved through a clear chain of command and through the application of impersonal rules’ and that ‘only those at the top have the capacity and opportunity to direct the enterprise’. This philosophy has strongly influenced the development of project management (see: The Origins of Modern Project Management). But does this represent effective military management?

Following the defeat of the Prussian armies by Napoleon at the battles of Jena and Auerstedt in 1806, the concept of ridged process-oriented command and control structures has been progressively replaced by the concept of ‘auftragstaktik’, or directive command. These ideas were originally championed by Major General Gerhard von Scharnhorst and were formalised by German Generalfeldmarschall Helmuth von Moltke who was the chief of staff of the Prussian Army for thirty years from 1857.

The core concept of auftragstaktik is ‘bounded initiative’. Provided people within the organisation hierarchy have proper training and the organisational culture is strong, the leader’s role is to clearly outline his/her intentions and rationale. Once this is understood, subordinate personnel can formulate their own plan of action for the tasks they are allocated and design appropriate responses to achieve the objectives based on their understanding of the actual situation, exploit opportunities and mitigate problems.

The investment necessary to achieve this capability is not simply a question of financial and material resources – time is critical both for the training of individuals and the development organisations. In von Moltke’s army, a junior Prussian commander exercising his initiative on the battlefield was most likely drawing upon a variety of resources at his disposal including:

  1. his understanding of his commander’s explicitly stated directive that would have provided him with an appreciation of the situation, a specific task, and a description of the commander’s intentions;
  2. his beliefs about his organisation, his role within that organisation, and the degrees of freedom available to him in the exercise of that role;
  3. his expertise in the technical aspects of the military profession and
  4. his understanding of his commander and his peers.

These latter aspects are captured in the notion of ‘implicit intent’, would provide him with the basis for his course of action and bound the solution space available to him.

A General may wish to defend a city, a Brigade Commander defend his designated sector and within the sector, a Platoon Commander may be tasked with establishing a road block which involves one of his NCOs establishing a strongpoint. The General does not need to instruct the NCO on how to site the strong point, camouflage it or man it. At each level, good leaders will think ‘two levels up’ and provide oversight ‘one level down’. The process is not random, Standard Operating Procedures (SOP) define how specific tasks should be accomplished and ‘bounded initiative’ allows the individual leader to optimise the SOP for the specific circumstances he or she encounters to best support the overall intent of the commander. Von Moltke emphasised that he wanted to ‘steer’ initiative in the right direction.

These concepts are closely aligned with the human resources approach to management, which developed in the 1950s and 60s and emphasise a symbiotic relationship between individuals and organisations where ‘democratic leadership is the most effective means of managing’ and ‘openness and participation are the most effective means of demonstrating democratic leadership’.

On very small projects, a project manager may be capable of directing and controlling the work of everyone in the team. However, as soon as the team or the technology grows beyond a relatively simple system direct ‘command and control’ becomes impossible and attempting to impose a ridged hierarchy based on formal instructions will lead to inefficiencies. Effective leaders need to establish clear guidelines and a system of protocols, chain of command, and standard operating procedures so that everyone in the project team knows what they to do and who is accountable. The overall action of the team is unified by the leader’s intent; within this space sub-teams and smaller work groups are allocated their individual missions and tasks within that higher intent. Once this framework is in place, properly trained team members can go straight into the performing stage of their activity.

This alternative to ‘command and control’ developed by the Prussian military in the 1860s allows a far more effective and efficient use of resources. Auftragstaktik is not an easy option, the team needs better leadership, better training and the willingness to engage in taking ‘bounded initiatives’ but overall it offers a much better way of achieving the project’s objectives.

Applying these concepts does not reduce the importance of the normal project management artefacts such as the schedule and cost plan; what changes is the way these artefacts are used. In a decentralised management structure, the Project Plan defines the guidelines and framework the team will work within rather than attempting to prescribe how they will work (for more on this see: Project Controls in the C21 – What works / What’s fiction).

If it can go wrong……

One derivative of Murphy’s Law is: If it can go wrong it will go wrong, usually at the most inconvenient moment!

Planning the assault

This post may be old news to many European’s but in November 2009, the 27-kilometer (16.8 mile) Large Hadron Collider (LHC), buried under fields on the French/Swiss border, suffered serious overheating in several sections after a small piece of baguette landed in a piece of equipment above the accelerator ring. Dr Mike Lamont, the LHC’s Machine Coordinator, said that “a bit of baguette”, believed to have been dropped by a passing bird (other sources suggest a malicious pigeon), caused the superconducting magnets to heat up from 1.9 Kelvin (-271.1C) to around 8 Kelvin (-265C), close to the level where they stop superconducting.

In theory, had the LHC been fully operational, this could cause a catastrophic breakdown similar to the one that occurred shortly after it was first switched on. Fortunately, the machine has several fail-safes which would have shut it down before the temperature rose too high.

Part of the LHC

Given the total cost of the project to build and commission the accelerator is of the order of 4.6 billion Swiss francs (approx. $4400M, €3100M, or £2800M as of Jan 2010) with an overall budget of 9 billion US dollars (approx. €6300M or £5600M as of Jan 2010), making the LHC is the most expensive scientific experiment in human history. Politicians are probably asking how a bungling bird could target a critical part of the machine with a small piece of bread and shut the whole system down?

A more realistic question for project practitioners is how could design engineers and risk managers be expected to foresee this type of problem? Failure Mode Analysis (FMA) may help but I can just see the reaction to someone in a risk workshop hypothesising that a bird would fly over the machine and drop its dinner precisely on target to cause the maximum damage. Theoretically possible, but hardly plausible would be a polite reaction……until after it happened.

One of the messages from books like ‘The Black Swan’ and from complexity theory  is the future is inherently unpredictable. This is probably as good an example of a ‘Black Swan’ as any I’ve heard of.

For more on the LHC see: http://en.wikipedia.org/wiki/Large_Hadron_Collider

Developing Competency

Knowledge alone is not enough! To be effective in any sphere of life you need to be capable of applying knowledge effectively to achieve an outcome; this is competency. However, to be really effective you not only need to be capable of being competent, you need to be willing to act, to use your capability effectively. Effective (ie, competent) managers need to know what should be done, have the skills to do the work and be willing to actually do the work.

Putting this into context, project managers agree that having an effective schedule is important and also know they need knowledge of CPM theory (summarised in Chapter 3 of the PMI Practice Standard for Scheduling) and their scheduling software to produce a realistic and achievable schedule. But simply creating a schedule is not sufficient – the project manager needs to make effective use of the schedule if it is going to add value to the project delivery process.

This makes measuring and assessing management competence difficult. Observing an artefact is not sufficient, it is the way the competent manger behaves that make the real difference. Fortunately, the definition and assessment of competency is based on a defined structure:

First, there are three basic elements within the project management competency framework,
- technical competencies – what you do or produce,
- contextual competencies – how you work within the organisation / environment, and
- behavioural competencies – how you operate in the workspace and interact with people.

Then each element of competence is assessed in terms of:
- knowledge (what you know – tested by CAPM and PMP exams),
- skills (the capability to effectively apply the knowledge in the workplace and the artefacts produced) and
- attitude (how willing or effective you are in applying the skills).

This is normative competence and is the structure of PMI’s Project Manager Competency Development Framework and virtually every other professional competency framework including those developed by the AIPM, IPMA and GAPPS. However, the framework dates back to the industrial age where task repetition was common and one could learn the best-in-class approaches and emulate these to deliver new tasks.

In the ‘age of knowledge’ this is probably not sufficient, competent project managers in the 21st Century need to grow beyond normative thinking and embrace transformative practice. Project management competence is shifting from a process view towards autonomy; self reference and group self organisation. These qualities empower professional project managers to perform well despite prevalence of complexity and rapid change. They develop customised solutions for each new, unique, occasion; implementing the new solution requires the use of existing knowledge but will also generate new knowledge.

This constructivism theory has a basic assumption that each time you perform a new activity you build on your existing knowledge to acquire new insight and competence, and consequently engage in continuous learning. To be really effective, the organic ‘on-the-job’ learning should also be reinforced with the acquisition new information from journals, innovative courses, discussions with colleagues and participating in communities of practice.

Consolidating the new learning into tangible and useful knowledge needs reflection (to understand what has been learned) and possibly the assistance of a mentor to help unlock the complex factors needed to grow within yourself, develop creative solutions, and find new ways to succeed.

Yesterday’s competence is the foundation on which you can build tomorrows, but relying solely on yesterday’s skills is insufficient! Competent project managers know they need to keep learning and developing.