jump to navigation

Technical People vs. Business People September 11, 2008

Posted by Jeremy in Business Solutions, Development Process.
Tags: , , , ,
add a comment

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”.

Business System Analysis September 3, 2008

Posted by Jeremy in Business Solutions, Efficiency Process.
Tags: , ,
add a comment

Business Systems

My belief is that if every company focused on building a system (a business system not a software system) to do their business they would be vastly more effective.  A system allows for things to move along in a very uniform pattern.  This makes things easy to deal with and conform to a set of standards.  It makes it very easy on employees and also makes it easy to train someone new coming in the door. 

It takes a significant amount of time and effort though to define your business system or process.  It follows a simple set of steps but they can definitely take time:

Step 1: What are the current process steps and Why?

This sounds like a simple task but in many cases it is not as simple as it seems.  In many cases there are multiple people who do the task and not a lot of process documentation to outline how it’s done.  Also, many times no one will really know why a certain task is done the way it is.  Many times this is due to the fact that it has been passed down from one employee to another and the reason may not have been passed.

**NOTE: In this step, the answer “Because that is the way it has always been done” should not be acceptable.  You should strive to have a true answer to Why or realize that the step may need to be looked at.

This is a very important step.  It is very important that the proper amount of time is taken to truly understand the current process.  Only if this step is done properly can the rest of the steps come out correctly.

Step 2: Is there a better way to do the task and does it need to be done at all?

This step can be difficult and needs to be handled gently.  You definitely don’t want to make this an interrogation of the employee.  This should be a very open, honest brainstorming session.  This is where the process refinement comes into play.  The people involved in this discussion should really consider better ways to do the task and also consider if there are ways to not do the task at all.  This is where you can get rid of the non-essential tasks and bureaucratic red-tape if possible.

This is also where there should be discussions of how to automate certain tasks.  In many cases, if there are specific steps that have to occur each time and they are pretty reproducable a software solution may be able to help simplify the the process.  This is something that you should discuss with a solution architect to figure out if automation processes will be applicable and feasible for your process.

Step 3: Revise process

The process should now be written in a draft format and reviewed by the members of the process team to verify that they will work.  During this process you may find that you will go through Step 1 and Step 2 multiple times to further refine the process.  This is fine because your end goal is the definition of an efficient process. 

At the end of this task, you should be very comfortable with how the process works, why each step occurs, and where the improvements will happen.  This will allow you to move on to the next step.

Step 4: Document the process

It is just like they say in the legal field, a oral agreement is as good as the paper it’s written on.  This information needs to be documented.  Each step in the process should be outlined as to who, what, why, where, and how.  Everything about the task that is known should be documented.  This will make it easy in the future when you need to train someone else or when you have to go back and look at why a process works a certain way.

During this step do not tie tasks to a specific person tie it to a specific role.  Over time people change roles so the documentation will lose some value.  If you outline the role that should do it the documentation will transition much easier from person to person.


This process is by no means simple and it will be time consuming but it can produce lasting benefits.  Many processes are defined and then never looked at again even though circumstances and resources change.  Many companies will add new customers, products, and resources yet they don’t consider looking at their process to see if it can and should be changed to support the new requirements.

Even though this task may seem daunting, it is something that will pay off in many ways once completed.  It gives you an outline of what you do and why you do it.  This information will help everyone understand the process and do it as efficiently as possible.  It shows you where you can improve and allows you to remove aspects no longer needed.  The bottom line is that it can and will effect your bottom line.