What we know and what we think we know

Every time we start a new project we try to understand what it entails. To accomplish this, we talk to people who know the ins and outs, we review the information and attend some meetings, in which, we clarify everything that is needed to define what we are going to do from beginning to end. With that plan in mind, wouldn’t we carry it out as is?

Although that is what we would expect to happen, let’s be honest: It virtually NEVER happens.

Why is that? You see, what we think we understand at the beginning and what we really understand is very different and the conditions surrounding certain projects usually change over time. This is usually due to either the same user or person, who is aware of the necessity, wanting something else, having discovered new requirements or third party opinions suddenly appearing and providing their own opinions on the matter, as well as, what actions should be taken. The result of all this is that we end up seeing new paths that we had not contemplated before and that on many occasions completely deviate from the course of the objectives we set out from the beginning.  In fact, the coming of changes does not represent a problem in itself, because in any project, no matter what it is, changes will always come up. The matter complicates itself more because, even with all these changes, we continue to intentionally ignore their existence or act as if we knew more about the future than the present.

Let me explain.

In traditional methodologies, we always deal with anticipated risks which, let’s say, is fine because we should be more preventive rather than reactive. What happens is that we usually do this at the beginning, when we have less information, therefore, even if we do inception sessions where we try to identify what is required to prioritize, leading us to acquire more clarity, we should not fall into the mistake of thinking that we already know how we will go all the way in delivering a working product. Although, we can recognize the effectiveness of these practices, they are, however, not enough! And what this ends up generating is that we are more attentive to risky situations that will probably never materialize causing us to ignore the actual risks that would arise and that we had never identified. 

Among those risks that are usually identified in this type of methodologies, there is one that I have never seen that has been taken into account and it is precisely the risk of believing that we know more than we know and it is a risk that is almost always, if not always, present at the beginning of the projects that we execute. This is truly is paradoxical seeing that, the advancements in the development of a project is when we actually begin to know more about what we should do and how to do it; this is gradual, not something that happens immediately with the first meeting, with the kickoff meeting or any other.

Often what is most serious is not thinking we know more than we do, rather, that at some point we will come face to face with reality itself which is when we truly realize that we did not know as much as we had hoped, therefore, forcing us to level the playing field with the knowledge of what is definitely needed to achieve the proposed objectives. What’s more, oftentimes, the proposed objectives might not be as clearly thought out as we expected, leading us to fall hard, as if we were falling off a cliff of knowledge.

This begs the question, what do we do when we fall?  I will answer with another one: What if we start doing things differently?

For example, let’s not try to have everything controlled and defined at the starting point. Let’s try to define the minimum necessary for that moment and, above all, let’s generate an environment of constant communication between the whole team, including the user, customer or Product Owner or whatever you prefer to call it. Because the only way that I know and that seems to be fundamental for a team to have sufficient and necessary knowledge about the objectives at all times, is assertive communication, a communication that includes all the people who can decide and define the direction of the product. An approach far from the source of the definition will only haunt us with reprocesses making it all the more impossible to reach the desired value generation.

The invitation here is to find a way, based on each of our contexts, to be as close as possible to the source of information on what we want to work on, to generate short work cycles with feedback on what has been done, therefore, avoiding a defined and controlled assumption of total knowledge at the beginning. And yes, I know it sounds difficult, but I also know that, if we do it consistently, we will be ever closer to results that generate real value, even if they are far from the results expected at the beginning.

Might I add, it is important to clarify that this is not new, it is what is proposed from agility, where frameworks such as Scrum is proposed to achieve a gradual and evolutionary value, as well as, constant teamwork, to truly accept change as part of what happens.

The cover image was taken from undraw

Stay up to date with our publications through our social networks: LinkedIn, Instagram and Twitter, or leave us your information and receive our monthly newsletter (mostly in Spanish).