Specifications - A Suppliers Guide

Suppliers can benefit from a spec guide just as much as clients. We can fall into the same traps as clients. Too often suppliers:

• Fit a solution around our existing skill set
• Don’t question the functionality outlined
• Don’t consider alternate solutions (or are not encouraged to)

But most importantly as developers we will receive poor specifications. Actually, oftentimes we just won’t get specification that’s usable.

We’ll get anything from a small paragraph to a thirty page document that is too prescriptive. It’s not the document required for a succesful project and happy clients.

That’s why I suggest to all suppliers to get into the specification writing businesses. It’s a critical business tool. It helps you secure more work, better work and complete it with happy clients.

A succesful project is one that fulfils your clients business needs. If you can identify and then achieve these needs you massively improve the chance of their business growing and returning work to you in the future.

That’s why getting a good specification down is so important for both suppliers and clients.

What a specification is not

The word specification is confusing and used in different contexts. The more technical often associate a specification with a complete itemisation of the work to be completed.

I call this a technical specification. This is not what we are working on at this early stage.

Many suppliers would call the specification we are creating more of a brief. The naming convention we decide upon is somewhat academic. The aim of the document is more important.

I consider the specification to be the outline of business objectives, timeframes and budgets which a supplier can use to provide an accurate proposal.

A technical specification is created after the general scope of the project and the direction of the project is decided. Typically this document includes specific details about the steps involved to complete the project.

There are many different process workflows such as agile which don’t use a prescriptive process and instead focus on smaller chunks of work (often called sprints).

In any case, it’s important to note that these specifics are different and separate from the specification we are building.

Charging for this service

Both a specification and technical specification are important to succesful projects. I’ve spoken to dozens of freelancers and agencies and there is no agreement on how to approach specifications.

Generally there are two camps. Those who provide a specification for free and those who charge. If you charge then you run the risk of loosing the work while if you provide the service for free then you run the risk of working without getting paid.

I’ve seen an expectation among clients that this is not a service that should be charged for. So it’s a tricky risk to balance. The main danger of not charging for a specification is not spending enough time on creating a thorough spec. This can result in projects going over budget and timeline (and/or skill set).

There is risk in both circumstances and the decision you take will likely depend on your work pipeline.

Here is a breakdown of the pro’s and con’s I see in free vs charging:

Free

• PRO: Build a rapport with the client
• PRO: Demonstrate knowledge
• CON: No guarantee to get paid
• CON: Less time to spend on spec may mean less reliable

Charge

• PRO: Weed out tyre kickers and clients with poor expectations
• PRO: Sets expectation of value at start
• PRO: Can dedicate more time to a thorough spec
• CON: Less likely to win the work

Estimating Time

I’m afraid there is no silver bullet here. Estimating your time is hard and isn’t always reliable. This is something that improves with time and later I discuss some ways to get more accurate.

There are many ways to price projects but I suggest that you outline time estimates and bill for your time. This is called billing for time and materials.

There is a big shift to value-based pricing. That is to set fixed prices on the projects. I think this is a great way to price projects that you can have a clear expectation on time estimates. However if there are uncertainties then you run the risk of bearing the cost when projects overrun.

This comes down to risk. The more bespoke and complex the project, the more unknowns. The more systematic and consistent your process the less unknowns. For many projects value based pricing is too high risk.

Many projects are a collection of unknowns. Perhaps there is existing custom development that needs integrating. Or designs that have not been created yet.

We can make educated guesses about what the work will look like, but it is impossible to be 100% accurate.

If we are working from scratch this much less so. You can create a systematic workflow and have an accurate understanding of the work involved. However in many cases the work is not so clear cut.

If you do charge for time and materials it’s important to emphasise it is an estimate. Not a fixed cost. This is important for you and your client. Setting this expectation early avoids you working beyond the scope of the project.

The more clarity on this the more chance the project succeeds.

Estimation Tips

1. To improve your estimations try and log the estimation against the real work. This way you will get an idea of how realistic your estimations are. Perhaps you always over estimate and can adjust accordingly. A simple spreadsheet logging this is really useful.
2. Add a buffer time to your estimate - some time that is yet to be allocated. Be upfront about this and call it a buffer time and explain to the client that this is for unknown items. Again this sets a clear expectation with the client.
3. Communication is critical with estimates. If work is taking longer, communicate this to the client straight away and set the expectations early. I suggest weekly ‘stand up meetings’. That’s jargon for a weekly update. Even if no progress has been made, you can catch any frustrations or concerns that otherwise may simmer away unnoticed.