Disruptive innovation is a trendy topic in economy and management. Even if Clayton Christensen, who coined the concept, meant it in different way to how it is now used in many places1 – it also had its effects on IT analysis. Innovation is expected from the solutions that we, as IT analysts, design. An IT solution that is nothing more than a copy of the old system in a new dress is rarely accepted. But how does innovation come into the solution? Are the current processes of requirements engineering enough – or do we need new ones?
Flashes of inspiration as the source of innovation
Have you had a flash of inspiration before? I mean the moment where the solution is clearly right in front of you, the solution to a problem that you have been laboring over for hours – or maybe even days – without results. And I am not just talking about IT here. It can also be something as seemingly banal as planning a holiday with a big family with different interests. And then it suddenly appears – the destination that has something for everybody.
Such a flash helps, of course, with lots of other problems. Questions when building a house, technical questions, the content of an article for the microTOOL blog.
The first historical person who was hit by a flash of inspiration was Archimedes of Syracuse. The legend says that King Hieron II suspected his goldsmith of having put too much silver in his new golden crown, so the king gave Archimedes the task of finding out how much silver was in the golden crown. We can assume that Archimedes spend hours in his study ruminating over how he could solve this task. After a while he probably wanted to have a break, relax. He took a bath. And because he noticed how the water in the bath tub flowed out when he sat in it, he had the flash of inspiration that we now call the Archimedes principle. He is supposed to have jumped out of the bath at that moment, naked, and shouted “Eureka!” and run through the streets.
This pattern – a flash of inspiration after intensive preparation, when you no longer expect it – has been formulated into a creative process by many different authors. One of the first was Graham Wallas, who summarized his observations of the German physicist Hermann von Helmholtz and the French mathematician Henri Poincaré into a systematic theory of creative thinking2. According to his theory, creative thought takes place in four phases:
- Preparation: Here you are intensely occupied with the problem, collecting information, assembling knowledge. Even Archimedes would have thought a lot about how he could have established whether the crown of the king was really made of pure gold.
- Incubation: Here, you let all the information you have collected in the preparation phase sit. You do nothing, relax, occupy yourself with something else. If you are like Archimedes, maybe you take a bath. Your brain is still working.
- Illumination: This is when Archimedes’s Eureka comes. The subconscious did its work. The elements that were appropriated in the preparation phase have been rearranged and the solution comes into the consciousness.
- Verification: People probably have a lot of flashes of inspiration, but the ideas have to be proven. But they can only really be confirmed with a confrontation with reality – or maybe not. That is why Archimedes probably ran back to his study – naked, as we know – to verify his brainwave through experiments.
How can we learn from that for our work in IT analysis? Is there also room for this creativity process in the procedures of requirements engineering? Let’s consider the main activities of requirements engineering as they are formulated in the course plan for the IREB-CPRE exam3:
- Determine requirements
- Documentation of requirements
- Examine and confirm requirements
- Manage requirements.
Where is there room here for creativity? Can the four phases of creativity be accommodated for here? Documenting and defining requirements – that doesn’t sound like a creative process. But you can’t be unjust to classical requirements engineering. There are already the creativity techniques, like brainstorming, or the six thinking hats. And there are also the excitement factors of the Kano model.
And despite that – if we wanted to come to creative solutions, then we will have to further develop the procedures of requirements engineering.
The process of IT analysis
So where does creativity fit into IT analysis?
The aforementioned creativity processes have to have a place in IT analysis. For this purpose we will suggest an analysis process – let’s call it system analysis 3.0 (link in German) – with three main activities:
- Analysis: forming the available information into a solution design.
- Communicating: information will be collected from the stakeholders and the solution ideas of the analysts will be coordinated with them.
- Producing: the necessary artifacts for development that describe the solution design will be created.
Let’s get into more detail about these main activities:
Analysing is the part of the analysis process in which the available information is formed into a solution design.
The first step of the creativity process according to Wallas is preparation. James Webb Young divided this phase into two phase parts: the collection and processing of raw materials.4
The analysts are occupied with the following questions, for example:
- What is the task of this field? Why does it exist?
- What are the essential objects and concepts?
- Where does this information come from? What are the interfaces to other fields?
- Which other fields build off the information to be processed?
- How does this field work? What are the rules?
- What should the system in development achieve?
That is a completely different approach than just defining requirements. Here it is not about just asking what the others (stakeholders) want from the system. It is about plunging into the work of this field and its rules.
The information sources are diverse: according to the area it could be specialist books, or different records. The stakeholders are of course also a source, experts in the field. But here the first priority is not to collect requirements but to build up knowledge, although these tasks will overlap in many ways. This knowledge is the raw material from which our system will be designed.
“Creativity is just connecting things,” according to a quote from Steve Jobs. The compiled raw materials, then, need to be newly connected. For that, the analysts have to play with the material, try to assemble the individual elements in a new way. That is done in constant agreement with the stakeholders. So it’s not just collecting the requirements from them – different solution approaches also have to be agreed upon.
When working on raw materials, problems can be met. The individual elements might not fit together like the analysts wanted them to, maybe there will be contradictions between what the stakeholders say and what they want. So let the task sit for a bit, let the problems sink into the subconscious, and let the subconscious do its job. The everyday of the project seldom allows us to take baths during work time, like Archimedes did. But one definitely has the opportunity to dedicate time to other work whilst your subconscious does some troubleshooting.
After some time has passed, your subconscious will make contact again – with completely new views, with a flash of inspiration. Of course it won’t be so spectacular that it will be spoken of in thousands of years, as is the case with Archimedes. But it will be an idea, maybe for an optimal data model, and interesting variant of a process, an innovative user interface or something else.
Not every flash of inspiration is a good idea, nor are they all achievable, and the stakeholders don’t always agree on them. Finding out is the task of the verification phase. On one hand, lots of communication is important here, on the other hand it is also backbreaking work to express your flash of inspiration in a way that others can understand.
Communicating is the second main activity in our analysis process. Unlike in classic requirements engineering we understand more here than just making requirements. It is on one side the collection of knowledge on an expert area and on the other side the confirmation of our ideas, especially after the (hopefully reached) Eureka in the illumination phase.
At the beginning of the third main activity of the analyst process, production, the solution is pretty much already finished. Now the artifacts will be produced that are necessary to implement the drafts – data models, process descriptions, screen designs. Of course, there were also a few work papers that were discussed with the stakeholders during the analyst phase. But the final document is produced here.
The reason for that is that it is a lot of work to draw a process model – or a data model. And if you have invested lots of hours in it, you don’t want to change it. So then you lose flexibility, and flexibility is the basic prerequisite for creativity.
Updating the old solutions with new robes – or true innovation? The decision is for the IT analysts. So that innovation in IT projects is possible, the analysts have to be able to perform more than to just pick up and manage requirements. The analyst has to become a creative designer.
But the prerequisite for that is to give the IT analysts process room for required creative processes. The procedure we have suggested, which we will call system analysis 3.0, unites the necessary attention to requirements of the stakeholders with the creativity process as it was described by Graham Wallas.
We have summarized the basic principles of system analysis 3.0 in our blog: (German only) http://blog.seqis.com/systemanalyse-3-0/. If you have questions, we will be happy to hear from you: (German only) http://www.seqis.com.
: Christensen, Clayton: What is Disruptive Innovation? In: Harvard Business Review (https://hbr.org/2015/12/what-is-disruptive-innovation)
: Wallas, Graham: The Art of Thought, New York 1926
 IREB Certified Professional for Requirements Engineering – Foundation Level – Course plan
: Young, James Webb: A Technique for Producing Ideas, New York 2003