Placing the “Why” in the Center of Digital Software Engineering
Digital transformation is about solving problems from the customer’s perspective, outside-in. The problems are typically in the areas of functional capabilities, customer experience, and speed to deliver new products and services. Additionally, digital projects must solve these problems in a way that counters asymmetric competition. It needs to offer the solution in an as-a-service model that is scalable both up and down. Defining and framing the problem is the “Why” that must be put in the center of digital software engineering.
How have we missed the “why” for so long?
Modern software engineering methodology usually starts with the requirements phase. Whether Waterfall, Agile, XP, DevOps or RUP, software engineering methodology starts with the notation of Requirements in the form of use cases, storyboards, and test cases. A successful software engineering project is often defined as meeting requirements on-time and on-budget. In practice, success by this definition can be significantly different than solving the real business problems, thus we run into projects that passed all the test cases, yet customers are unhappy with the outcome. Modern software engineering originated from an era when the majority of the IT projects failed. The core ideas of software engineering is to leverage the best practices from the other engineering practices, in layman’s terms, “stating what you want to do”, “writing down what you just said”, “executing what you wrote down”, and “validate and verify that what was executed matches up with what was written down”. Anecdotal evidence suggest, as an industry, we have been wildly successful. Just two decades ago, more projects failed than succeed. Today, by the definition of meeting requirements on-time on-budget, I routinely witness greater than 95% of projects succeed.
What are the problems of requirements-centered approach?
The requirements centered approach comes with several significant constraints for digital projects:
1. It encourages inside-out thinking: requirements are typically provided by seasoned analysts who have lived “in the box” for the last 10 to 20 years. Thinking outside-in is nearly impossible when you have lived “in the box” for so long. ,
2. It limits choices and creativity: often, requirements are prescriptive based on past best practices. It limits choice and discourages creative thinking. For example, the classic Master Detail screen layout is so well established that many analyst would describe use cases and story boards automatically following this pattern, when in reality there are now many more productive screen layout options available.
3. It sets the scope and encourages complexity: U.S. spent millions of dollars to develop a ball pen that can meet the requirements of maintaining ink pressure in the space so astronauts can write with ball pen in space. The Russians didn’t have the resources to spend on such an expensive ball pen. They simply had their astronauts use pencils. A lot of IT requirements are written in such a way that end up solving too many problems, yet missing the mark on solving the real problem for the customers. After all, most companies don’t have the technology resources NASA has.
How do we go from requirements centered to problem solution centered?
We place the “Why” in the center of Digital Software Engineering, starting with a dedicated project phase to defining, framing and sharpening the problem statement. We recently completed a legacy application transformation with this new approach. The results met the unarticulated needs of the business by solving the essential business problems. Here is how we did it:
1. Problem Definition - 3 weeks: the goal is to sharpen the problem statement down to a small paragraph, from the customer’s perspective, that is specific and tangible, without being prescriptive on the solution. The steps are defining, framing and then sharpening the problem statement. Part of this exercise is to develop consensus on who the customers are and the interaction personas.
2. Solution Challenge – 2 weeks per iteration, 2 iterations: we received 50 solutions in iteration 1. We then down-selected 10, refined our problem statement, and executed the second round of solution challenge. We also provided detailed commentary on the pros and cons of each solution to guide the solution challenge in the second round.
3. Down-select the Solution, Award and Optimize – 2 weeks: we down-selected the final solution, provided the financial award to the winning team, and then engaged the winning team to optimize the solution to the specific business and IT context so to reduce the integration complexity and business change.
4. Execute per DevOps: At this point, we would essentially treat this as a regular DevOps project. The key difference is from business to IT, we are now truly one team sharing a common vision of the problem to solve. Requirements and Design activities are significantly accelerated, generally cut down by 50%. We also ended up with a set of newer technologies (e.g. Angular on Linux) that we would otherwise have not considered to execute the chosen solution.
In retrospect, we would have never imagined there are so many solutions out-there to the business problem we faced. The requirements business asked turned out not to be what business truly want, once we get into the problem discussion, i.e. the “why” of the project. When we defined and sharpened the “Why”, the “How” and “What” became much easier and faster.
To solving digital problems, we must place the “Why” in the center of Digital Software Engineering approach. Today, DXC has industrialized this problem solving capability at scale. We call this offering “Rapid Digital Delivery”.
I serve as a strategic advisor to help Salesforce clients realize the value of their Salesforce investment
6 年Thank you for sharing your insights, John! Thinking outside-in is so crucial especially now where industry boundaries start to blur. Digital software engineering is more successful when organizations can harness the power of the external collective genius, as no one organization can do it all.