Throughout my 30-year career in technology projects and disputes, I have noticed unequivocally common success factors and equally common (and prevalent) factors for failure. IT is often a complex space with a lot of moving parts, and we need a set of tools to get clarity out of the complexity. The tool I most often use is a suite of frameworks pertaining to all aspects of a project or common outsourcing lifecycle. In this article, I look at the two main frameworks I commonly use for benchmarking a situation, as I have found it is within these that the majority of problems and solutions reside.

I like detail, but very often while focusing on those details, we miss the true root causes of the project’s success or failure. These frameworks serve as a vantage point to look at the big picture as well as the detail. From here, we are best positioned to provide advice and help clients reach well-informed decisions. 

The first framework covers the mechanics of a large technology project:

The three big areas here are: 

Technologies and solutions

Sometimes the purpose of the project is not well defined and that is a warning light – if the buyer does not understand the motivations, neither will the supplier. So, we start with “Why are we doing this project? What are the problems we are seeking to solve? How and when can we measure success?” 

That will help us understand the buyer’s requirements, which are the golden thread that ties all essential components of the solution we seek - from design to quality compliance to clarity and outcome. It also gives us an idea of the challenges to overcome. It is a good basis for engaging with the market to assess feasibility and costs, as well as learn whether the requirements and outcomes can be improved upon. 

This then permits the market to consider the requirements and present possible solutions to the problem, as well as the technologies to be used. The important factor here is that the requirements and outcomes are mutually understood, aligned, and agreed upon – first by the buyer’s internal team, then with the provider and then by the contract. 

Delivery and governance

Every project has a Before, During, and After. I have learnt to keep it that simple. There are so many project methodologies out there like Waterfall or Agile or Hybrid, and multiple variants within those. Finding a preferred approach for all stakeholders well in advance is of utmost importance. Finding it too late, for example, if the buyer wants Waterfall and the supplier only does Agile; or switching from Waterfall to Agile mid-project, will usually be fatal to the project.  

By applying the lenses of Before, During and After it helps everyone to arrive at a clear project narrative, which articulates, in a common language, all aspects of the delivery and relationship lifecycle. This understanding then helps shape the best commercial and contractual model to incentivise all parties to a common goal.  

Contracts - legal and commercial

Unfortunately, “the contract in the drawer” is a common practice in project management, driven by the assumption that contracts are ‘drafted by lawyers for lawyers, and are only to be used in the event of a dispute’. That is quite ironic because, in my experience, lawyers, being very diligent in managing risk, take great care in presenting a contract with all the levers, checks and balances needed to help drive an effective delivery and performance.

The framework illustrates the importance of the contract and its relevance to the back-end schedules. It identifies gaps in clarity and certainty and provides a sanity check on whether all aspects of the commercial, delivery and technical schedules are well-articulated, sit seamlessly with the front-end terms and conditions and, collectively, assure the desired outcomes.

It also shows how pivotal the contract is in managing innovation, lifecycle, relationships and, last but not least, change. Requirements change, technologies change, and as Covid has shown, entire environments change so the contract needs to be flexible enough to enable that. The framework helps get a quick handle on the impact of change across the entire landscape, not just the technical effect. 

Flexible contracts are easier said than done as we all know but essential if we want to enable delivery. “The contract says no” is the common denominator of most business relationship failures.  

Orbiting the framework are People, Enablement, and Empowerment, which I explore in more detail in the second framework, which is more to do with people and behaviours.

People and communications

Over the years, I have found that unless a project is stone-dead and in formal dispute, people are a fundamental factor for the success or failure, as the faults often lie with them and not the technology. The stakeholder framework above gives an overview of all relationships in three major bubbles:

Executive teams

For bigger projects, having the executives on board and supportive is essential. Again, some simple key success factors: are they aligned strategically? Does the deal make sense in the long term? Are they fully behind it?  Will they be good sponsors for the team? The executives need to be aligned not only in terms of concept and budget, but also in team enablement, setting out clear expectations for delegation of authority, decision making and trust in the delivery teams. Swift decision making is essential to a successful project. 

Delivery teams

We need teams to be skilled, motivated and encouraged. We also need them to feel comfortable in making decisions and owning their mistakes early so they can be fixed in time. Very often personal mistakes are swept under the carpet, manifesting in ‘watermelon reporting’ (green on the outside, red on the inside) and major project fault lines later. 

To illustrate the above, here is a comparison between two projects, each having a thousand decision points: 

Project A has a lot of governance and big delivery teams. Each decision is made by a team of 22 people at an average of four hours per decision. 50% of those decisions get overturned within a week.

Project B has a smaller team of six people empowered to make swift decisions up to a certain level, with a switched-on, engaged sponsor.  Each decision takes on average of one hour and none is reversed. 

Project A - 88,000 hours (1000 decisions*22 people *4 hours) are spent in decision making, and as 50% of the decisions are continually reversed, that number of hours increases ad infinitum. That project clearly will never get delivered. 

Project B - 6,000 hours are spent on decision making. Some of these decisions will be wrong, but if the culture is to acknowledge it, learn from it, and fix fast, the project will get delivered. 

The business

Many projects fail because people do not like change and some businesses reject even the best technological solutions because of that. Simple questions we should ask here would be:

Is the wider business aware of what is being embarked on? Are they being engaged in the right way? Are they trained? How can we help them to transition and transform to new ways of working? Those questions pertain equally to all those who will be touched by the project, be it clients, customers, existing providers, or partners.

Orbiting here are again the Outcomes (always something to keep an eye on); Good Sponsor (an engaged, enthused, and supportive one can be rare to find but is worth their weight in gold); Good Teams (collaboration and emotional intelligence alongside technical skills, attitude, and motivation) and Good Place (facilitating successful outcomes and shielding the process from the toxicity of previously failed projects). 

This is just an outline of the two main frameworks. Others include ‘Sourcing’ and ‘Tech-enabled Transformational Change’, which I will cover in a future article. 

How and when do these frameworks help?

Very often as expert witnesses in disputes, or as independent expert advisors pre-litigation, we concentrate on the schedules. If the contract terms are good but the implementation is not in accordance with what was promised in the schedules, we then use the frameworks to ask all the right questions in terms of fact, technology, contracts and delivery. To win the dispute  pre-litigation, we need to understand all those aspects to find the best strategic approach for the best possible outcome, or to determine quickly whether you have a good case. 

If a failing project has not gone to dispute, and you are seeking to turn it around, the framework can help identify the root causes quickly. It has been designed to uncover all of the causal factors systematically, including inter-connecting factors, which can often otherwise remain hidden. Once the true landscape is known it is much easier to be confident that your strategy for turnaround or dispute resolution is robust.

If you are about to start a project and commit to a big investment, the frameworks help you architect and design all the essential components you need for a successful and timely completion. In a world where so many major projects and programmes still hit snags or fail completely, I have found that these frameworks consistently reverse this trend.

Richard Kerr is a director at IT Group, a Kroll business, whose distinguished career spans three decades with a particular specialism in IT software projects, outsourcing and technology–enabled business change.