A Framework for Assessing Project Challenges and their Potential Solutions

Having worked on and supported major capital projects from concept to EPCI delivery for over 20 years, I've seen a wide swath of challenges, mitigations, and solutions that impact the ultimate success of projects. While recapping all of those could fill (many) books, I wanted to put together a series of articles which focused on a few key aspects of these stemming from experiences in delivery, operational/functional support, and engagement between project teams, IT, and software vendors.

Any of you who have heard me present over the past decade or so know that I'm passionate about driving forward continuous improvement, value-additive solutions, and leveraging digital transformation to help ensure project success. While the carrot is there, often times we are still chasing it, not grasping that final satisfying bite.

Why is this?

We'll dive into that during the articles because the details matter, but there's a common thread in many of the topics and that is often a lopsided focus between People, Processes, and Tools as well as misapplication of Lessons Learned impacting one or more of these elements. Without appropriate balance and due diligence on each, 'solutions' will fail or not achieve their potential greatness.

Each of these core elements carry their own potential challenges and approaches for success which are touched on below.

Before we get to that, we need to touch on the first thing:

Define the Problem

'The Problem' you are trying to solve has to be identified first. Without defining the problem and fully understanding WHY you have the problem, you at a high risk of coming up with the wrong 'solution'. The right solution to a problem might just be a simple process fix, or maybe it's a training issue, or maybe there's a bug or configuration change that could fix it. Not everything needs a brand-new solution and tool.

Dive into it, do a root cause analysis, get the impacted people all in a room and tear the problems apart piece by piece. Brainstorm solutions. This needs to be a highly iterative and interactive process.

Once you've settled on the problem, don't lose sight of it. If the solution you're aiming for is a new implementation of a tool, or a major change in process, it's easy to get distracted or get caught in the momentum of an initiative and not realize that you're down the wrong path.

If you're in the energy industry or AEC, I bet you've seen a 'Stop Work' philosophy from a safety perspective. Your entire team should be empowered the same way during your initiative. Lose sight of the problem? Stop Work! Pause, re-assess, and make sure you get back on the right track.

At the end of the day, your goal is to solve a problem or a challenge, don't forget it!

People

Often considered lower in priority during problem analysis, People are the first point that need to be considered! People do the work on projects and are the primary interface with Clients, Project Team members, and the Supply Chain. Like it or not, your solution - be it Training/Organizational Change, Processes or Tools - will succeed or fail based upon the People working on the project. Failure to consider the People who will actually do the work will result in ultimate failure or at least reduced success of implementation of change. Capturing their challenges, needs, and what they value most in the context of the problem you're solving will help guide later decisions.

That said, company culture and how change is implemented also plays a key role. Fostering an innovative and 'all ideas are welcome' sprit is great during development, but sometimes you also must draw a line in the sand and adopt a mantra of 'debate is over, it's time to do' once a direction has been agreed upon otherwise you'll endlessly look for the next big thing and not realize the value of what you've already got! Each scenario we look at going forward, I'll touch on the People aspect first.

Processes

There's a saying of "Don't digitize a bad process" and this is absolutely true. Problems and challenges linked back to processes must undergo some level of root-cause analysis. Likewise, process improvements must really analyze the factors which impact the processes' success or failure. Are people not following the process? Is it being done better or more efficiently elsewhere? Why do we do it this way?

My favorite story to use when diving into this is one with project teams is a study by an American Army Colonel who was assigned to assess the performance of artillery crews versus their adversaries.

To cut the story a bit short:

• American artillery crews could only fire their cannons every 30 seconds vs their adversaries firing every 10 seconds
• They'd fire, then wait 20 seconds which was per the Army Field Manual

But why? Turns out earlier versions of the Field Manual referenced the 20 seconds as time to "steady the horses". This language was removed but the time allocated to it never was.

So, when you look at your problem and you link it back to a process, are you needlessly "steadying the horses"? Are you merely going to 'digitize' (replicate the process in a computer) or 'digitalize' (reimagine leveraging technology) the process? Choose wisely here and don't forget to tie it back to the value you'll realize from it!

Technology

Too often, the first things people jump to when analyzing a problem is that we need a new tool! This is the piece that's sometimes the most attractive or exciting but is really the final piece of the puzzle and dependent upon the groundwork looking at the people and the processes which are involved. This is an iterative component and fixating on a single tool or provider too early in an assessment or selection process can have significant drawbacks. Even if there's a strong preference or good experience with a toolset, at a bare minimum you need to look further afield to make sure you aren't choosing without knowing what is out there.

Tool and software vendor assessment is not simple.

Any selection process must consider many factors. Some key ones:

• What the tool will provide (the functionality)
• The value that will be derived (how efficiently the functionality lets people do their work)
• Does it provide a good user experience? (aka - will people love or hate using it?)
• Will it work with other tools in your stack or will it be an island of excellence surrounded by manual work to get data in and out?
• What is the cost of implementation and ownership (the WHOLE picture, not just the license cost) vs the return on investment?

That's all on top of assessing the company providing the tool. Are these people you want to work with? Are they making promises they can't keep? What's the service ticket/support picture like?

At the end of the day, I would say that this is an art and not a science. It's a deal between people and companies.

It's easy to drown in spreadsheets and scoring criteria trying to make sure that you make the 'right' decision. You need to trust the people who will actually use the tools to assess the functionality, value, and user experience and trust your IT teams to evaluate the technology and cyber security aspects. You've also got to trust the Initiative / Product Owner (Business + IT) to assess the companies being considered and picking the best fit for your needs.

Wrap-up

I hope this article provides a bit of a framework that will help you along with your journey addressing your challenges and assessing potential solutions. Don't forget:

• Define the Problem
• People are at the Core
• Don't digitize a bad process
• Tools need to be critically assessed from many angles

Thanks for reading! Let me know in the comments if this was helpful or if you have some further insight to share!