Photo by lalunecreative @ unsplash.com

What we can learn from a car crash request for proposals

It all looked so promising. A professional needed a website and his query found its way onto a developers’ online forum. What could go wrong? The answer to that, it turns out, is almost everything.

A promising start

The message revealed that the potential client had a portfolio to show off and needed a relatively simple brochure site. He had decided that, because his mate used a self-hosted WordPress instance, this is the way he should go too. He primarily wanted help, he said, with initial set up (SSL certificates, hosting, DNS etc). He was vague about the level of actual development he would need to render the content itself, implying that he might take that on himself. He thought that he would be paying for a day or two’s work at most.

Various people emerged with ideas. A very approachable project in a couple of days, they said. Various WordPress themes were suggested that might be suitable for a fast turnaround.

All that was needed, it seemed, was for client to pick from the interested developers, pin down the brief, and work could begin.

It begins to fall apart

And then some of the interactions between the client and potential developers began to filter back to the forum.

The client said he might pay 200 GBP for a site ‘if the design was exceptional’, thereby both setting an an extremely low budget, and widening the brief to include design and build on top of set up.

When it was pointed out to him that two days at his budget barely amounted to the UK minimum wage, he suggested that the two days he had mentioned referred to project duration and not time spent in hands-on development.

These nuggets were shared to the forum along with an unflattering commentary from a developer — which inevitably made its way back to the client.

The client doubled down. He accused developers as a species of palming off old work on unsuspecting clients, and vowed that he would not pay for anything that was not created especially for him and, even then, only if he liked what he saw.

Of course, by this stage, it was clear that no-one from the forum was going to be working with the client. But how might it have gone differently?

Defining requirements

At getInstance, we have been thinking about what it is we offer. We have come to the conclusion that what we really do is help with growing pains. That is, we are called in when a client identifies a need to move from one state to another. From no site to the right site, for example. From a broken system to a system that is fit for purpose.

Neither the problem state nor the solution are always obvious. What kind of site or system is needed? What are the constraints at play (in terms, for example, of budget, time, platform)? How is a broken thing broken? What kind of solution will address the problem? A framework? Fixing an existing system? A product like WordPress or Ghost? Something in between? What are each solution’s risks and benefits?

Finding the answers to these questions is a collaborative process. How we communicate as clients and developers to define requirements and map out the steps needed to achieve them is the first, maybe the most important, challenge in the development process.

To break it down then, a good project experience requires:

• A well-identified set of requirements
• An understanding of the constraints that might limit those requirements
• Effective communication to define both these needs and the scope and process of the project

From the very start, each of our best projects has been a collaboration with our clients.

So what went wrong?

The potential client may seem to have made a reasonable start. He identified a need — a site to show off his services. He provided a set of constraints — budget and timescale. But, it turns out, this did not amount to the foundation it resembled. Among the red flags identified throughout the exchange were:

Lack of clarity

Although the client specified a budget, he was vague about the actual work he expected within its scope. Did he want design or just set up?

The budget itself turned out to be unclear. The client wasn’t sure whether two days meant developer time or project duration — a crucial distinction for cost. Was this shaping up to be a four hour job or a sixteen hour job?

Finally, and most importantly, would the client even pay for work done? He seemed to imply that he might not.

(Probable) feature creep

Feature creep is the offspring of a lack of clarity. Where a brief implies rather than defines required scope, it is likely that all sorts of extras will be discovered during development. This can adversely affect budget or timings. Where a team is committed to a fixed budget, feature creep can force it to work at a loss, risking the complete breakdown of the project.

Bad faith

Both vagueness and the consequent likelihood of feature creep suggest bad faith. When deliberate, a vague scope can be used as strategy to extract more work than expected from developers. But this reality shows itself sooner or later, and it has a way of biting.

The client insisted that the work he was commissioning would be both easy and of low value. Explaining to a developer exactly how easy a project should be suggests at best an unfortunate kind of magical thinking. Good developers, make hard things look easy.

He expressed a lack of trust in developers as a breed. A client who believes in their heart of hearts that their developer is out to cheat them is unlikely to get good results. Especially if he tells them so.

Worst of all, he implied that he might not pay at all if unsatisfied by the work provided. Now, the right to withhold payment for bad or missing work is part of most contracts, but its invocation at this stage of negotiation strongly suggests that the possibility of a dispute would haunt the project once begun.

Over specification

In object-oriented programming there is a principle that goes like this: code to an interface not an implementation. This means that you should define and work with components by what they do rather than how they do it. We might adapt this here to project specification: specify according to what you need rather than how to get it.

The client’s constraint, that the new site should be built as a self-hosted WordPress project, was not in itself unreasonable. To be sure, he may have had good reasons for asking for this (familiarity with the platform, perhaps, or an eye on a particular plug-in).

On the other hand, it would be worth subjecting the requirement to scrutiny. Self-hosting WordPress is not rocket science, but if you’re not technical yourself, are budgetarily challenged and want some design or page-build input, it might well be worth inviting other options. Carrd, a hosted WordPress.com site or a Ghost account might all have been more appropriate options to get him up and running on a budget.

If you are asking professionals to propose a solution to your problems, you may unnecessarily hamstring them (and risk your project) by insisting in advance upon the particular solution you expect.

A Better Approach

You might think that this article is just another example of a developer dunking on a nightmare client. And, of course, given the red flags described above, this conclusion is hard to avoid to some extent. The flags might, however, be treated less as a reflection of the client himself than of the way he communicated. So, the real motivation here is to look at how a product owner might commission work more successfully.

So what can we distill from this little case study?

• Begin with functional requirements (privilege your desired outcomes over the means you expect to be employed to achieve them).
• Be clear about the work you want done, but be ready to amend your scope. Your requirements will likely evolve based on your discussions with developers. You can streamline that process by being as specific and consistent as possible from the outset.
• If your budget is constrained, then ask what and how much work will fit within it. If you fix both scope and budget up front then the only thing left to reduce is quality, and even that can only degrade so far.
• Don’t tell experts what is easy or hard — gauging difficulty is one of the reasons you’re talking to them. Even if you’re pretty sure you know exactly what the lift is, you will not endear yourself to your developers by telling them what a piece of cake their job should be.
• Attempt not to impute bad motives to your developer or to developers in general. Even if you truly believe that the world is filled with cowboy coders, saying so will make your project less likely to succeed.
• Aim to define the metrics for a successful conclusion. Rather than implying that your ultimate satisfaction will determine sign off, build acceptance gateways into the project itself.

What next?

This has been the first in a series of articles from getInstance about the often-fraught issue of client / developer communications. Time and attention allowing, we may expand these into a short e-book about some of the typical problems that product owners encounter, and the ways that development teams can help (or, occasionally, hinder) the search for solutions.

You can help us with this by weighing in with your experiences and opinions.

Up next: Fear of Change.