We talked about a certain approach and development in the previous article.
That’s when we try to understand the expectation of the customer or the business side of the Project. In the beginning we create a plan and a design for the product, then we start the project and create the product. In certain projects, such as IT development Projects, we have big problems with this idea because we cannot understand the real expectations of the products upfront. So, my question at the end of the previous article was: How can we solve this problem?
One way is to keep using and improve the current approach. This approach is called: Predictive. Because we try to predict everything upfront. So, the next question will be: How can we improve it?. For example, we can have a better communication in our project. But experience shows that, even if better communication helps, it doesn’t really solve the problem.
Maybe we can get help from prototyping or modeling at the beginning of the project when we try to understand the expectations? That has been proved that helps, but again, it doesn’t solve the problem. Then, What can we do?
One alternative is to change our development approach and this is how we can do it:
At the start of the Project we don’t know much about the expectations of the customer but instead of trying to make everything precise in the beginning, we just go on with the project for a short period of time, we think about different ways of approaching the project and we pick the one that seems to be the best; the one that we believe will bring us closer to the expectations as we know them.
So, we run the project for a couple of weeks, create a “small piece of product” and show it to the customer. Is in this very moment that we realize that maybe the only thing that is in common between technical people and business people is the product, and that’s the only way we can really understand each other.
But not everything is nice and easy as it may seem it is. The problem with the predictive approach is that we only have the working product at the end of the project and we cannot really use it to create understanding so, we will have multiple products during the project. As I told you before, with the Adaptive Approach we spend a few weeks and we create various small pieces of the product (something that works), we show it to the customer or the business side of the Project and we receive their feedback.
Using that “feedback” and the new understanding we have from the way the business works with that small piece of product, we will have a better understanding of the expectations. Therefore, we’ll be one step closer to finish the product.
Now we can take the next step, using the new understanding we will think about the final alternatives, pick one that seems to be the best, create the second version of the product, show it to the customer again, receive more feedback and we go on like this until we realize all the expectations. This approach is called Adaptive Approach because instead of using a Predictive kind of understanding that is created at the beginning of the project, We go on and we let the environment helps us adapt our final way to the project.
One common problem is that we don’t think that Adaptive Approaches will just go with the project, we don’t care about planning or designing or anything else. Nothing farther from the truth. The truth is that we are using a very special approach, a certain process that helps us use the environment to find our way, we still have to find our way. This approach is what we call Adaptive. Adaptive Approaches are called “Agile” and when you use Predictive Approaches in IT developments, we may want to call it “Waterfall” as well.
We don’t use the word Waterfall when a predictive approach is used in another industry such as construction, it is just about terminology. We can also call it a Life Cycle.
As you see in the picture above, one of the major differences that we have here is that we have multiple versions of the product, instead of one version that is created at the end of the predictive approach.
Do you know the term that we use to refer to when we have multiple versions of the product created during the project? Let’s talk about it in the next article.