I have something important to tell you about the design and development of systems and services.
Which requirements are important
I have witnessed several big shifts in technology and every time there is a strong focus on the emerging technology itself. I see it now again as we help more and more customers into the cloud.
We can agree that technology is important and to choose the suitable technology is vital to system development. At the same time, it is very enjoyable to play around with the new technology to see how we might benefit from it, or even how it threatens us. It is part of innovation processes exactly for those reasons.
But can we also agree that listening to the end users is very important? The importance of user research and user centric design was demonstrated decades ago. Nobody denies the value of user experience anymore. It has grown so big that UX design was separated from systems development way back. It became such a major process that we needed separate roles in projects to deal with it.
But technology and user needs cannot alone define the requirements of a system or a service. Business requirements are as important as the choice of technology and the needs of end users. I have often referred to the user needs and the business requirements as the two sides of a coin; you simply cannot have a coin with just one side.
And not forgetting the organisational part. How the organisation is organised to develop and deliver the system or service. In the methods we use, such as service design and design for omni-channels, we address the organisations role and contribution.
Turns out that this coin of mine has four sides to it… Actually, I would like to see both market and sustainability in this model so that would make a nice dice, but I will deal with that dice model some other time. For now, let’s stick to the four parts as market often is included in the business part and sustainability is dealt with in the organisation part.
Four parts make a whole
It should be obvious that these four components or parts must equally (or at least weighted) contribute to the requirements of a system or service. Right? The total set of requirements is found in the intersection of business requirements, user needs, organisation and technology.
Looking at this illustration you can see that there are different tones of colour. The darkest blue is where all four parts coincide, but the interesting areas are the parts where only two or three parts coincide. If only business requirements, user needs and technology coincide then organisation needs some looking into. This may lead to requirements being forced upon the organisation and we need a way to address this.
When you hire consultants to build a system or service for you — whether it is a developer, architect, project leader, designer or a whole team — it shouldn’t be any surprise that they want to ensure that all of these four requirement parts are addressed properly.
It may be that you have thought it all through with regards to the business aspect of it, but we want to build on that. It may be that you have the user research of another world and have a brilliant concept, so we want to build on that. It may be that you have the best developers in the world, and we want to work with them.
Do you see where I am going with this? We need to take a minute in the beginning of the development of a system or service to ensure that all of the parts of the requirements are dealt with and that all the necessary roles are filled in the project. If they are not, then we must seek to complement the resources and the processes.
Protect your work
And this will make it ok then? Well no, not necessarily. All these processes and methods that we use to define the requirements, we will want to use further to ensure resilience. We want to make sure that the system or service we help you make is resilient to change and crisis. Allow me to explain some more.
One of the components we use to ensure that the business requirements are well defined is the vision statement. The requirements of the system or service should be founded on your vision, strategy and goals.
You have probably seen the illustration from Jesse James Garrett where everything builds upon the layer below.
This is part of the process we use, and it ensures that all the efforts and work to develop a system or service is built on your vision and strategy. Fine, but we also use this after the system or service is released to ensure that all changes, forced upon you or controlled by you, are aligned with this vision.
Why? Because firstly it helps you and your team to pull in the same direction. Everybody knows why we are doing this, so it is easier to lead further development and it is easier to get the good ideas and innovation from the team members.
Secondly, the vision should be wide enough to allow innovation and growth, but still narrow enough to keep focus on why we do this and why it is important to stay on that track. Did Covid-19 change your vision? Hopefully not. Did it change your strategy? Maybe, and your revised strategy still needs to be based on your vision, right? And by changing your strategy you will want to see how that affects the components you’ve built upon this strategy. It will bring control back to your governance.
Are you with me on the importance of this? I hope so. It doesn’t require that much overhead if that is what you’re thinking. It is a small investment you do; it is not a cost.
We use basically six of these components of resilience. Vision is one as you have seen. Another is composure which is more of a mind-set then a process. It is related to vision because it is about resisting that fight-or-flight-response when a crisis or change emerges. Keep calm and save your energy, trust in the vision and strategy you have. It all about solving problems and recognising opportunities. Composure has much to do with the organisation part of the requirements.
Just everyday magic
It is not a secret, it just everyday magic. We like to include this in our design and development because it is so much more rewarding for everyone. Keep in mind thou, this is not an add-on effort by a consultant for a week. It is an integrated part of a process over time.