Mind the GAP
Bridging the Tech-Divide
We all know the buzzwords, and the most up to date software development techniques, at least most of us like to believe we do… "Agile", "SDLC", "Test-driven Development","Functional Designs", "Use Cases", "Technical “Designs", etc., etc., yet we fail to understand that our strongest weakness lays right in front of our eyes, I like calling it "The GAP".
The gap is everywhere starting at the top of the command chain. The Stakeholders A.K.A C-Level Executives or Business Managers that want their Business or End Users to perform a function in their applications, functions or tasks they likely do not do in the way the Stakeholder thinks. Most of the data collected will probably be not ever actionable, whether because of its irrelevance or the lack of integral reference. Then, you have the Business Analyst, yes you, writing a functional design to describe the so-called function for a system for which he/she does not know with technical depth. Hence the gap again, and last but not least the Software Developer who has to deal with a double whammy. Translating the functional requirement to a technical one, and in most cases, also deals with his gap, knowing less than he/she needs about the technology that will be used to create the solution.
Quite a riddle?
Over a wide array of projects, I have seen an impressive range of variations of the infamous gap. The chart below shows a non-discrete measurement, purely subjective, of twenty-four start-to-end software development projects.
As a person that loves the Ocean, I like comparing these variation ranges with simultaneous ocean swells. Swells like knowledge, passion, and drive, are energy that travels over miles under the seafloor, and then arrive at our shores in the form of waves. Disorganized "gappy" waves call for messy, not so good surf.
Today, more than ever, it is the time of the Business Analyst, his responsibility goes above and beyond, to close the knowledge gap, but how? Is there a silver bullet? There is not! Very likely in most cases, we will fail, but don’t we at most things we first attempt?
My findings are:
1. Uncover and expose business facts first, what do Execs need, what will the End User really do? Do this in joint meetings where all parties concerned to hear their voices, not just a subset group, be thorough, really thorough! This step lays the foundation for the rest of the project.
2. Write up a clear functional specification that solves the business need (of course, you already knew this), but, I recommend you break the solution down into very short phases, especially when the requirements are hefty, and make sure your development team only develops a subset at a time.
3. Be clear about the overall solution scope with your developers so that they can plan, but have them focus on quick iterations and start developing your first phase, then quickly release to users as a pilot, and repeat.
All of it is hardly rocket science, and we can all apply it well with a little focus. Be brave, smart and above all, be better than "The GAP"!
Thanks,
Cariel Cohen
