It could be an existing product that keeps missing delivery dates, a system that takes too much effort to use, or a proposal to replace something that nobody's particularly happy with. The detail will be different in each business. My first question would be what you're hoping will improve, and why you think this particular change will help.
Start by speaking to the people involved
I'd start with the leadership team to understand what they want to achieve and where they think things are getting stuck. Then I'd want to speak with the other people involved, ideally individually. Depending on what we're looking at, that might include product managers, developers, customer service and people elsewhere in the business who use or depend on the system.
You can learn a lot from those conversations. The leadership team might have a clear idea of where the business is going, but I'd want to know how that reaches the people deciding what gets worked on. Do they understand the priorities in the same way? Are they being asked to do something different by somebody else? Is there a reason for a delay that hasn't reached the people making the decisions?
People need room to explain what they think is going on. I'd report themes without attributing comments wherever possible, although in a small team you can't always guarantee that somebody won't recognise where a point came from.
Look at what happens in practice
Alongside those conversations, I'd want to see the work. What are customers actually using? What are they paying for, and what are they saying about it? How does that feedback reach the people managing and developing the product?
I'd look at the plans, processes, ticket boards and testing arrangements where they're relevant to the question we've agreed to investigate. If we're concerned about costs, we'd need to understand what's being paid for and why. If the product handles sensitive data, I'd also want to understand how that data is managed and who can access it.
Some of this may show that things are working well. Some of it may show a difference between what the business thinks is happening and what the team is actually able to deliver. If something doesn't make sense, I'd go back and check it with the people involved before drawing a conclusion.
Be prepared to question the plan
There may be a perfectly reasonable case for a new system or more people. But I'd want us to be able to explain that case, rather than keep doing the same thing and hope that spending more will give us a different result.
I've worked with a business where we had to simplify what was being developed substantially to get a useful service into customers' hands. The longer-term ambition was still there, but we needed to agree what could deliver value first and what could wait. I've written about that in the refocusing delivery case study.
In another business, the answer might be different. We might need clearer priorities, a different mix of skills, better testing or a decision about something that's been left unresolved. That's why I'd want to understand the situation before recommending the solution.
Leave with something you can act on
I'd bring the findings back to the leadership team: what's working, where things don't fit together and what I'd suggest doing about it. That would include improvements that could be made fairly easily, alongside the things that need more thought or a longer-term plan.
You should be able to take those recommendations forward with your own people. Where it would help, I can also lead the next stage, but that would be a separate discussion.
If this sounds familiar, my technology, product and delivery review is a way to look into it. We'd agree the question, scope and fee before starting, around what your business needs to understand or decide.