Part 3: Oversight
In this podcast episode, Bhairav Patel takes listeners on a journey through the crucial role that oversight plays in the success or failure of projects. Through engaging anecdotes and thought-provoking questions, he highlights the all-too-common scenarios where lack of oversight leads to costly mistakes and missed opportunities. Drawing parallels between project management and everyday decision-making, he challenges the audience to consider why thorough due diligence is just as essential in the realm of software development as it is in other aspects of life.
As the episode unfolds, Bhairav weaves together stories of clients who were blindsided by trusting recommendations without proper background checks, vividly illustrating the importance of thorough oversight in project execution. From cautionary tales of overlooking warning signs to empowering examples of how a little oversight could have made all the difference
A full transcript of the podcast can be found here:
Bhairav Patel:
[00:00:00 – 00:00:45]
Welcome, everybody, to episode three of why do projects fail? So, for those of you who are subscribers and who would listen to the first two in the first couple of episodes, I kind of set out our reasons, or atom CTO reasons for why we think that projects fail. And I came up with the funky acronym of CPOP, the C standing for Communication. And in that, for those who had listened, you’ll have heard me talk about a number of different areas where you have inconsistent communication on a project, people hiding bad news, people not communicating in the same language. So people using acronyms and really not telling the software development house exactly what it is that they’re trying to do from a holistic business point of view, and software development houses not really communicating very well with their clients.
Bhairav Patel:
[00:00:46 – 00:01:21]
In episode two, I talked about people, and really, I do believe that people are mostly the problem. You can hear in that episode how I talk about egos and how egos can drive wrong decisions on projects and essentially drive them to failure. I also talk about the one to ten rule, which actually someone realized and pointed out to me is actually the three to ten rule, which again, is a good podcast that I’ve done previously with Azibamir. And I thoroughly recommend that in this podcast, I’m going to go into the next letter of the acronym, which is o for oversight. So what do I mean by oversight?
Bhairav Patel:
[00:01:21 – 00:01:38]
Well, ask yourself a bunch of questions. Would you let kids mark their own homework? Would you buy a house without doing a survey? Do you check out reviews online before you buy something? And would you keep buying from someone if they never delivered your goods?
Bhairav Patel:
[00:01:39 – 00:02:15]
So, as I’m sure you can understand, what I’m trying to get out here is due diligence and oversight. Right? So let me tell you a few stories that we’ve come across over the years, which are really quite shocking, but also ones where you can understand that even a little bit of oversight, the clients would have actually figured out something was going on. Now, there was one client that came to us a number of years ago that had a situation where they were looking to raise money and they had some funding earmarked. However, they needed to deliver a product, and they needed to deliver it in nine months.
Bhairav Patel:
[00:02:15 – 00:02:37]
And once they had delivered that MVP, they would have unlocked an additional set of funding. And the initial set of funding that they had, had them having just enough money to create that MVP. So they went off, signed a contract with a company, and merrily went on their way. So the company said to them, yes, we’ll deliver the first thing in three months. We’ll deliver the first iteration of the product in three months.
Bhairav Patel:
[00:02:37 – 00:02:59]
And so they stepped back, came back three months later, and the software development house said, well, no, sorry, we don’t have it ready. It’ll be the next month. They came back the next month and sure enough, nothing was delivered. And this kept going on for six months. And by the time they had basically figured out six months later that the company who had taken their initial deposit didn’t actually have a team available.
Bhairav Patel:
[00:02:59 – 00:03:33]
And this was back in the days a few years back where there was a lot of demand for software developers. And that particular software development house had essentially said yes to a project without having a dedicated team. After about two, three months, what they had done is taking other people from other teams. And so those people were working on two or three projects at the same time to try and deliver something to show to the client so that they could at least tell them the story that something was happening. And it turns out after six months that really they had nothing in their hands, but they already paid a lot of money.
Bhairav Patel:
[00:03:33 – 00:04:17]
So they came to us asking us if we could help them in the next three months deliver something to a third of the budget. Now, of course, that is a situation where we stepped back and just asked, did you not speak to the developers? Did you not have conversations with the teams that you were working with? And they said no. And really what the point of this story is is that if you’re going to go into business with someone and you’re going to hire a team of people to deliver software, you need to meet the team and you need to talk to the team leads, or you need to talk to the architect or whoever it is, because again, you wouldn’t go and build a house and not meet the contractors or the architect who is actually designing the house.
Bhairav Patel:
[00:04:18 – 00:04:37]
These are things that you wouldn’t do. So why do that in software development? And again, for software development houses, this is, again, where communication comes in. You could easily have solved the problem for the client by being honest and open, but that’s a different story altogether. The other aspect of oversight is around delivery and quality of delivery of the product.
Bhairav Patel:
[00:04:37 – 00:04:59]
And here I go back to the first question is, would you let kids mark their own homework? Now, clients do come to us who are a little bit suspicious of whether what has been delivered to them is any good. Now, what I say to them there is that it’s great that you come and actually had a conversation with us about this. We can definitely help. But really, this is something that should have been built in at the very beginning of your engagement.
Bhairav Patel:
[00:05:00 – 00:05:43]
I know a number of different companies are very, let’s say, protective of their own work, and they don’t like others coming in. But you as a client, you as a person paying the money, should be able to say to your software development house that, yes, we’ll pay you on delivery, but we will be doing some reviews. We’ll have an external party reviewing the work that is going to be delivered. Because if you’re paying significant sums of money, which I’m sure most of you will be, when you’re looking to implement a software project, you should not be scared of saying to that software development house that you will bring in someone to validate the work that has been done. And I don’t think that’s unreasonable for a software development house to open up their code to a third party to allow them to see what’s going on.
Bhairav Patel:
[00:05:43 – 00:06:25]
And we’ve been in many situations where there have been software development houses that haven’t actually wanted us to look at the code. And there’s a reason for that. Usually it’s code that is sloppy or written by junior developers, or they may just not have done a lot of what they said they had done, and it could be smoke and mirrors that are there. One of the other things that we say to clients very early on when they’re negotiating contracts, is that you should have step in rights. Now, these are something that we’ve discussed on other podcasts, actually, with Rustam Roy, on outsourcing contracts, and this is quite an important one, where you as a business can request step in rights for your project, where your software development partner can’t deliver a piece of work.
Bhairav Patel:
[00:06:25 – 00:07:46]
So it may well be that someone has taken on a piece of work that they’re not qualified for, they can’t do for whatever reason. Maybe they don’t have the resources or they don’t have the expertise in house, you should be able to request the ability to step in, or have a third party step in and fix the problems that occur at either a cost to the company that is developing the software who can’t deliver it, or at a discount of the money that you would have paid to that company in the first place. So my last point on oversight is just basic reference checking. What I find quite astonishing is that a lot of people come to us who have paid lots of money to someone because their friend recommended them, or they know someone who knows someone, and they’ll have spent 2030, 40,000 pounds with a group of people that they really don’t know anything about other than their friend has recommended them or their brother recommended it, or even worse, that they’ve brought family members in to develop something, and then they’re not able to actually remove that family member from the project because, of course, they’re family members. So one of the things you do, and obviously a way to neutralize any kind of emotions or personal connections there is to do that due diligence, as you would do with anything else you buy, anything else that you would purchase for that significant amount of money, you would either bring in an expert or someone to kind of help you do that due diligence, or you would do it yourself.
Bhairav Patel:
[00:07:46 – 00:08:11]
You would do some background checks on them or at least find out from their clients how they work. So that’s oversight in a nutshell. I hope you’ll stay tuned for the next letter of the acronym, which is P for Planning. And in that, I’ll talk about how we don’t plan for change, how we try to do too much too quickly, and really how poor planning really can bring down a good project.