So you have your opinions on why projects fail.

Maybe you think you have the answers. At times, we may all think that way.

But have you taken some time to consider what anybody else thinks?

Have you had a dialogue to compare notes and reflect?

 

This has been my underlying driver for researching why projects fail in the natural resources sector. Why we are continuing to face such high cost overruns, and extended schedules within our projects? And why do our stakeholders never seem to be satisfied with the outcomes?

Working in the mining sector, and oversight of projects within that realm, I always felt it was easy to see where blaring issues arose. I could always spot the gaps, from my perspective, and within my realm of experience. As likely all people can do - within their range of experience. The problem is, the things you can spot are never the only things going on. 

We are blind to what we don’t know.

And sometimes the things we might point out are a problem, but they aren't really at the top of the priority list to fix. In the past, this frustrated me, but I get that now.

In a complex system,

there are often much bigger problems

that need to be handled FIRST.

But still - I wondered: how can we avoid getting into these situations in the first place?

 

So, in that light, over the last year I dug into a broader perspective of why projects ultimately fail. I reviewed articles, blogs, forums and more on project management and mining, from numerous sources and varying perspectives. My last post summarized some of the key issues I found at the intersection of risks to mining developments and project management through the extended mining project life-cycles. 

But I felt more needed to be investigated. So I started interviewing people within (and outside of) the mining sector. People who worked on projects, who managed projects, who were stakeholders of projects, and even some people in management roles outside of projects.

What came of this exercise was interesting.

 

Commonalities

Of all the dialogue on why projects failed, there were a number of common themes that arose.

Out of these emerged a high level root cause analysis, at least from my perspective (since for this particular step I did not re-engage my stakeholders, or expand that circle!) But all the same, it is an opinion based on the feedback of others and a starting point for further discussions.

And now is your chance to give that stakeholder feedback, in the comments below.

I’d love to hear your thoughts!

 

In an almost sequential breakdown, these were:

Poorly defined scope, schedule, budget and quality

This was sometimes also described as insufficient accountability to meeting targets in all categories (i.e. delivered product on time, but poor quality and way over budget). Several areas of concern could inadvertently impact scope definition:

1. Insufficient respect of PM role and PM processes to appropriately plan and keep things on track / in scope (i.e., seen as overhead, unnecessary time and cost) - possibly compounded by PMO insufficiencies: too many steps; missing important steps; not based on risk or tailored to the industry needs
2. Insufficient identification or communication of risks in planning and / or in change management instances; unknowns about environmental assessment requirements and timing; no lifecycle review of risks or assigned too low risk rating
   1. Inexperience of various roles: tech level promoted to PM; PM from external industry; lack of experienced technical specialists (estimators, designers); lack of skilled labour pool. And in the case of junior mining companies, sometimes inexperienced management…suggested that they are not prepared for all the needs for the approval process of a mining development 
   2. Insufficient knowledge resources: lack of knowledge base to learn from; lack of its use where present, or insufficient information within; insufficient use of very experienced SMEs; not capturing and utilizing lessons learned from after project closure/transfer to operations
   3. Communication barriers: the presence of working silos, poor team bonding; lack of trust and “safety” for project individuals to speak up, give opinions without penalization; poor alignment of team on project goals
3. Major differences in the level of design detail between feasibility (40-50%) and detailed design (80-90%): risks at early stages are typically assigned as contingencies on the scope at that time. (The next set of issues indicates the importance of this one main point.)

Poor tracking of changes in scope between stages

The major changes made in scope between lifecycle stages are usually caused by growth or shrinkage of size or complexity of project due to funding, a change in risk tolerance, or shifting objectives of client. These are often not well documented or tracked as change to baseline, but rather the corresponding stages are initiated as a 'new' project. 

There were three many causes noted for the poor transparency and documentation:

1. Poor level of ownership to plans and decisions previously made, or to achieving original baseline (i.e., PMs new to the project may simply adjust scope and baselines rather than tie back to scope from an earlier stage)
2. Major turnover of personnel or shifting teams from one stage to the next - turnover occurring for both projects personnel and stakeholders
3. Extended duration in time between early definition / feasibility evaluation and execution stages of projects, particularly when projects are temporarily ’shelved’ or paused between stages to accommodate spending distribution between annual budget cycles.

Poor ownership and buy-in to change initiatives and improvement programs

In some cases, mining projects arise due to a corporate change initiative or improvement program. Failure to first gain buy-in and support of the initiative itself will result in problems with the associated projects. Gaps discussed included:

1. Education and engagement of the people who need to be involved in the change implementation is critical
2. To understand how to target the best education and engagement methods, the leads need to understand who they are dealing with, including their personalities, mentalities, comfort level with change and working in a less-than-rigid framework - this will vary with every team
3. In the case where a change or improvement is questioning standard practices or criteria, this can put people on the defensive, particularly when trust is low

 

The worst outcomes of these issues?

The consequences of these underlying problems show up as unplanned risk occurrences - 

during the execution or construction phase. 

When it is most costly to make changes and when most companies would not consider "going back” or cancelling the project. They simply find the time and money to finish the job, taking a significant hit to the bottom line for the project, and it gets tagged as a project failure.

 

Second, for the unidentified risks that did not rear their heads during execution?

These occur AFTER transfer to owner / operator.

So now the owner faces additional costs & impacts during operations, or even later (in the case of impacts that aren’t apparent until the longer term). So not only is the organization having to be responsive vs. proactive, which can be more costly overall, but this can also often have an impact on its external reputation.

 

Recommendations 

Fortunately, all these fine people interviewed not only shared challenges, but also some recommendations as well. 

To facilitate clear and complete scope definition:

• Stress on iterative and early planning - nearly everyone agreed on this aspect!
• Ensure involvement of very experienced SMEs (i.e. those who have scar tissues of previous failures or insufficiencies);
• Include a combination of internal and external specialists (including construction, operational, and maintenance personnel);
• Increase use of organizational (and external) knowledge base and lessons learned from past projects, similar projects by others, and operational issues that arose following past relevant projects
• Ensure external stakeholder comments / concerns factored into scope planning in some way or another

To prioritize multiple and competing objectives, drivers, or influences:

• Identify risks against achieving each objective
• Assess these to prioritize and make decisions on how to address each (use overarching governance if need be)
• Engage teams to work together to find options / solutions for addressing all risks, and to always keep end goals in mind (helps with alignment of teams too!)
• Use quantitative decision analysis to facilitate better, less-biased decisions on options and areas to assess in more depth BEFORE finalizing scope

To reduce risks of changes made through lifecycle:

• Make sure gate requirements are clearly and directly tied back to scope requirements
• Make sure gates have been met and SIGNED off by all stakeholders
• Ensure tracking of changes made between lifecycle phases, not just during execution of each phase…as noted above, many decisions are made on what to include in the next phase scope based on the economics at the time of each gate
• Ensure decisions made on scope, and changes to scope, incorporate lifecycle financial impacts to the business model (i.e. have to look at changes to both CAPEX and OPEX, all costs in, and in a non-discounted cashflow analysis)

To improve level of ownership of project: 

• Assign the lead / owner role to a person from the install site vs. a corporate role or within the PM office
• Consider a possible PM redundancy (particularly for very complex projects)
• Ensure communication of the full value proposition / business impact of successful project delivery for PMs to understand, convey and motivate teams with
• Ensure a clear, well-documented connection between components of delivery (and decisions for those) to risks, objectives and benefits

To help reduce unplanned risks or changes during construction execution: 

• Increase exposure and hands-on experience of new planners / designers to field conditions (stressed by many), to improve the understanding of:
  • WHAT the designer is asking of those to build, operate and maintain
  • Risks associated with field conditions or labour available
  • Practicalities and barriers that exist in the field
• Ensure use of SMEs in planning AND review of all project stages

 

Opposing thoughts

Of course, I think it safe to say that one can never have the perfect alignment of all stakeholders on just what the problems and solutions might be. (It’s why we need to work together to take the best of both sides and find the things that everyone can agree on, that meet all the objectives, and so we can make traction!)

Many differences of opinion hovered around aspects about the project manager, and project management realm, in general.

Sector-Specificity

First, there came the question of whether the PM requires sector-specific knowledge or not.

Experienced PMs suggested it is not necessary to know the sector inside-out to achieve project success, as they would bring in SMEs as necessary to ensure that. In contrast, personnel within mining (at all levels interviewed) suggested that it was not only necessary from a credibility and trust standpoint for the PM to know the sector well, but also required in order to make quick decisions without introducing risks. 

The split on this one was quite extreme - mainly one way or the other, without many in the middle.

What say you?

Project Management Processes

The second dichotomy came with respect to the value placed on project management and reporting requirements placed on projects. Some felt that the requirements can often be a burden or add unnecessary time and cost, slowing things down, and that oversight on projects (i.e. external or corporate review of project scope and details) was of no value due to a lack of direct ownership in project delivery by those doing the review.

The opposition thought oversight brought great value, as it allowed use of the SMEs (who have scar tissue) to capture and address risks unseen by others. These proponents for PM standards suggested that designers, sponsors and stakeholders should be better educated on the value and need of the PM skill set, role & responsibilities.

They additionally felt that there should be more tracking about details on who and how goals of projects, decisions made, etc. were achieved, to help show this value and to help give credit, build trust and transform the view of the PM role. 

Stakeholder Involvement

Finally, and perhaps less of a contrasting position, but more of a cautionary one, was regarding the concept of bringing in external stakeholders at very early (evaluation) stages of a project - and not just for input, but also in support of making decisions.

Most agreed that this can be beneficial, but that it needs the right balance. Comments included: 

• "Too many cooks" leads to too much debate and too little traction
• Too many in the room results in poor engagement, and ineffective use of everyone’s time
• Planning of this is critical - evaluation is required to determine who gets brought in and when, and should be staged appropriately
• Clear communications is key
• It should primarily involve the people doing the key selection of options.

Maybe some of these differences of opinion are simply dependent on the organizational client - their structure and willingness to break down silos and collaborate, their risk tolerance, the number of stakeholders and their varying opinions…the list goes on. 

The key thing for these differences is to gain an understanding of these factors when kicking off a project, and ensure that those types of risks are addressed within the planning!

 

Closing

In closing, I stopped trying to find a short and simple way of summing this all up. I honestly felt I’d simply be repeating much of what has already been said because there are so many good points. Plus, as mentioned at the beginning - this is merely a compilation of interview results and not a full stakeholder engagement.

What I will say are two things:

THANK YOU! 

Thanks to all those who participated in these interviews, and thanks to all of you who have read through to this point. If you recognize your comments as a contributor, and feel that I have misconstrued anything in any way, by all means please do correct me! As a reader, if you strongly agree or disagree with anything you've read, please comment away.

Second, the key takeaways I had - from these interviews AND from the online research - was that we need a better way to collectively gather all the requirements for our projects, through early and thorough stakeholder engagement, and at the earliest evaluation stages. 

We need that process to be clear, collaborative, easily managed, and useful for collection of information, communications and review - for purposes of scoping, record keeping, for use in managing changes, and for use as lessons learned on future projects.

To address these aspects, I’ve developed a training module to facilitate more thorough requirements gathering, where the use of visual planning tools will support stakeholder engagement, decision making and understanding project risks, opportunities and interdependencies.

To learn more about this opportunity, please review “Mining 4 Requirements,” or just give me an indication of your interest in the comments below, so that I may get in touch with you.

 

Now it’s Your Turn

What are your thoughts on these results?

What stood out for you?

What one thing do you think should be addressed first?

Will training in the area of requirements gathering be beneficial, and move things in the right direction? 

Please submit your views below!