Nobody said that building digital products is easy – and one of the key risks to a successful outcome lies in the relationship between the product’s owner and his or her development team, be it in-house or outsourced.

At Keplar we see these issues for ourselves when we’re called in to help a pre-existing project team which has somehow gone off the tracks. At that point it’s natural for the client to blame their developers – and it’s certainly true that the most visible aspect of the project’s problems will be what the development team has done (or hasn’t done).

As we dig deeper, however, we often find that poor quality work is a product of more fundamental problems in the working relationship – in particular:

1. Unrealistic expectations – the client’s expectations about what service the development company will provide are plain wrong
2. Poor communications – the client and the development company fail to communicate with each other effectively
3. Misaligned incentives – the development company’s objectives and rewards run counter to what benefits the business the most

In the rest of this blog post we look at each of these problems in turn, and try to come up with some tools and techniques to resolve them.

Unrealistic expectations

There’s often a big disconnect between what development companies offer, and what their clients think they offer. In the hope of narrowing this expectation gap, let’s say a little about what development companies are good at, and what they are not good at.

In short, development companies are good at:

• Taking the functional requirements for a product and turning them into a technical specification
• Taking a technical specification and building to it
• Recommending technologies which they own (e.g. in-house-developed content management systems), or have experience using, or want to learn to use

What development companies are not good at:

• Taking business goals and turning them into the functional requirements for a product
• Understanding how the technical components of a product relate to the wider proposition (marketing, monetisation, maintenance etc)
• Providing neutral recommendations for which technologies to use

Given the above, when someone takes a business idea straight to a development company, it’s like somebody with a plot of land going to a builder instead of an architect. In creating a new digital product, there’s a vitally important layer between the business strategy and the actual development work – a layer which all too often gets overlooked. Try to factor this layer into all of your planning.

Poor communications

Businesspeople and developers speak fundamentally different languages, and neither party is particularly good at translating!

Again, it’s the role of the architect to act as an intermediary and ensure that a project isn’t jeopardised by communications breakdowns. There are various tools and techniques you can employ to do this – our top three are:

1. Mock-ups – turning functional requirements into mock-ups or wireframes helps everybody to visualise the product and prevent misunderstandings. It also helps to identify any gaps or contradictions in the requirements. We use Balsamiq Mockups to create these (another post to follow on this)
2. Issue tracking – part way through a product build, the number of issues to keep track of suddenly goes through the roof, leading to email ping-pong and things getting forgotten. The best way round this is to use dedicated issue tracking software – there are some good ones out there, we use Redmine
3. Daily check-ins – developers often want to be left alone to “just get on with it”, but a daily check-in keeps things moving and identifies issues before they become showstoppers. We run daily check-ins as part of the Scrum project management methodology

We recommend giving all of these tools and techniques a try.

Misaligned incentives

There are only really two ways of paying for external developers: on a time-and-materials basis, and as a fixed price project. Most development projects these days are fixed price, especially if the developer partner is not previously well known or trusted.

The trouble with fixed price contracts is that the developer’s incentive is to sell a client as big a project as he or she can afford; then once that work is won, the developer focuses on fulfilling the requirements as set out in the contract to ensure that they get paid in full. Any scope creep for which the developer can be paid extra is an added plus.

The flaw in all this is that “no plan survives contact with the enemy” – in other words, as a project goes on, the team’s understanding of the problem they’re solving evolves, and the product changes with it. And this evolutionary process goes into overdrive when the first customers start interacting with the product! Developers’ misaligned incentives stifle this process.

How do you solve this problem? At Keplar we encourage clients to “think small”, only building enough of the product to get it to market, gather data, test hypotheses and design the next iteration. It doesn’t make much money for the development company, but it gives a project on a tight budget a much better shot at making it!

A final thought

Back when the vast majority of company websites were simple brochureware, the above risks might have wasted some time or money but didn’t pose a significant risk to the business itself. Today it’s a different story: how a business operates and competes online is now a major factor in its success or failure. In short, the web has grown up, and it is time for businesses to start engaging with development companies in a more serious way to reflect that.