Frameworks For Optimal Outcomes and how they can help resolve IT disputes

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:

Posted in Miscellaneous