We’ve done quite an amount of projects at Foreach. Some have gone swimmingly, others have been less of a smooth sailing. And the functional analysis – the part where we draw up an application’s functional specifications – has been a culprit more than once. In order for history not to repeat itself, we’ve listed a few of our common mistakes, and how to not make these mistakes again. Henceforth…
Don’t dive in too deep, all at once
Usually, in the beginning, there’s chaos. A torrent of requirements – if you’re lucky – or a serious lack of input – if you’re less lucky. In any case, it’s up to us to create some sort of structure in that informational chaos.
That’s not always easy. A mistake we’ve made in the past is to single out the one thing that appears to be straightforward to start with. We got sucked into this one part of a feature, or story, or ticket, ending up with one, shiny piece of the puzzle wrapped in a bow.
And then we realised this shiny piece did not fit with the rest.
So resist the urge to start without the necessary input. Don’t delve into the details of one part of a functionality. First, make sure you understand the bigger picture. Connect the dots. Start from the top and gradually work your way to the bottom level. And then, you won’t miss dependencies and you won’t have to throw out work.
Not writing down what is not, on top of what is
We tend to write down what an application must do, sometimes in painstaking detail. But what we often forget, is to add what is explicitly decided to be out of scope (for now, or ever) and what was implicitly assumed.
As humans, we communicate through words. And when we use certain words, we usually think we’re being pretty clear and unambiguous. Until one day, we’re in a meeting with a business client, discussing a feature, and both parties disagree on whether or not it’s included in the formerly agreed upon specifications, even though we’ve got the same text in front of us.
As they say, the devil is in the details. What we’ve noticed, is that adding an ‘assumptions’ and a ‘not in scope’ section tends to elicit more and deeper discussions beforehand, which prevent those same discussions from happening after development has already been done.
Working on an island
Collaboration is key for, say, 95% of all jobs. But it’s especially key for a functional analyst. Working on an island is the biggest no-no of all, because our main task is to fully, truly understand what the business client wants, what is technically possible, and what is the best way to go about it. Therefore, our communication network should minimally consist of three main players.
First, we’ve got the business client. This is the person giving the requirements. He or she is instrumental in deciding on scope and signing off on your work.
Then, we’ve got the developers – the technical wizards. They can tell you how technically complex your proposed flows are, and perhaps prompt you to make a little functional change that has a big technical impact.
Last, but not least, we’ve got our fellow functional analysts. Never hesitate to ask feedback from a peer, or spar with one when you’re stuck on a question. Usually, they’ve worked on different projects, have different experiences, and can help you with a different point of view.
It’s important to consult with these players on a continual basis, not just once, in the beginning. Involve them throughout the whole analysis, so that everyone remains on the same page. Functional analysis is not to be done in isolation. Functional analysis is to be done in joint venture.
In the past, we did it all. We wrote stories too fast, with little information, all on our own, solely from the perspective of a happy-go-lucky scenario where everyone magically understands everyone. This has led to a rougher ride than we should’ve had. And so, we agreed to work more thoroughly, go after all needed input, involve an entire team, and look at things from all perspectives.