Everyone who worked in corporate, recognized, that there is a huge gap between business and IT. The gap is because the world, and especially technology has gone with specialization so far, that the business people doesn’t know what IT guys are saying, even why do they say so much, if in their private life, people around them can handle technologies much more easily, than in hundreds of MDs.
There are several aspects of this topic, so to not overwhelm you, let’s focus on the communication and common language first and I will focus on differences between business and IT processes later as well as different yearly goals of these departments.
Capabilities
We will start from the top-level business. Imagine we are one of the top-guys. On daily basis, we hear lots of ideas, needs or problems from our departments. We need to pack them under a topic. Let’s call it a capability.
Process
Business is working in processes, even if he’s not aware about it, or the processes in some parts are inexplicit and if you want to formalize them, you need to generalize a lot. Each capability can be then described in one or more processes, which defines what’s happening, where and whom should be responsible.
Needs
Each business person (or in each process part), there is always a need for improvement. This is where the gap between business and IT starts. Business analyst (or product owner in agile) should define via business requirements (or user stories in agile) exactly the need for improvement.
The GAP
On the other side of barricade: let’s image, we are the programmer. We were hired to program in one system. We know the code and we can do magic with it, because we spent several years on training and we have lots of difficult certification on how ideally things in IT has to be done. So the last thing we need to get things done, is someone to tell us what to program. Once we have it, we can program literally anything and in few hours.
Now we jump in the office to the CMO and he says, he wants the campaign management. Great! But what does he want me to program? Should I ask him about what fields he will need?
Well, let’s go first a level lower to a team manager and look at the process. This looks better. I know the dataflow, so I am getting better picture about what fields they will need to enter to get their process working. I see the roles also, so, I can setup the access rights. Ok. But how many screens do they want? What do they want on the first one? They will for sure want some colors there. Do they want the system available all the time? I heard also, that they want new PDF forms for operations. Are they aligned in the business? Why does the manager don’t know what exactly do they want? Pfeew. I will wait for the business analyst to tell me what to do!
Well now I have THE analysis. They want me to send SMS? I can program that, but it would not be cheap and we already have system for that. They want me to allow external users to the database? Oh, god, I sense this could be risky and I don’t want to tell business NO. I need some more experts from IT to tell only what tasks should be done by me and handle with the business risky requirements. I need the Solution Delivery LifeCycle and whole IT department to agree on what has to be done! I am scared. And I thought I will program it today and release tomorrow.
So let’s put my legs on the table and rest for a while before it goes through the Solution Delivery LifeCycle.
Conclusion
Hopefully I managed to described that there is no fault on any side. It’s just about communication and missing common language between very specialized people and the others. That’s why things in the company are (ideally) top-down split from capabilities to business requirements and then on IT side ran through the solution delivery process, or in agile way. I will explain in my next blog, why does it take so much time, on both sides, and what steps has to be done to get from these top-level ideas to working solution.
Overview
| Role | Item used (Common / SDLC) | Agile terminology |
| Top-level management | Capability (high-level) | Initiative / Theme |
| Mid-level management | Process | Theme / Epic |
| Business employee | Need | Epic / User story |
| Business analyst (Product owner) | Requirement | User story + acceptance criteria |
| …(whole IT process in next blog)… | …(whole IT process in next blog)… | User story + acceptance criteria |
| Programmer | Task | User story + acceptance criteria |
Game Changer 