Partnerships support business agility

In the digital and AI world, where everything is moving fast, if we are slow in delivering values, we will lose the competition and, thereby, business. Traditional ways of contracting in the IT-enabled solutions domain will not be optimal, as in most cases, they will not work if we have a transformational backlog (list of perceived values).

Situation of dilemma

To meet the continuously changing market demand, customers want to deliver solutions (perceived values) faster to the end business users, so they should be on top of the competition in a continuously market VUCA world (Volatile, uncertain, complex and ambiguous). Many companies fear going for an agile contract because they are comfortable with the traditional way of contracting.  Companies still find themselves comfortable having contracts with their partners to fix scope, time, and budget, knowing that they are in a VUCA world and that scope (perceived value) can keep changing based on recent market demand and technical architectural findings.

Working in this way prevents the partner and development team from delivering real value, which is needed. It also constrains the team’s ability to adapt to changing market demand and discoveries from a technical standpoint. It also adds difficulty managing recently discovered risks that were unknown at the beginning.

Suppose one requirement (perceived business value), which we anticipated as small and simple at the beginning, and now we discovered it to be large and complex, which needs more capacity and time. In that case, our focus shifts towards contractual terms due to the rigid contract (Fixed scope, cost and time). We start negotiating contractual terms rather than focusing on giving real value to the customer waiting at the other end of the value stream. The cost of delay is always expensive.

The traditional way of contracting is good if the buyer and supplier understand very well what to build and how to build it; examples are building bridges, houses, etc. It is hard to define a solution up-front in the IT solutions world where both the demand and market are continuously changing. IT-enabled solutions are always R&D; there are so many unknowns associated with it. On top of that, the ever-changing market demands need continuous adjustment of the scope (perceived value) to meet the market demand and enable business users to capitalise on opportunities.

Common pitfall

To bring some agility to delivery, a very common mistake that customers and partners make is that they formulate the contract traditionally and adopt Scrum or other agile frameworks at the execution level. This is hilarious as it does not solve the problem; in fact, it adds more stress to the development team and partners who are responsible for delivering perceived values at the end. They are sandwiched between two altogether different principles. Traditional contracts tie the hands of the development team and the partner even though they are following an agile framework at the execution level. This constrains them from being innovative.

I understand that customers need some predictiveness before starting an investment into engagement. But the question is how to make a good balance between predictiveness and agility in value delivery?

The partnership which supports business agility: lean-agile mindset

To give some predictiveness and agility in value delivery, the best way is to have a pre-study workshop where both the customer and partner do the initial scope analysis and the problem statement. This needs critical thinking. The partner does the feasibility study from technical & industry best solution perspectives. Formulates conceptual design based on program objective and initial scope (list of perceived values) identified by the customer. Design Thinking approach can be leveraged for this.

To make it fair for the partner and customer, the pre-study should be a small level of investment not lasting more than 2-4 weeks, depending on how big the program/project initial backlog is. It is a kind of “testing the water” before starting the journey.

The outcome of this exercise is preliminary estimates with some assumption of how much time, skills, and capacity are needed to deliver some key values (MVP) in a shorter time horizon, 3-6 months time, max 6 months; one or two program intervals (PIs) max is 2 PIs. So that the customer can evaluate solution outcomes and based on the findings the customer can pivot or persevere it; both initiative and partnership.

It gives customers more control on funding the initiative. It also allows the partner and development team to showcase solutions and their skills. The outcome of pre-study workshops enables buyers with stronger business cases with data points which can be used for funding implementation projects.

Secure capacity and skills, fix the budget and time, leaving scope (perceived values) to be flexible. Because we do not know what will be the most important thing after some time, this gives customers more control over the scope (perceived values) and business outcome. This makes sense because this is ultimately the customer’s initiative, so they should have more control over scope and funds. It also enables partners to suggest new ideas and be more innovative, which ultimately benefits customers. They do not have to worry about terms and conditions written down in a contract.

Contract for long-term partnership – lean & agile in nature

While formulating an agile contract between customer and partner, there should be clear roles and responsibilities delineated. What is expected from the customer and what is expected from the partner.

And what they should be doing as ONE team to achieve a shared goal which is a project goal.

In a contract that basically marries the customer and partner, there should be three roles and responsibilities defined. The customer’s responsibilities, partner’s responsibilities and shared responsibilities. These are the three pillars of engagement. Trust, collaboration, and open communication is the foundation.

Customer’s Responsibilities

The customer is responsible for the program level, strategic themes, features, and any non-functional requirements with perceived business values. They have full control of the scope (perceived values).

Partner’s Responsibilities

The partner is responsible for defining a preliminary scope, technical feasibility, and how much time and capacity is needed for it. Securing the required skills and providing stable, agile teams The number of teams varies depending on the number of value streams identified during the pre-study workshop.

Shared responsibilities

And the third pillar is shared responsibilities. Together, the customer and partner can keep refining the program backlog, prioritising scope based on perceived business value in a given time frame from an economic context. Continuously inspecting and adapting the empirical process. Because needs change as per market demand, whatever we have prioritised at the very beginning may not be relevant now. The program backlog needs re-prioritisation as we go and as we discover more. Prioritisation should be a shared exercise that brings both business context and technical context.

Success Criteria – Pivot or Persevere

Last but not the least, measure the success based on the solution outcome which is basically real business value from business context rather than number of user stories delivered or number of requirements delivered, which is typical in traditional contracts.

Trust plays an important role in agile contracting; in fact, trust plays an important role in every kind of relationship. Transparency, collaboration, and open communication are key to building blocks of trust. And by ensuring you have that in place, you are up for success with your project.

If you’re looking to navigate your next transformation journey with agility, trust, and a shared vision, we’d love to hear from you.  Reach out to us to explore how we can partner for success.