The hand-over disconnect

The feature request is ready for development. In your role as a solution architect, you get the question from the project requesting the feature to produce a ball-park-figure time estimate. Personally, I am not a big believer of time estimates, but that’s beside this story. As you read the documentation of the feature, you feel there are some things you need to clear out. There are questions to be asked. “After the user has done step 1, but before the system has processed it in process B, should the user be able to do any changes to the input?”. “What happens if process B fails to access the external resources it needs to do its job?”. And so on.

These questions will always need to be asked along the journey from an idea to a piece of software that can be used by actual users. However, more often than not, in my own experience, these questions are not asked until after the requirements and analysis process is considered to be completed. Lots of time has been invested in producing documents outlining the feature, giving background about it, defining the processes and rules of it. And then it’s handed over to the IT organization for development where the more technically experienced persons dig into it, and these questions come up.

This is not strange in any way. I don’t expect a person without software development background, but with deep knowledge about the business domain, to be able to foresee where in the feature that there are technical challenges. That is not their expertise. It’s completely natural that business domain experts don’t include all sorts of technical mishaps that may occur when this feature runs as actual software.

What I do find strange is that many organizations still are divided into “the business side” and “the IT side”. As if they are two different things. Here is the thing: they are not. They are both parts of the same machinery, and they are dependent on each other. It’s a symbiosis, not a unidirectional chain.

If you have a hand-over as part of your working process, chances are that there will be a lot of time wasted around that point in the flow. Business analysts feel that they are ready, and they hand over the feature. The technical folks will look at it and say, “hey, what about….”, and toss it back. Then it goes back and forth over the divide until both sides are happy. Not until then it can move into development.

If we are lucky, the technical challenges that are detected at the hand-over point are small enough they can be ironed out by just getting some clarifications. If we are less lucky, the feature as a whole is designed in a way that makes it more or less impractical to develop at all. That is where the real money wasters are.

What baffles me is that so many organizations still work like this, when the solution is so very simple. Include a technical architect in the analysis phase right from the start. That person will be able to put their finger on potential problem domains from a technical point of view. Hopefully they have an idea about general architectural goals for the organization as a whole, and can help shape the feature to fit into that map, right from the start.

You can think of it as pair programming for feature work. It will most certainly, if not completely remove at least shorten the time spent tossing questions and answers over the business-IT-divide. Perhaps, if you have employed the right persons, the divide will vanish altogether.

Because in reality, there is no divide.