Lisa Venter joined the Synetec team a little over two years ago, after having lead Operations in major corporations on four different continents. She has implemented tools and processes that ensure client budgets and deadlines are met consistently. She is also big on mentoring team members. Her methods earned her a finalist position at the Women in IT awards in 2021.
In every project we do, there’s a Discovery Process. There’s a good reason for that. According to a McKinsey-Oxford report, 70% of software development projects fail: they’re late, over budget or don’t achieve what they intended to. Some even get abandoned with no hope of completion.
I set out to challenge this and make sure that my customers ended up in the successful 30% instead. It wasn’t instant – it came from drawing insight from my background in Operations in other companies. I ended up creating a Discovery Process that allows us to fully understand all requirements. This means we get to really understand exactly what it is that the client needs. We go as far as to scope this out and plot it out in a project format.
The great part about it is the client can then have a look at our discoveries and decide whether they go forward or not with the development. That's really what the big contribution is from the Discovery Process, is that we actually take the time to first understand and then tell you what the definite timeline will be and what your definite investment will be.
A lot of the time when software development consultancies are asked to quote on a job, they'll look at the whole job surface level. They then plot it out and hope for the best. But our process allows us to actually do a deeper dive, do some diagramming, do some planning, speak to all the stakeholders involved. So, by upfront investment in planning, the Discovery Process allows the project to roll out as expected. This means you don’t end up in the 70% of unsuccessful projects.
We scope out the customer requirements like it’s a project, from the very start. We produce a Findings Report and a proposal. The client can then look at this and decide if they want to go forward with the development.
We take the time to understand what’s needed, then we can tell exactly how much and how long. We don’t hope for the best, like others do. We take a deep-dive and make promises we intend to keep.
Our initial engagement with any client is a high level call to understand what the pain points are, what's actually keeping them up at night. Depending on the client's problem, we may have a little dip into their code if there is existing code, just for a quick look at this stage. From there, we decide on how long the discovery process should be. We have various offerings depending on the size of the company that we're doing the solution for, and the complexity of the issue.
The first step of the discovery is really just to make sure that we engage with all stakeholders. To ensure we gain access to what we need, we do a kickoff meeting. During this kickoff, we explain to the customer exactly what the discovery entails. We explain our delivery process in terms of the discovery:
From there, we set up all the meetings across the discovery. After each meeting, we give ourselves a bit of time to document, then we have a feedback loop back to the client each time.
Whoever we engage with, we go back and check: Did we understand properly? Let's have another discussion. All along the way, we are partnering with the client to understand the problem and to really feel their pain.
From there, we draw up a Findings Report and a proposal that outlines what the investment and timeline would be to resolve the issue. We sometimes give one or two options, other times we may propose only one option. The customer then has the ability to either go ahead with the development or not.
Depending on the size of the project, Discovery Process takes maximum 10-20 days total. We spread it out as to when the customer can do it. These won’t be consecutive days but we’ve found it useful to keep these days within a maximum six week timeframe. Six weeks is a good period in which to have the deep dive: have the interviews, as well as come back with a solution.
Well, to be very honest with you, it seems like common sense. If you equate building software to building a house, you go and tell your builder what you want, and he should understand you, right? But the reality is that when you start seeing the building, you're thinking: “Oh, that's not what I meant.”
We try to prevent that and take the uncertainty out. Why this is not being done everywhere, I suspect the usual issues – cost and time. Some companies do a very informal quote, some use expert judgement. We can see from the 70% failure rate that there’s something wrong with how quotes are done.
I took a long time in my career to think about how to resolve this issue. This didn't happen overnight. Once I had formulated something, I found it worked for me in previous companies. So, when I arrived at Synetec, I then rolled it out here, obviously with a difference.
We took a variety of best practice process to come up with a fool proof process. Partnership with client is key. Partnership is one of the four pillars to delivering on time and on budget. The pillars are:
In the beginning, you’re going to need to provide access to the stakeholders from both the business perspective and the technology perspective. Technology is not the key, it’s a business enabler, that’s why we need to talk to all stakeholders. If you only solve the technology problem, you’re not solving the process problem.
At most, you’ll spend 2 hours a week on the project. This sounds intense but our customers have found it’s actually not.
We will also want to see any documentation you can show us. If there is any existing code, it’s useful to have a look at that as well.
We research the business very thoroughly and appoint a Product Owner to run the show on our side. I have oversight of the whole thing, and I tend to go on client calls once a week to keep my finger on the pulse.
The reason why our discovery is great for the client is that they end up with predictable costs, minimise risk, and find a partner who can take the headache away from them.
What clients say about the Discovery Process after it’s done, has always been positive. They’re surprised by how much time we take to understand their problem. They love it. They’ve totally bought into it. They feel relieved at the end. They come to feel they have a safe pair of hands in us before they make a major commitment.
Those who were unsure at the start, have had problems with others in the past. This doesn’t worry us because our approach is different.
We deliver on time and on budget because we gain a deep enough understanding to give a quote we can commit to. The Discovery Process gives both parties transparency and mitigates risk.
Typically, scope creep is one. Secondly, there can be changing resourcing. Thirdly, nasty surprises. A nasty surprise would be a big problem with a system that you haven't uncovered upfront. This means the project is going to take a bit more time, and perhaps you scheduled less time. So, when the issue is uncovered, you realise you didn’t account for this issue.
That nasty surprise could be anything from something breaking in the system to something badly architected that simply isn't taking the load anymore. So again, because we can dig in upfront and have a look at a few areas of the system, we tend to uncover those things prior to actually going into the development. We take the uncertainty out.
Initially, people could be resistant because they're thinking: “What are you going to do different to anybody else?” That’s actually a good point because why would they give us this time? They might want the proposal in four weeks, not six weeks. So, there may be a bit of a change management process – we take the client on a journey to help them understand that the outcome is better for them.
They need to invest the upfront time. I think that's really what prevents them. Most of the time when we've had resistance, it's been because of the time period needed for a Discovery Process. But it actually doesn't lengthen the total project time. This is because the planning, which would happen anyway, is simply split off. Think of it as separating your initial planning from your project. No more work ends up being done than if the planning was integrated into the main project.
The client feels more certain and more comfortable when they’ve been taken through the process. Let’s remember that we are there to make the client look good and take the headache away.
The Discovery Process is one of the ways in which you can see that we’re not a vendor, we’re a partner. There’s a difference. A vendor will use their expert knowledge when drawing up a quote. There’s no deep dive. They then build the software outside, and bring it in and introduce it to you.
A partner will tell you that it’s not in your best interest to have them go away to build something. You know your business better than anyone outside, so walk the journey with them, help them understand, and they will build what you truly need.
Definitely don't go with a vendor option. Engagement needs to be a partnership, especially in software. You need to make sure you understand what’s being delivered. That means you need a partner, not a vendor.
Again, you wouldn't get a builder and tell them: “Just build this house, and I'll be back in six months,” would you? You're invested in your house, so you want to see how it's coming along, possibly make a few changes. That's actually where agile helps you.
Don't be scared of agile, because that's your weapon in order to change direction, or even make small tweaks as you go along. So, I would encourage a COO to look at who they're partnering with, what the delivery methodology is, make sure you understand it properly before you embark on a project together. But also, be prepared to invest the time.
You will know you have the right partner, when you’ve had some interaction with them. Our model lets you dip your toe in to see if we work together well. Whoever you go with, look for evidence of how you work together and if they deliver on their promises.
Finally, don't be afraid of the Discovery Process as a tool to make better decisions.
Our Product Owners are very invested in the customer. We limit the number of customers each PO handles. They go for quality over quantity. Also, our POs are Subject Matter Experts in the industry of the customer. We give them time to learn if they’re not an expert yet when they join us. They are trained to understand the business and can tell you when you’re going wrong.
How the client will see this, is all about the PO asking the right questions. When the PO is a Subject Matter Expert, they’re able to ask the right question. The PO needs to have natural curiosity, and I actually recruit for intentional curiosity. I ask a lot of situational questions to see how the candidate reacts. Intentional curiosity means that a person is passionate and uses their curiosity.
When you have a PO with intentional curiosity, who is also a Subject Matter Expert, the clients really feel the difference.
Speak to one of our advisors. Gain a clear understanding of the next steps you need to take to plot out your bespoke software development project successfully.
If you would like to discuss a bespoke software development project, challenge or goal please book a 30 minute Clarity Call with us and we'll point you in the right direction (even if you chose not to work with us)
.png)
.png)
