Your software vendor sees your project through a keyhole. Or how to successfully outsource a project?

You carefully selected the best software vendor and defined the project. Then magic happens and you see your project brought to life. Well, it’s not exactly what happens…

Through a keyhole

For a second let’s assume ideal scenario could happen. We who build the software for you, get a 100% complete specification of 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 the 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 of 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. This is the curse of knowledge in action:

The curse of knowledge is a cognitive bias that occurs when an individual, communicating with other individuals, unknowingly assumes that the others have the background to understand.

We have to uncover the assumptions relevant to your project while we work on it. There’s 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. Think about delegating work to a single employee. This is a difficult skill in and of itself, even though they are already embedded in your organisation and they know the context. Delegating a project to a new team is difficulty squared! What I’ve seen time and time again is an eager and professional team blocked by lack of information on where to go with their work.

Open the door

There’s a number of 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 there’s an experienced product owner 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 a big, fat, in-depth documentation of requirements. This 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. Obviously they’re busy with their own 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, pickup the pieces of information, get to know the people involved and carve out what needs to be delivered in scope of the project.

If you wanna see your project successful open the door! Let the light shine on the requirements, questions and assumptions! Do it either by following Agile or Scrum, connecting us with your product owner and allow us to work together with your team from time to time.

Originally published at evojam.com.