We often tend to identity reasons of failed software projects with "cost-overrun" , "time-overrun" or "poor quality". 

A few years back, during conversation with a dear friend, who also happend to be my client at a major investment bank, I was struck hard by his thought on the subject, which still continues to be my guiding mantra. He had said - "most projects don't fail for the above three reasons (which are essentially the consequences of failure). But just for 2, and they are :
ONE) "An idea that is bad" or
TWO) "An idea that may be good, but which is not articulated well".

The key is in striving hard to bridge these gaps, and one such way is to ensure that people who are responsible for eliciting and defining requirements learn the skills of doing it well which essentially comes from the art of COMPUTATIONAL THINKING....

=======================================================

In today's fast-changing world where technology is playing a key role in most aspects of work and life, it is increasingly clear that we need to be able to think critically and be able to resolve complex and not-so-well defined problems, to truly thrive in an environment where we are expected to ideate, conceive solutions and articulate well, rather than just being excellent executioners. But while few would argue against the utility of teaching critical thinking and problem-solving skills, there is less consensus about how to do it, or what levers to use when acquiring this extremely important competency.

One approach to acquire this skill is to train our minds on computational thinking, because it not only teaches as how to think critically but also helps develop and deploy strategies for solving problems by making granular assessment of the issue in hand and take a step-up step approach to define the solution.

The intellectual core of computational thinking is about formulating ideas with enough clarity, in a systematic way, so that from that point forward systems can be built. Or more simplistically, it is the process of breaking down a complex problem into easy-to-understand parts, and then stitch them together to articulate the need.

What got me to realize the importance of this discipline early in my career was when, as a functional consultant, I was thrust to be a part of an extremely complex project for a major financial services data provider, as part of which we were modernizing a fund analytics platform by re-writing its code from a legacy technology to a latest stack (of that time). While I was called by my department head to be part of this project, he explained that the engagement was in a crisis as most of the deliveries from our offshore centre were not meeting the requirements because of which quality was perceived to be bad, sprints were delayed and there was a cost overrun already. If we didn’t fix the issues from the root, the chances were that SLAs would be invoked and it could then end as a failed project. The task given to me was to go to the client’s site in London, do a root cause analysis, identify the issues in hand, fix them and turn the program to green. A daunting task as it seemed at that stage, and as much as I was anxious, it turned out that during the next few months my learnings from this project as a domain specialist would improve many folds, from the journey I would take to try and find the real causes of failures and how I would fix the issues going forward !

The claim of our offshore technology team was that “requirements were never right”, so while they would code what they thought was asked to be built, when it came back from UAT at the end of every iteration, changes were too many. A classic software development problem as it seemed from the face value.

As I started working from the client’s site, I soon realized that I was amidst the best of the think tanks in one of the most prestigious financial firms who knew their business from the roots. While application’s purpose was to churn out charts, graphs and many other statistical attributes from underlying data related to funds and their asset holdings over a time scale, these experts in the bank would consume the outputs and were some of the best in the industry to derive the right meaning from such statistical measures with years of profound knowledge and experience and there was little doubt therefore that they were the best people to give the technology teams the requirements.

So where was the problem? As it turned out while the business experts were the best breed of individuals to study and derive the right set of results from the output, they were not the right people who had the capability to decompose these complex statistical measures to the lowest level of granularity and articulate well in the form of functional specifications which could then be used to design IT solutions. As a result, what was being given as requirements were – “what needed to be done statements”, and not "decomposed requirements explaining how it needed to be done", with enough clarity, in a systematic way, so that from that point forward design and coding could be executed without ambiguity. In other words - the missing link between requirements and execution was computational thinking. To explain this further with an example, if a bell curve representing distributions of monthly returns was an output desired, the requirements were never decomposed to an extent detailing the right sources of data, types of prices (close, average, mid) to consider in the calculation of returns, the frequency intervals etc. The consequence was that much of these were assumed at the time of design and development resulting in gaps between what was expected and what was being developed. Multiple this issue a 1000 times to so many, much more complex algorithms being developed, the problem was humongous.

Though I was not, at the time, trying to corelate this inability to articulate requirements well for software development with any academic discipline, nonetheless I could associate this as an issue related to “system thinking”. I was quick to take the ownership to fix this gap without resting the blame on any entity. I realized that not all people good in their respective genre of work may also be able to decompose and articulate problem statements to the lowest level of granularity which can aid software design. It’s an art that comes from a convergence point, where our artistic right brain communicates with the logical left brain, and which is what all business analysts, domain consultants, functional experts or solution architects must strive for.

The Art of Computational Thinking - There is an increasing realization today, that computational thinking is rather an art than just applicable knowledge-sets. A skill that is characteristic of an ability that is acquired over time and experience. It’s not knowledge of facts or information. Many of the routine tasks that are done every day are probably done within the bounds of a process and knowledge acquired, which do not often need critical thinking. It is only when someone is asked to do something new that one really has to think to solution and think to build. Building a product or designing a solution is an outcome of critical analysis and organized thinking skills that involve many aspects which are largely contextual and can come only when a person's mind is grooved to the art of computational thinking.

I am often asked as how is computational thinking different from scientific thinking or design thinking – They are different because while computational thinking helps decompose a problem statement to arrive at the right proposed solution, scientific thinking deals more with forming a hypothesis to test and prove or dis-prove the same. Design thinking on the other hand is a tool used by designers and engineers to design solutions and experiences. In summary – to be able to successfully execute a scientific project or a design thinking project computational thinking skills are a must. The foundation rests there !