When we see how the modern world is changing rapidly, we may notice that some old processes and approaches don’t work in the contemporary environment anymore. It’s not a surprise that techniques that used to work in the past are failing now. It doesn’t really matter if we speak about IT, finance, or any other branch of the economy as only a few resisted changes and the processes are the same now as they were in the past.
Management issues – high risk in IT projects
When it comes to how we perceive different things, we may, and we will see differences. Even the simplest things described by two other people may result in a different outcome in their description. There is no difference between “IT vs Business” and “Business vs IT” as they adhere to the same rules as everyone else. From my experience, the two images the other side in a peculiar way. When tech guys have to describe Business, I’m pretty sure they’d use words like „stubborn”, „they have no idea what they want”, „they don’t know how hard it is to do sth in software engineering”, „they always think they’re right”. On the other hand, if you’d ask business guys to describe the other said, I’m almost certain they’d use such words like „stubborn”, „they think they’re better than anyone else”, „they don’t understand what we need”, „they live in a basement”. Ok, sorry, I completely made the last one up 😉
Is there anything wrong with some assumptions we use to describe the other group? Not unless it is accurate and not falsifying the reality. Those examples I’ve given were real-life words I’ve heard at least a few times. Such words hurt – and I don’t mean the personal feelings of the described person/group. It hurts the producer of those statements, as they think they are better. In the end, it builds walls that prevent both sides from getting to the same page. So the next time any of you tries to use such words, think again as you may be building a higher wall that won’t help in the cooperation. Instead, think of the way you can help build up the mutual understanding that leads to better project rules and the overall project success.
Who leads in IT project?
Speaking of which – who is responsible for imposing the project rules? Business or IT? As a person with a typical IT background, I’m wholeheartedly on the IT side, but my feelings don’t matter here. Business is responsible for that. You can argue, you can show your point of view, you can even feel resent, but that is the ugly truth. To explain, I’ll refer to DDD and event storming sessions along with ubiquitous language. Why all of these are defined and should be strictly followed? Because IT departments were built to help Businesses achieve what they want and need. IT is a tool in hands of a Business the same way a hammer is a tool in hands of a construction worker. I’m unable to think that a hammer imposes different behaviour on the worker. You?
So what are the main reasons why conflicts occur and why do projects fail? Inversion of roles. The hammer steers the worker on what has to be built and the way how it is used. A lot of IT guys are cranky, often lazy, and think they are ruling the world. And they poison others as they build those walls that separate them from the outer world. To be less abstract, they tell the business guys that they provide the wrong requirements but they don’t explain how to do it in a better way so they could understand. Or they say that something is impossible just because it requires a lot of changes in the existing system. There is nothing wrong with changing a solid portion of the system if it is really required! If you’re unsure that it really has to be done this way, maybe ask better questions so the business can deliver better descriptions of what they need and why. Then, maybe a better plan can be created.
IT management done right
Now we’re getting somewhere. Questions. Answers. Communication. That’s the foundation of each and every project. Everyone knows that but only a few really follow it. Think about two hypothetical companies:
· one is having the IT department imposing rules and pushing the business to „do their job better because IT doesn’t see a value or understand it”;
· in the other one the IT department asks questions when the business guys come with a new requirement and change.
I know for sure the latter company achieves the same task faster, better, and in a way cooler environment. The first company will bother with something I call a ping-pong effect. The business asks for something from the IT department and they don’t a) want b) know c) like the idea so they’re ponging back and they blame „insufficient requirements/description”, „unable to change the whole system in a reasonable time” or else. Then business changes their approach or requirements and the whole process starts over, but it takes time as they have to shape everything as „the IT guys want”. At the same time the other company, during one meeting with IT and Business establishes a connection, asks questions and gets most of the answers immediately, and knows how to shape the system to fulfill the requirements. Just because they know they are there to help business and not the other way around.
A good link between those two departments has always been the most important thing in every project I have taken part in. In DDD communication, maybe not completely directly, is considered the most important thing when it comes to delivering projects. I add to that by being humble, not being cranky, and trying to understand the business guys by using something very sophisticated that is called: questions. If you don’t understand, then how do you want to implement it correctly? If you don’t understand, then how can you even start your work as it will have to be corrected sooner or later. Ask questions as they work as a manual for the hammer. This is the way you’re instructing the construction worker on how to use the tool. I know the comparison to a tool isn’t the most pleasant but it describes our responsibility 100%. We are for them, not they are for us, even though, they can’ accomplish their job without us. Just be for them.