7 ways a Functional Specification will save you time and $$$

Way back in 2000 – that was before the 1st Blackberry! – a young man named Joel Spolsky said that any software project requiring more than a week of coding required a functional specification document.

Mr. Spolsky doesn’t write as many blog posts now as he did back then, before he moved on to ventures you may have heard of, such as Trello and Stack Overflow. Today his net worth is estimated to be $100 – $500 million; he’s a busy man. So you might think he knows of what he speaks.

Yet, many programmers argue that a functional spec is a waste of effort and money, and many clients feel the same way. Why not get working on the project, rather than spend days or weeks describing it in mind-numbing detail?

This mindset is heightened by the fact that the decision to start a software product usually takes longer than anyone wants it to. By the time it gets to the development team, at least one person has their pants on fire and wants to get right on it.

What is a functional specification?

Before I address that question, let me clarify what a functional spec is and isn’t. A functional spec does NOT describe implementation, data structures, or programming languages. That’s the role of the technical specification.

The functional spec describes how the software will work from the user’s perspective. It describes features as well as screens, menus, dialogs, and so on. In a word, it describes function.  

Because when you design new software, the critical thing is to nail down the user experience (UX). What are the screens? How will they work? What do they do? How do you get from one to the next? Start with the function, not with the code. Start with the end in mind.

At Factora, we’re big believers in the payoff from a functional spec – it’s the starting point for successful projects that save the client time and money. Following, 7 reasons why it does that. Some will leap to your mind, particularly if you’ve worked in software, but others are less obvious.

1.   Make the ugly decisions early

Programmers love to roll up their sleeves and jump right in. But doing that often means that partway through, when a difficult choice has to be made as to how to execute a certain feature, it turns out that the early route taken was a poor one. A functional spec, for the programming team, highlights the difficult choices, the technical gaps that could become blocks, and forces better decision-making early on. As to the idea of get going now, and make those decisions when you have to? Don’t even think about it.

2.   Communication takes more time than you think

A functional spec provides a playbook to go by, one that everyone involved regularly refers to. It’s a single source of truth. This cuts a great deal of wasted communication time, a lot of unnecessary back and forth. Team members spend less time during hand-offs explaining to one other – or bickering – about how the program will function.

It’s a synchronization tool. A baseline for change control. And a necessary bridge between any diverging opinions.

3.   We all know what happens when you A-S-S-U-M-E

We humans all live in our own little brain-worlds. When one human describes something to another, the listener starts to build a picture in their brain. And while that picture begins with the words uttered, it’s then colored in, inevitably, with assumptions.

A functional spec – partly because it’s thorough, partly because it’s visual – paints a much clearer, more detailed picture in the user’s mind. Wrong assumptions are corrected. Misunderstandings can be cleared early on – when it’s cheaper.

In tandem, a functional spec also forces the development team to check their assumptions. Once we realize we need to do XYZ, we then need to check that it’s possible to access the required PQR in order to do so. Once you lay it all out in a functional spec, those unhappy surprises that occur halfway through a software project come close to disappearing.

4.   Sober second thought

Even if there is perfect clarity between developer and users, the users need a chance to see before they agree. What they have said they wanted, what they thought they wanted, may need adjustment.

Seeing gives the users a useful reminder of what may have been neglected or omitted. It jogs the memory. It allows them to more accurately compare the new way to the old, and discover possible issues. Here is how it will be interacted with. Here’s how you interact. Often they change their minds at this point. This is a good thing, or at least, a good time to do it.

As well, it’s a user/client heads-up. Early on, the client knows they need to provide us with access to this or that system or database.

5.   The payoff of inclusivity

It’s cumbersome, collecting the views and input of all users and stakeholders for a new program before beginning to code. In many environments, it doesn’t happen, a major cause of enduringly poor software and user misery.

But with a functional spec, you have a system that dictates the gathering of requirements from all involved, at the outset, rather than when it’s too late. (A month or two into the project: “You shoulda talked to Joe!  Didn’t you? He has a bunch of new requirements…”)

This means you won’t just hear from the louder voices (trust me, you’ll be grateful later on). Because software on the factory floor can affect operators, QA, inventory, accounting … you get the picture.

6.   Reason 5: Avoid code-cling

Say you don’t create a functional spec, and instead Sammy the Speedster gets head-down-and-going on the code, el pronto. At one point, someone realizes that Sammy has taken the wrong direction. But Sammy’s now invested two weeks in his work. And code is not like a Word document, where you can just delete or change a paragraph, it doesn’t work that way. So Sammy’s more than reluctant to throw his work in the trash (which is the best economic decision at this point, for all involved, but assuredly not the easiest one).

So Sammy convinces the team to keep all or part of his code. And now we’re developing a system based on Sammy’s Bad Start rather than user requirements. You so don’t want that. But believe me, it happens too often in the coding world.

7.   Early focus on the user and UX

If you saw my colleague Ryan Burns’ post on building sustainable solutions that earn customer adoption, you’ll know how seriously we take user input at Factora: on one of Ryan’s recent projects, our Chief Innovation Officer, VP of Sales (now CEO) and Delivery Leader all travelled to take part, on-site, in the meetings with the operators – all four shifts of operators. Plus their IT team and business leads.

The days of building poor software with an ill-designed interface are over. Now – lightbulb! – instead of forcing people into software, the goal is to build software around people. To design functionality as the users would have, if they could have. That is the road to  fewer errors, higher quality, better workflow, higher engagement, and higher productivity.

In summary

Question: What’s the best way to add value to any project?

Answer: Mitigate risk. Starting with a functional spec mitigates project risk, one of the highest predictors of project success. You reduce or prevent problems or wrong turns, or at the least address them early on when’s it cheapest. Your project will be a smoother, happier journey, resulting in a better, more sustainable product with a significantly better user experience.

That relatively small investment at the front end will pay off richly over the course of the project. And onward, in use on the factory floor. Because better tools make for better results.