Looking at the history of software engineering, it is interesting to see its evolution. It all started with a pretty basic ‘writing programs’ that did perform some (hopefully functional and useful) tasks. Quickly, it appeared that happy nerd-driven programming was insufficient for addressing more serious functional problems. Hence, a proper software engineering process was established. Requirements engineering was born as a key element of this process. And so the profession (or a role initially) of a requirements engineer or manager. Requirements engineers were expected to be very much technically skilled. It was because they had to specify those complex software systems. At that time, this skill was on the verge of black magic. Moreover, requirements engineers were also expected to know something about the domain the system was being built for. Subsequently, the requirements grew beyond functional and included non-functional elements like performance or user-interface. Somehow, this was still not enough to address the complexity and growing expectations for complex computer systems.
The next phase of computer systems evolution pushed expectations even further. Technology was to support key business processes. Technology was to become an element of key competitive advantage. Requirements managers not only had to have technical and domains skills (and of course ‘user-understanding’) but also business process and strategy understanding. The demands were growing and the profession even changed its name to business analysis. Business analysts were expected to be software engineers and MBAs at the same time. Their job was to crack down business problems and translate them into supporting IT systems. As a matter of fact, we are still stuck with this pretty rigid business analysis world. The demands for business analysis have perhaps been a bit unfair. Analysts are expected to combine natural sciences (math, like in computer science) with social sciences (management) and still define almost error-free solutions. We all know this ‘almost’ is actually ‘never’. As a matter of fact, with business analysis, management consulting was to some extent combined with requirements management.
And now we live in an era of ever growing consumer and business expectations towards technology. Problem solving expectations of businesses, experience expectations of consumers, expectations of intuitiveness and speed, expectations of performance. Arguably, these expectations cannot be met with old means. Neither requirements management nor business analysis alone are sufficient to cater to those high demands. It is like we have the science, we get the business but we need … some art? Well, it might be very much so. Perhaps a little more disciplined. Simply design thinking. Wait a minute, so this is the third element: we’ve had technology, we’ve had business and we have … design. Notably, we’ve had requirements engineering, we’ve had business analysis and we have … business design. Wow, who wouldn’t like to be called business designer?!
I argue that this combination might yield the best results and has the highest chances to address the toughest challenges. And I also argue, this is a rare combination requiring wearing 3 hats at the same time, continuously juggling with them. It requires 3 different mindsets at the same time! Having all 3 is and will be rare. But not impossible.
I reckon the sooner you realize this and the sooner you acquire the necessary skills, the more successful you’ll become. The most important and the most difficult skill is the mind-switching. Never stay too long in your engineering hat, never stay too long in your analyst hat and never stay too long in your designer hat.
Just to remind how design-thinking angle enriches the perspective (key tenets):
-Focusing on a problem (vs a solution)
-Finding the right problem
-Ideation and creativity
-Asking WHY (vs WHAT and HOW)
Design thinking by its constant divergent and convergent thinking modes helps you explore both in identifying right problems and possible solutions. Business designers’ job is not to specify anything. It is to address and solve problems (when they can be solved). You might want to read a very interesting book by Roger Martin called The Design Of Business.
To make it less abstract, let’s look at an example. Company A’s management prepared an RFP to build (or purchase off-the-shelf) internal communication tool, something like Yammer or Slack. They identified lack of internal communication and lack of sharing ideas as hampering their business. The thing was, they did specify the solution (application required) without deeper understanding of the roots of the problem. Requirements engineers would rush immediately to answering the RFP specifying how great their systems are and how great they would exceed customer’s expectations (so many great features that in 10 days, the company would unlock its great business potential). Business analyst would certainly go further and see (and specify) how this new application would fit business processes and how to would enhance business results (for this additional analysis might be needed).
What would business designer do? They would ask: why do you have those communication problems. And they would keep asking WHY until they found the problem (or perhaps several). And they could have e.g. identified management culture filled with fear as one of the main contributors to the symptoms (poor communication). Subsequently, they would rush to quickly experiment with non-technology solutions like e.g. a program where the CEO speaks to 8 employees a week (randomly) guaranteeing them the conversation would be private, anything can be said and no consequences would ensue. And there is no guarantee the right solution can be found but experimenting is a fact-based method to check what works and what wows (check this from Jeanne Liedka and Tim Oglivie). And remember the original assignment? Well, no penny would likely be spent on any app but the customer would certainly value your approach as the most likely to result in a great solution.
And yes, you there will be many rushing to push their solutions. Short-term thinking and greed (unfortunately) will help them ‘justify’ their actions. Notably, fooling the customer will backfire some day (we have all been there, haven’t we?). And yes, company A’s executives will push for the specified solution in hope of defending their jobs through unnecessary complexity and traditional supplier management approaches. And that will backfire too. We are all really better off with true and authentic problem-focus. I can guarantee our lives, both professional and personal will be happier.
Business designers, the floor is yours!
Care to comment?
Digital Innovator aka Dinno