A young, well-educated, gentleman named Mark joins a firm as a marketing assistant. About four months into the job, he is told that he is being assigned to work with IT on a new project that will help the sales and marketing department. Being on the low-end of the totem pole, he is told that he must participate on the project and ensure that all of marketing needs are met. Mark dutifully attends all the meetings, reviews strange looking diagrams, and corrects any meeting minutes. The project goes in…late, over-budget, with only some of the requirements being met.

About 3 years into Mark's career, he is assigned to work with IT again on a different project. He meets different people, is shown different diagrams, but is still involved in the details of the project. The project goes in…late, over-budget, with only some of the requirements being met.

About 5 years into Mark's career, he initiates a project to work with IT again. He again meets different people. He is told, by IT, to follow a different process than he did during previous projects. He sees different diagrams and must still sign-off on them, even though he isn't quite sure what they are showing. Are his needs being met? Not sure until the end. The project goes in…late, over-budget, with some of the requirements being met.

Mark, now a Senior Vice President for the same company, has touted his success by adding value to the company. He followed orders, worked with different departments, built a strong relationship with the Sales organization. He says he knows the power of technology and how it can take the marketing department further.

But...ask Mark about his experience with working with Information Technology and he will state something like this:

Technology is a crucial part of this company's success. I have no idea how they do the voodoo that they do. It costs a lot and takes a great deal of time to get even one fourth of our needs satisfied.

Why would Mark say such things? IT has always been there to help him! IT has always worked on the projects that he requested. Why would Mark say such things?

It's simple...IT assumes their knowledge is shared by all. We assume that business understands the process and the documents we show him. We assume that business people, like Mark, understand what has to be done and will supply IT the information they need to build it.

Yet, the opposite is true. Individuals like, Mark, are involved in multiple projects over their tenure at the company. During that period of time, IT keeps evolving. IT identifies new processes, procedures, notations, methodologies to follow. Technologists are eager to use the latest and greatest approach that they have learned.

Yet, if you look at the history of success of projects from 1960's to today (40-50 years), projects are still late, over-budget, with only some of the requirements being met. In fact, I've seen figures that the percentage of failed projects has tripled.

Because technologists are so involved in trying new approaches, we forget about the affect it has on the business. To the business community, it looks like IT tries something new, fails, and goes to the next technique.

I'm not suggesting that we don't try something new. All standard methodologies (of course, define "'standard") attempt to improve quality. I am saying that we need to look at these approaches and think about its affect on the business community.

Never assume that the business community has been through this process before. Never assume that business personnel (especially if they have been involved in other projects) have evolved as IT has to be able to try some new methodology.

Think about it from Mark's perspective. Walk in his shoes. I'm sure he was involved, at different levels of detail, in more than three projects. Some may have involved some of the same IT individuals…but that is probably a small number in comparison to the number of other new individuals with whom he had to work.

Look at your own business users. Can you identify how many IT projects in which they were involved? Pick three business users. Make a list of all the IT projects each one has been involved in during their years. Who was the IT manager of each project? What approach did you take (waterfall, iterative, agile, scrum)? What diagrams did you have them review (flowcharts, physical data models, use cases, state transition diagrams)? Label consistencies among the projects? What percent of success would the business person say about the project?

What's in it for you? An opportunity to build rapport and trust with the business community! Let them WANT to work with you and they will instigate promotions for you.

Start by walking in the business user's shoes. Identify what projects they did work on in the past. Identify what is different from your approach now. Will the difference enhance the user experience? Can you shield them from some of the changes? Will they be able to continue doing what they were hired to do (business function) instead of being locked for months in a room with you?

Kick off the first meeting setting expectations with each individual business user. Tell them the kinds of information you need from them (who, what, where, when, why, how, constraints). Those things don't change with the different approaches. That information is needed no matter what type of project you are working on.

Every diagram or work product you produce for a business person's review, add a legend and a paragraph (or two) on how to read the document. Tell them what you are looking for them to find or clarify. Be patient and walk each business user through part of the documents individually.

Why take this extra effort? Because if you asked Mark who helped him the most or who is his go-to-guy in Information Technology, it will be the person that took the time to make it easier for him to do what he was hired to do. That will be the person that gets the most bonuses and promotions. That IT person will be the envy of IT.

Be mindful that each project is done differently with the same business result.

SBDi speaks both Business and IT languages. Bring SBDi in to help communication between both organizations. Let us help you find the right flexible solution that will help business increase revenue.

Pat Ferdinandi, Chief Thought Translator