The gap between offshore delivery and business expectations
The biggest concern I have heard from overseas clients raise on the outsourced software development model is that they don’t get what they really want and on top of this they have to spend a lot of unnecessary time, money and efforts in first proving that there is a gap in what’s been asked for and what was delivered, And then fixing the issues to take the delivery closer to business expectations.
In my twenty years of career in delivering software development solutions from offshore, I have observed some common delivery challenges trends. Gap between client expectations and delivery is one of the prime. Interestingly some teams do well and some don’t. Even a change in a team structure can impact the gap between expectations and delivery. Isn’t this puzzling? I collected some data around team experience, expertise levels, performance metrics, team and compositions. And then compared these attributes with gaps in delivery versus client expectations.
Software Development: The Art-form
My root cause analysis of this issue narrowed down the cause ‘Software engineers inability to read the Business intent hidden in the documented feature requirement’. Engineers are primarily trained on the science, technologies and method of software building. They are also groomed on mathematics and logical aptitude to look at the technical challenges but one big aspect they miss in their training is ‘The ART of software development’. This seems to be the missing piece of the puzzle.
Software development cannot be treated like a legal compliance process wherein developers just ensure that every word mentioned in the requirement documentation is been addressed in the implemented functionality. Even with all the latest standards of requirements documentation right from using UML to User stories, it isn’t feasible to capture every element of requirement in a documented form. The ‘Intent’ to build the software solution is often ignored as it cannot be documented in as many words in requirements document.
ART is more subjective in nature. It expresses knowledge in the form of subjective representation. It is concerned with aesthetics. It is seen as creative, intuitive, expressive and emotional.
The very purpose of every solution is to address a Business need. It could be a business pain area, business optimization need or business expansion plan. The development team is expected to read these ‘between the line requirements’ to address the business problem. They are expected to think intuitively to get into end users shoes and look at the problem and build aesthetics, usability which will ensure an enhanced user experience. This is over and above the expected functionality which is been documented.
To some engineers it comes naturally and hence we see this perfect marriage of expectations and delivery in few teams. It is more person dependent success. Can it be imbibed in the development executive framework?
I tried an experiment. I developed and followed ‘A Business intent driven development (BIDD)’ model. I just introduced couple of more basic steps to the SDLC as below.
Business intent driven development (BIDD)
The framework ensures that the intent of requirements is discussed and agreed upon first, and then the team walks thru the requirements document to understand how the business intent will be achieved using the feature recommended. Understanding persona of the end user is also a critical step. The persona is considered in UX implementation plan of functionality. The intent and user persona are documented and are critical part of acceptance test criteria. This BIDD process plug-in was successfully tried in both Waterfall and Agile approach.
Here are some observations of the team performance which adopted the BIDD approach
- Team did consistently well in meeting Business expectations over a period of 3 months cycle.
- It helped in building a One Team culture between Business and Development team. Development team could come up with valid Business suggestions.
- Achieving the Business goal got the highest priority against implementation of the documented requirements. At few times development team recommended some interesting Out-of-the-box approaches to address the business issue.
‘Understanding the intent rather than going by the action’ was a simple change in the approach that we followed and the results were impressive. It is indeed a common sense approach. Human psychology cannot be ignored even in virtual world. After all ‘Software is built by humans for humans, for humans to use’