2. Writing the Specification
Our goals are the focus for our blueprint. We should work backwards from where we want to be, from the needs we’ve identified.
We do this and we have all the chance at success. If we don’t, we’re shooting in the dark.
In fact, we had a shot of this in he last chapter when outlined our processes. There we showed our workings. We said this is how we currently get to our goal, and asked for alternative solutions.
But sometimes we are starting from nothing. We're not just iterating for improvement. So we should also identify our key goals and not just improve what already exists.
Our goals should be our true north for everything in the specification. We should be careful to make sure everything is focused on these goals, so we build to well defined needs.
Life’s too short to build something nobody wants.
When we looked at our business model we identified our primary need. To be generating a profit and return on our investment. This is the most fixed element. Our other needs are more fluid.
There can be a range of solutions for both our resources and our processes. A succesful goal will not be prescriptive. It will free us to find new solutions.
Too many times I’ve seen complex requirements for some custom functionality that I knew could be achieved by existing software. However the specification was fixed. It needed to be built that way.
It is great to have a detailed breakdown of the resources and processes you require, but by setting out the goals you want to achieve, you let other experts chime in with their experience and insight.
If your specification is inflexible you may be building surplus to requirement.
Individually, we are not experts in every field. By sharing our core goals, our business needs, with our team, we open ourselves up to alternative solutions. Solutions that may achieve the same goal quicker and more cost effectively. Which is after all, the main goal of the business.
Basic Template to identify Goals
To identify goals I use a simple template. You might not need to 'show your workings' in the actual specification. Just defining the goals should be enough. So this might be for your eyes only, but breaking down elements according to this template helps clarify your goals:
- Problem and Goal
Problem and Goal outlines the problem. What is the reason this work is important. Be broad. What is the top line need. How will this benefit your business.
Requirement is the specifics of what can be done
Proposition is a detailed outline of your ideas. You might not need a proposition because perhaps you are not sure how to solve the problem. That’s fine. If you do add your ideas, I suggest jotting them down as bullet points. This helps identify the steps involved and also, people love lists!
Caveats identifies some immovable items. This helps the supplier to come up with ideas that are not completely out of the box. Ideas that can work within a framework for your business. Often we mention our ‘tent pole’ items from our technology stack.
Response is empty. It’s there for your supplier to fill in. This is where they’re experience can help. They might concur with your proposition or they might have new ideas. This is where we will find out.
Here is an example from our imagined e-commerce store:
Problem and Goal: Reduce manual work with accountancy
Requirement: Integrate our Accountancy Software to our e-commerce store
Proposition: Build a custom api integration using the available documentation
Caveats: We must continue to use ECommerce platform X and Accountancy Software Y
Response (from supplier): There is an existing integration called FabIntegration which can do this and costs only $50. Alternatively the custom development will be approximately 3 days work (at $500 a day).
Mapping out your goals
Make a list of all the challenges in your business. Find the problems and list them. You can sea from our template above that the goal is often a counterpoint to a problem.
Some may be specific, like our accountancy example above. Others might be broad, like improving company branding.
I know some companies that have a document where they list down any rough areas of their business. Anything that can be improved, jot down.
Once you have your problems, use the template above to outlined the requirement, proposition and caveats.
In our next chapter, we’ll look at organising these into a cohesive set of requirements we can use in our specification.