Keys to Stewarding the Client Investment & Maximizing ROI

Getting to the heart of a client’s concern is the crucial first step to delivering an effective software solution. But deciphering complex requirements and balancing competencies between a client and a technology partner can be a daunting task. This is where discovery comes into play.

In our series’ first post, Discovery: Understanding the Problem Space, we learned that discovery begins before kickoff with a client-focused “needs analysis session.”

In this blog, we’ll explore how discovery activities help teams gain powerful insights, establish trust, and deliver impactful solutions as they work to steward the client investment.

Matching Project Scope with Domain & Technical Competence

Finding the right fit can be elusive, but it’s often the difference between projects that spark long-lasting relationships and the ones that stumble to the finish line.

Smaller projects may require only a single resource – maybe a project manager or tech lead – to churn through a backlog of software enhancements that engineers then code and deploy. Larger ones call for UX, Dev, and QA resources to build a pre-assigned roadmap of features on a regular cadence.

True product teams, as Marty Cagan explained, face a more complex task. They’re not handed a task list and a timeline for completion, he says. Their job is to identify a problem (and its source) and then go out and find an efficient solution for it.

Clients want their technology partner as invested in delivering a successful outcome as they are – that they’re sharing the risk burden with them, like we have ‘skin in the game’ too. It means we’re personally committed to the project’s success and share accountability for its results.

Discovery’s Role in Finding the Right Fit

At the start of each project, ITX innovation leads ask client stakeholders a lot of questions to get a sense of the size and scope of problem. And, because the product team is often a joint team with the client, it’s also important to understand the roles and responsibilities each team member will play.

We use the Pre-kickoff image below to represent the client’s and ITX’s domains of responsibility, starting with a couple key assumptions: business-specific expertise lands in the Client domain. Product development expertise rests with ITX.

Once the project kicks off and the two domains interact, collaboration begins and the product team finds the right blend and balance of each other’s strengths. And the line bends and bows as responsibilities are assigned (Graphic 2). Team member interaction flexes throughout the project as progress is made and resource availability changes.

Using Discovery to Find the Right Fit – 4 Examples

Anyone who’s done software product development knows that no two projects are alike. Much as we try to streamline the process, there’s no ‘one size fits all’ solution. All sorts of issues bubble up and need to be addressed.

That’s why shifting discovery activities earlier in the project is crucial to its success. It’s also why innovation leads continue with discovery throughout.

In an earlier post in this series, How To Convert Client Needs To Establish Clear Product Vision, we described risk as “the unavoidable reality of software product development.”

Done well, innovation leads help their teams avoid or mitigate that risk. Done poorly, we’ve learned the hard way, and projects can go sideways in a hurry. Here’s a few real-life examples –

1. Unallocated Resource. Occurs when a need goes unfilled, creating a resource gap.
   Example: Client A assigns a deep bench of backend developers to the project, but no one with frontend dev or UI experience.
   Adverse Impact. Lack of adequate coverage.
   Remedy. Early-stage conversations with client-side stakeholders help innovation leads understand the expertise and availability of their team members.
2. Skill Set Overlap. Occurs when both ITX and the client allocate a team member to perform the same role.
   Example: Eager to please the client, ITX deploys a highly skilled innovation lead to the team. At the same time, Client B allocates a similarly talented product manager.
   Adverse Impact. Overlap of highly talented team members, which can lead to:
   • Confusion. Client B’s PM and ITX’s innovation lead both trying to perform the PM role, leaving team members uncertain as to the team’s leadership.
   • Conflict. Client B’s PM and ITX’s innovation lead may differ on strategy and roadmap, creating tension on the team.
   • Cost. Both the client and ITX face increased opportunity cost; each should consider redeploying their team member, deferring to the client’s preference.
   Remedy. Discovery can help to define clear roles and responsibilities within team leadership and technical roles – e.g., architecture, design, engineering, QA, etc.
3. Insufficient Allocation: Occurs when the project scope expands beyond the original estimate, and there’s more work than the product team can manage.
   Example: Client C expands the project’s scope to account for a shift in the market environment. The client soon discovers the initial assignment is insufficient.
   Adverse Impact. Situations like this one are often unavoidable, but here’s an example of why iterative discovery is so valuable.
   Remedy. When teams foster and sustain open lines of communication, options arise to address unpredictable events. In this case, the client’s options include: reducing project scope to its pre-kickoff level; providing training to deepen the team’s skill set; deploying additional internal resources; or requesting support from ITX.
4. Resource Mismatch. Occurs when a product team overstates a team member’s technical competence.
   Example: Client D doesn’t completely understand the project’s complexity scope and assigns a team member it believes can succeed in the role – but soon realizes they’re in over the head as the project falls behind schedule.
   Adverse Impact. Skill set misaligned to project scope.
   Remedy. Discovery helps product teams establish constructive “ways of working” and frameworks for decision-making (like RACI). It also creates opportunities for innovation leads to guide and support their team members.

Collaborative Excellence: 5 Steps to Eliminate Risk and Deliver Project Success

Building software is a team sport. Stewarding the client investment occurs naturally when innovation leads position their teams to succeed.

Early-stage (and iterative) discovery arms product teams with crucial information about client needs, matching team member deployments to align with those needs.

Here’s 5 key tactics used by ITX innovation leads to identify risks before they adversely impact your project’s success:

1. Understand the expertise and availability of all team members.
2. Define clear roles and responsibilities within technical disciplines – e.g., architecture, design, engineering, QA, etc.
3. Foster and sustain open communication among all product team members.
4. Establish a “ways of working” framework for decision making, e.g., the RACI matrix.
5. Be present, eager to guide and support your team members.

---

Need help with your next software project? ITX can help. Let’s talk.

---