One of the things that you need to keep in mind is that trouble projects may also arise from the wrong delivery approach. If we go back and try to go back to the basics of project management, you have some approaches that are incremental. And some approaches that are iterative.
In common terms, I. Everybody knows that I don't like these terms, But this is more waterfall. Or traditional.
This is why I don't don't like the word because traditional may sound like old and it's not. And this one is more towards Agile. Okay?
Just for us to have this, what's the root of the incremental? Incremental means you have a clear view and a clear scope of what you want to do. Then you plan, then you execute, then you control, right?
Then, you control while executing. On the other hand. What do you do?
You have an idea. You develop that idea, you produce a minimum viable product. You test, you design, and say: "Oops, it's working, not working".
If it's not working, you throw away and you develop it in a different way and you interact with your client, your customer, your user, and then you move on. This is excellent. Let me repeat.
Excellent. When you have a defined product. This is excellent when you have a clear goal.
This is excellent when you have a contract. That has very clear specifications on what you should deliver. Let me give you an example.
You are building an airport. You are building an oil refinery. On the other side here, it's when you have an idea and you want to test this idea.
When you have a clear goal in strategic terms, but you are open to change. To change. And here you are far more flexible.
If you mix this, there is a good chance you will be in trouble. Let me give you a couple of examples. Let's suppose you want to use a full Agile approach to build, for example, a new airport, but you want only to use Agile teams and everything.
I'm not saying again, let me go one step back. A project like an airport is such a big project that of course you will have pockets of everything there. But let's talk about the core of the project, the core of the project.
Then you decide to do it in agile. Let's suppose you decide to do the runway using Agile. What do you do?
You just, you know, cut the trees, make quick landscaping and you say: "Now planes just start landing and taking off, let's see if it works". If we need to make it a little bit wider or a little bit shorter, "Let's stay, oh, God, that plane crashed! No, we can do that, we need to increase".
This doesn't work. Do you agree with me? There are a lot of contracts.
There are a lot of regulations. That just does not allow you to do that. You just cannot do that.
You need to have very clear specifications before you cut the, I would say, the first tree or before you do the first meter of landscaping. There are a lot of documents. There are a lot of approvals that you need to have in place to build a new airport.
So this deliver approach will bring you more control over your process. If you use this, there is a big chance that you'll be in trouble. Now let's flip to the other side.
Let's suppose you are developing a very innovative product and a product that you don't know. You want to serve people with that specific need, For example, you are creating a niche of a social network, for example, vegetarians, and you are building a social network of vegetarians will share their recipes, they will share their lifestyle, and you want to create a community for those who are mainly vegetarian, just as an example. If you do that, "I want to my objective is clearly to have all the vegetarians.
My objective is to define what a vegetarian is". It will be very tough because you bring rigid control into something that is much more exploratory. You need what to do?
You need to test. You need to talk to vegetarians. Because maybe someone can come and say, look, I am a plant based.
Will I benefit from vegetarian or not? I am a vegan will I benefit or not? So there are several questions.
What the social network will bring to me. What is the value of that for me? So what do you need to do?
You need to test. You need to evaluate. You need to test and see, will people join this?
This will work or not? It's much more exploratory. If you come and make a contract and make this rigid, what will happen?
You will fail. And this is why, for example, many innovation projects fail. The many innovation projects, because incumbent companies incumbent old more traditional.
They are, I would say, they have this mindset of everything very clear, and deadlines very sharp. But they don't know exactly what will happen when they open the box. And this is a different approach.
And then you may ask me. "Which is the best"? There is no best.
Which is the best? That you use the right approach for your problem. Many times IT projects fail miserably because most of the IT projects involve a lot of, I would say, exploration, things that we don't know.
And we should move towards a much more iterative process than the traditional ones. When we use this, we just, you know, it's like handcuffing everybody. They don't have the flexibility and then innovation without flexibility, you go nowhere.
This is why it's important for you to understand, how your approach, will remove the project from trouble or will really help to sink your project, and your project becomes a failed project.
