Refocusing Technology

Technical People vs. Business People September 11, 2008

The Issue

I have heard and seen so many stories that say “the IS department at our company can never get anything done” or “the users don’t know what they need”.  It is at epidemic stage at many businesses.  At many companies it is an us vs. them idea.  This is extremely sad due to the promise that technology can hold for optimizing the work and business environment.

Typical Scenarios

Why does this happen?  I would say the biggest reasons are: communication, time, and understanding.  Those three items are a triangle.  In many businesses the timeline is set long before anyone spends any time fully outlining the problem.  So by the time that the business unit and IT get together they are already behind the “eight-ball”.  So they limit the communications to a few meetings to describe what the business is looking for.  Many times the business unit doesn’t have the time or the training to create specifications so they leave that to the IT staff.   The IT staff doesn’t have the business training to fully understand what they are being told and what the business unit is trying to do.  So by intermixing lack of time, lack of communication, and lack of understanding the specifications are not complete and quite possibly not correct.  Since the business unit does not completely understand specifications they may think that it is complete and correct.

Once into the project, the business users are now able to see what is coming together and find that it is not what they need or requested.  At this point, there are discussions of what needs to be changed. 

When that happens, there are two routes that are usually pursued.  First, the technical people will have a problem with the change because their solution is “to spec” meaning that it meets the written specifications.  This causes there to be discussions of the specifications being incorrect and many times finger-pointing ensues.  The second possibility is that somebody will just say “fine, we’ll change it” without altering the specifications or understanding the complete scope of the change.  In this scenario, many times changes start to be made without control which causes more issues and more fixes.  This can turn into the “black hole” project.

So what do we do?

Both sides of the equation need to understand that there is a knowledge gap.  The business unit will not typically understand what the technical people are asking/meaning because they are not trained how to develop solutions or even how to do analysis.  The IT staff will not typically understand what the business is asking for and why they are asking for it.  You really need to have one or more people that really understand both sides of the game.  There are a few solutions that I can think of

Business Analyst

In some cases, the solution is a business analyst.  This is a good solution as long as the person understands both sides.  This is a good solution as long as they can understand both sides.  This can be difficult because if you bring an outside analyst who understands analysis they may not understand the business or IT.  If you use and internal business user who really understands the business may have a tough time communicating it to technical people and may not understand how to do the analysis.  If you use a technical person, some of them may not be good with the business and/or analysis.

Education of resources

Some companies will have both sets of resources to spend time with each other to understand what each other does.  They may also spend the time and money to help both sides understand how to do analysis.  The developers will spend time learning how the business runs and the business will spend time learning how the systems will operate.  This can be a great solution.  It can also be time and money intensive.

Solution Architect

This is the term that I use for someone who has the education and ability to do analysis, design and development of the system.  The advantage to someone like this is that they have the ability to work with the business users to do the analysis.  The same person has the ability to architect and design the solution that will solve the problem.  They may even be involved in the development effort.  The advantage you get with someone like this is that less will get lost in translation.  The only thing that the solution architect will need to do is spend time to learn the business process.  This can be done by having that person spend time with business users or maybe even train and allow them to do the job.  This is a process called shadowing.

In many cases, the solution architect has the ability, knowledge, and experience that comes with doing this process many times so they know what they are looking for and really how to learn from what they are watching.  They then will have the ability to analyze and document the process.  From that they would come up with a proposed solution and design and architect it.  This will allow the developers to understand what is being built from a technical aspect.  This allows one person to translate between business and technical people.

Final Thoughts

As I said, it is sad to me that so many IT projects have issues due to timelines, miscommunication, and misunderstandings.  If companies and people will begin to put people in place that can be the “translator” between business and technical jargon, I think more companies will realize the vast improvements that technology can bring.  It really shouldn’t be “us vs. them” it should be “how do we solve this issue?”.  Honestly, in some cases they speak different languages so in turn they need a “translator”.