Across industries (and nations!) there's a tendency to fix problems with process - often from 'lessons-learned' debrief sessions following troubled projects. Failings in the delivery processes are identified and 'fixed' by adding more process steps - typically new checks or gates specific to that unique failure.But projects are generally '1-off' activities that deliver a single outcome - unlike 'business-as-usual' operations where the same process steps are repeated again and again. The root causes of failure often lie in the fundamental complexity of the business and the interaction between change and 'business-as-usual' activities. In these cases, the 'process improvement' approach can be like putting out fires with gasoline, as the additional process only adds to the complexity that fuels the problem.Ever more processes can effectively disarm the project manager, taking away their most valuable weapon – the ability to respond to unforeseen events in a timely manner. You cannot build a process to account for 'Black Swan' events, which happen all too often in any 1-off activity - like project delivery.Project Managers and the governance team need to exercise control and should not be shackled by excessive time-consuming process and needless layers of complexity.Our studies have shown that process compliance activities have often been thoroughly overdone, and the huge investment in process improvement and methodologies over the last 20 years has barely lifted project success rates from 40% to 50%.The net effect is that many businesses are suffocating under more 'red tape' than Government agencies - at a cost of more than $100bn annually for Australian businesses.

Most people go to work intending to do a good job, and it's worth taking a step back to explore how individuals' behaviour is actually a response to the drivers, motivations and incentives placed on them by the company they work for.There are certainly instances of bad behaviour leading to devastating project delivery failures. More commonly, people act in accordance with the organisation’s incentives and respond to their agreed (or implicit) performance measures when making decisions. Those incentives and measures often drive them in the wrong direction when there is a conflict between their business-as-usual and project delivery priorities, because business-as-usual incentives and drivers are often more well-developed and explicit.Imagine that your Key Performance Indicator (KPI) is 'operational delivery,' and you're given a choice between supporting the status quo and disrupting delivery as a part of the change process. How many staff are going to take the 'brave' option when they suspect it will eventually show up in their performance review?Staff working for suppliers (or customers) may also face a misalignment of their drivers between organisations. If the tasks your project requires are not the most profitable work they could be doing for their business, they may have strong incentives to focus their efforts on other, more profitable activities, even though your project will be delayed.Thus, it's often 'good' behaviours - ones that make us good employees as defined by our organisations – that lead to project failures.

A survey of chief executives, board members and senior executives, respondents consistently indicated that project managers and their teams were typically blamed for project failures, while they felt that the bulk of the blame lay with the executive teams performing project governance functions.This blame structure is entrenched in the 'process improvement' approach, where the 'lessons learned' debriefing process often pays little or no attention to the performance of the project governance teams. Few questions are asked about this key function, and the staff involved need considerable courage to criticise their bosses unprompted. In practice we don’t encounter much criticism of this area.We encourage all delivery organisations to look closely at how their governance teams are trained in their roles, with performance measures (or similar) to ensure they are meeting their delivery obligations.In most instances of project failure, we've found that much of the problem lies at governance level.

Why there are so many examples of poor supplier behaviour?The problem starts with contracts being used to manage 'supplier risk,' transferring appropriate risks and, opportunistically, also risks that  the supplier is unable to control or manage. Penalties (and sometimes incentives) are included to drive the desired delivery performance.Just like staff in your organisation, the suppliers' staff have incentives, performance measures, and KPIs, and they seek to do a good job for their employer. When faced with decisions that balance your contract against competing priorities or resource commitments, they will depend on their performance measures. Those measures are designed to deliver value to their shareholders, however, so when they 'do the right thing' as a valued employee, your contract may be left out in the cold.To avoid this, you need to know your suppliers as well as your own organisation and have visibility and reach into their organisation to see how they react.

Former US Secretary of Defence Donald Rumsfeld famously categorised risks into three types – the “known knowns”, the “known unknowns” and the “unknown unknowns.”Project managers can capture the known knowns into project risk registers with a mitigation plan and an assigned budget, but the known unknowns remain as 'residual risks' and the unknown unknowns are completely unpredicted events that 'come out of left field' (we like to call them 'black swan events'). These latter categories are seldom addressed or budgeted, but may be catered for with a fixed '10% contingency.'The residual and unpredictable risks often have the most impact on a project, but when they arise, there is no budget, no delegated financial authority, and often a requirement to seek steering committee approval at the next meeting - which may be a month away!This takes away the project manager’s main tool to manage risk - the ability to take timely action.

Your relationship with your customer is generally contractual, and very similar to your relationships with your own suppliers, which is discussed in Myth #4 above ('Suppliers will perform as contractually agreed').Customer staff will act and make decisions that (usually) align with the incentives and performance measures that are applied to them by their own company, and those will be focused on generating value for their shareholders, rather than on the delivery of your project.If their goals and motivators are not aligned with those of your project, they will not always choose what’s best for your contract with them. Just as you need to understand your supplier, you also need to understand your customer and have the visibility and reach to manage their behaviour based on insight into how they will behave/react.

It’s people, not organisations or processes that deliver projects and strategic initiatives - individual peoples’ actions and decisions make the difference between success and failure.Too often, management add layers of process and more gates, governance and approvals in an effort to 'control' projects and reduce the risk of failure. 6-Sigma and continuous improvement techniques are designed to remove variability from business-as-usual processes, but when applied to project management they remove the very flexibility that project managers need to react to issues and ensure successful delivery.Projects are, almost by definition, 1-off exercises. They inevitably require learning, coping and dealing with unforeseen events. Flexibility and speed are key to successful delivery and project managers and governance teams must be empowered, to succeed.For example, installing the same ERP system on many customer sites will involve projects with considerable commonality, and might tempt us to create a 'production process' based on a standard 'cookie cutter' model. But each customer and site is likely to be different and will have different people with different motivations and performance measures.Too strict a process structure will prevent the team from responding flexibly to these differences and issues that a clever and empowered project manager could easily resolve, can escalate into project-killers if the team lacks the freedom to act effectively.

It’s standard rhetoric that The Steering Committee (or its equivalent by another name) must be 'independent,' but they seldom are in practice - in fact, they’re usually inherently conflicted.Steering committees are expected to make decisions that support the project manager in delivery, but the committee will generally include representatives from the business units affected by the projects they're overseeing. These individuals will have performance measures and incentive structures aligned with their business-as-usual role, but seldom include a measure of their performance in supporting projects.When it comes to the crunch, there will be a natural bias towards decisions that support their performance measures - choosing business-as-usual priorities over project delivery.

Enterprise Resource Planning (ERP) systems are operationally and internally focused and provide comprehensive visibility into their host organisation and its business-as-usual performance.This leaves you partially 'blind':Customers, partners and suppliers also form critical parts of the project delivery organisation and your ERP system is unlikely to provide any visibility into those organisations - or to provide visibility to them.ERP systems focus on comprehensive control of efficient business-as-usual operations and seldom have strong facilities for managing change, though some have basic add-on products for this.Effective delivery governance requires a small amount of critical information that is developed and managed for the purpose - not the comprehensive operational information generally provided by ERP systems.Reach, visibility and focus are key elements for understanding the project delivery ecosystem and ERP systems (and other operational support IT systems) are not designed for this specific task.

Big Data refers to the aggregation of masses of data that cannot be processed effectively using basic relational database techniques. It is also loosely used to describe the analytical approach used for the analysis and management of operational and financial performance information of an organisation.Data analytics is used on aggregate data to identify trends, extract insights or correlate other attributes of complex data sets and can be very useful for extracting customer insights, assisting in market planning and forecasting and related business functions.This sort of analysis requires aggregation and analysis using statistical or other related methods which tend to focus on averages, correlations, trend analysis, extrapolation and an overall view of the data set, rather than on identifying the few critical elements for project delivery management.Unfortunately, strategic initiatives and projects do not lend themselves to statistical analysis. They are one-off activities with a sample size of 1, and while the data can, for instance, say that all previous projects have been delivered on time, the next project may be a complete failure. Reliance on past performance is no indication of future performance.Each initiative or project can only be measured as it happens. Information – rather than data - is needed in near real time to enable corrective actions to be taken in a timely manner and to ensure visibility. “Big Data” or data analytics are not current, but “after the fact” and are subject to statistical approaches.