Episode transcript The transcript is generated automatically by Podscribe, Sonix, Otter and other electronic transcription services.
Hello, everyone, welcome to the five Minutes podcast, today I like to discuss with you, which kind of consideration should we put in place to select our development approach.
First, as I said to you many times, there is no perfect development approach, and it's not that okay, agile will solve everything or a waterfall or predictive will solve everything. It's not bringing that will solve everything. It's not Scrum that will solve everything. We need to understand, which is the most suitable approach for our problems and the PMI, a deed in the PMBOK 7th Edition, a whole performance domain, one of the eight performance domains it's called development approach in life cycle end in this chapter have the PMBOK.
There is a, a set that I really enjoy reading, it’s talking about which kind of considerations you should have in your mind while selecting your development approach. And I want to cover today pretty much the product service or result group. So when we need to select or when we need to decide which we'll be our approach, the first thing we need to understand it, which kind of degree of innovation are we talking about?
For example, if you know exactly what kind of innovation you are planning to deliver, if you know the scope well it's well understood. Do you know exactly what I would say, the perfect end state is for you? You should use the predictive approach, you should plan before execute, control like I would say a more traditional way. However, if you are doing a project that is pretty much research, you are doing innovation, you don't know exactly what will come out of your innovation. Maybe it can be something very disruptive, something that you don't know completely how it will look like if this is your case, and this is becoming a very frequent well, the adaptive approach will suit far better, because how you will blend requirements. If you don't even know what the end state will be will look like.
The second one is very closely related to what I just said, Is this the certainty of the requirements, for example, you know exactly which are kind of requirements you need, it's easy to define, use predictive approach, but then, when it's uncertain when it's a volatile complex when you are facing what I always say, a VUCA environment, and these also are becoming a very common today. It's far better that you use an adaptive approach that you create MVP is that you create a small prototype and start building on top of that. However, if you are a building, I would say an airport, maybe this approach will be a little bit more challenging because you have so many requirements that are very clear, if you want to put things, place a legal airport. Okay?
The other thing is this stability of scope and the stability of scope is very related to the easiness of change. So how stable is the scope? If the scope, is stable, I would say more predictable. If you are doing, for example, an oil platform or you are doing, a refinery or a very large mining operation, there is stability on the scope. These projects are long-term, these projects are very complex, but at the same time, there are very stable products because they are very the technology, of course, there is a degree of innovation, but the technology is there. So there is some stability. So it's worth it for you to invest in the planning, to prepare it a little bit more, and use the predictive.
II the order site, if you are you using, for example, a high technology product or an e-commerce service, our website for e-commerce or a social network, or a mobile phone app or something like that. And that then things change in such a dramatic case that an adaptive approach would be far better, because most of the time, just for you to plan, remember one thing, just to give you one insight on scope stability, you develop an oil platform, this is an area that I would say I worked a lot. You'll develop an oil platform. The oil platform operates for 30, 20, 40 years. If you develop software, the software needs to be updated pretty much the day you delivered it.
So it's very different. There is no software that will last, okay as far as I know that that will last for 30 years, 40 years. So it's different, the airport do you are using today is doing renovations, but probably the place you put the
runaway of your airport. It's there since the airport was conceivable, probably 30 years, 40 years ago. So this is what I'm talking about scope stability.
Easiness of change, if you feel that you need to change the best approach for you to embrace and adapt change is that adaptive, the predictive is far more suitable when you need to have some investment, because the cost of change is very high, another example, let's go back to the airport and let's suppose we are talking about a runaway let's suppose you just built a runaway and you notice that the runway that should be tilted 35 degrees north for 35 degrees west. Imagine how much does it cost this change. This cost Should be, I would guess probably as big or even bigger than the cost of the runaway, the initial cost of the runaway.
On the other side, if you are building software and a new feature appears or something that you can just change like that, that the lightning speed, right? So for example, you can change from your approach to another approach very fast. So when it's easy to change and technology, for example, mobile and maybe a business and maybe some marketing, then, it's very suitable that you use an adaptive approach because there is no point
for you to make a full plan because what you want is flexibility.
And the other one is your delivery option. Many times you cannot deliver and make a useful MVP that will help and benefit the society so fast, for example, you cannot say, okay, let’s build a cardboard bridge, and then let’s test to see people will use it or not., and then if people start using, then we will replace by wood, then we will put concrete. If it doesn't work that way. So most of the time you need to do all this is studies before because when you start building the bridge, it must be as close as you can to the final state. In the software, you can do that, in releasing a new product or releasing a new marketing campaign or releasing a new service for your credit card product. Then you can create things and you can pretty much deliver in an incremental and pretty much a continuous way. Did you see the software? I always remember 10, 15 years ago, we visit the new website of X, Y, and z.com or visit the new website. There doesn’t make sense today, because the website is a permanent afford. It's not just a one-time shock. It's something that you are improving, renewing and updating, and creating new deliverables every single day, every single day. So for example, if you compare a social media website today and a social media website, one year ago, it's completely different, but they don't even tell that this is just part of the business. So it's a continuous flow of delivery. This is why in this case adaptive is an excellent, perfect approach for that.
Now going back to the final topics are risk, safety, and regulation. When I talk about the risk, I'm not talking that high-risk should use the X approach or low risk should use the Y approach, no I’m telling you that in some projects, we reduce the risks by strong planning. For example, when his takes are very high on the execution, when the investment is so high, when the risks are very high, many times you need to build full and complete detailed specifications. For example, the weber telescoped that will be released soon or a nuclear power plant, you cannot say, okay, let's try to figure out if this is the protection of the nuclear reactor we work for or not. This is not on the table to be discussed. Others are exactly the opposite. The high level of the tale increases the risk and does not reduce. For example, again, in software or in a new product release, it’s better for you to reduce the risk, to release the droplets. You release something to release something, to improve something that you release something. So depending on the risk you are facing, one approach will increase in another approach will reduce the risks.
Safety and regulation, many times increase in the need for safety and increase that regulation will not force you, but will move you towards a more predictive approach. For example, when there is a lot of legal requirements and when there is a lot of safety requirements, it's very hard for you to release a minimal viable product in these cases because this takes are so high, that if you fail, you may fail fast, but you fail in an incredibly expensive way.
So nuclear power plants, banking systems. For example, if you're doing online banking or this kind of do one of the biggest challenges you have, it's not just the customer experience, but the safety and regulation, there is a lot of entities agencies regulating you. So for example, if you see that COVID vaccines, used several aspects too, it was the perfect example of a hybrid approach, and why it’s not just an agile approach? Because of regulations, they did some fast-tracking, but they still require a massive amount of study. It's not something like, oh let's testing two people, okay, now it's a good let's testing five. No, it’s good, let's testing ten, no your is initial shot is quite high. So you need to test okay, 40,000 people, a hundred thousand people. So it's big at stake, so you need to plan properly.
So what I meant here is to give you this perception, you can have other criteria, but this criteria is inside of the PMBOK are very useful for you. And don't get into the trap that there is a one-size-fits-all because this is not true and this will not happen. Okay?
So thank you very much. And to the next week with another five Minutes Podcast.
