Last updated on September 8th, 2022
You carefully selected the best software vendor and defined the project. Then the magic happens, and you see your project brought to life. Well, that's not exactly what happens…
Through a keyhole
For a second, let’s assume the ideal scenario could happen. We, who build the software for you, get a 100% complete specification of the new project. A well-informed person, a product owner, is available to answer our questions at all times. Even in this optimistic scenario, this spec and contact person are a tiny keyhole through which we see your project. Looking through it, we try to uncover the assumptions that underlie your project. They can involve technologies, tools, communication channels, your market, your users and clients, code conventions, architectures, business priorities, and a million other things…
The thing with assumptions is that they aren’t expressed explicitly in 99% of cases. It’s natural. They’re part of the culture of your organisation. You don’t even see them because you live and breathe them. That's the curse of knowledge in action:
The curse of knowledge is a cognitive bias that occurs when an individual, communicating with the others, unknowingly assumes that they have the background to understand.
We must uncover the assumptions relevant to your project while working on it. There are also expectations on both ends, but let's leave them aside for now.
It’s unreasonable to expect that transfer of knowledge, expectations, assumptions and all of the culture-matching will happen by magic.
It is a difficult skill in and of itself, even though the person is already embedded in your organisation and knows the context. Delegating a project to a new team is difficulty squared! I can't count how many times I've seen an eager and professional team blocked by a lack of information on where to go with their work.
Open the door
There're several ways to counteract the keyhole problem. Our favourite is to follow literal Scrum in new projects done by new teams for new clients. (Have you noticed the number of risk factors…?) This approach can work wonders, especially if an experienced product owner is on your side. Scrum has a number of checks to counteract the problems above. For example, the focus is on delivering working software quickly and regularly because that’s when we can uncover the assumptions.
Obviously, Scrum is not always feasible. In that case, we need to find other ways to handle all that uncertainty. It could be extensive, in-depth documentation of requirements. It is a good start, but please don’t assume it’s complete just as we shouldn’t assume it will never change. The most helpful thing we can hope for is a single, responsive, decisive and well-informed product owner. A contact person who will answer dozens of our questions and guide us through the maze of your organisation.
In real life, the knowledge is spread across multiple people in your company. Naturally, they’re busy with their things, so answering our questions or being available to us is not their priority. In such situation, it is best to immerse us inside your organisation. Even if it’s only for a while and even if it’s just a single person from our team. Someone delegated by us needs to go to work in your office to understand the context, pick up the pieces of information, get to know the people involved, and carve out what needs to be delivered in the scope of the project.
If you want to see your project successful, open the door! Let the light shine on the requirements, questions, and assumptions! Do it by following Agile or Scrum, connecting us with your product owner, or allowing us to work together with your team from time to time.