Imagine if you will, you are the captain of a ship. (I’m from Baltimore, land of tall ships. Please pardon my nautical references.) You have been commissioned to deliver goods and passengers from point A to point B. You are uncertain where point B is but you have 16 years of experience sailing this ship and you earned your title of Captain. You have had a good look at the cargo and the passengers. You set sail. You know where everyone should go. Why bother asking the passengers and the folks that commissioned you where they expect to go?
All too often, much like that captain of the ship above, we rely on experience and the perceived business needs rather than involving the business in IT projects. After all, aren’t we the experts in IT? Why yes, yes we are. But what we are often not is experts in understanding how the business will use the end result of the IT project we are embarking on. In this scenario, we have been hired as the captain and crew of the ship. We are experts in navigating through the treacherous waters of IT. We REALLY get navigation. What we don’t know is where they actually want these passengers and freight delivered. We, as consultants and experts in IT, should insist on engaging the client’s business and not just their IT resources.
In a Gartner study of why IT projects fail, the top reason was not lack of technical skills, but rather the lack of business involvement. Moreover, in a 2008 study of Software Development Success, a large majority (83%) of respondents feel that meeting the actual needs of the user is far more important than building a system to specification. Let me pause there a moment. The client suggests that their satisfaction with an engagement is based more on getting what they need rather than what they ask for. The importance of this distinction cannot be overstated as we all work in an industry where client satisfaction is top of the pyramid. So ask yourself this question: how can we satisfy someone’s need if we do not know what it is?
Another piece of this business participation involves understanding the environment. Does the business trust IT? What is the relationship between IT and the business? Are they partners or competitors? Do you have direct access to the business or do you have to work through intermediaries? All of these factors and many more can and will impact business involvement. As an outside party, our interest is not to take sides, but discern what the need is and fulfill that need.
What if either the business does not want to participate or is unavailable? This is a tough one. If the business cannot (or will not) be involved from beginning to end, then negotiate and schedule check points with the business where progress cannot continue without their signoff and acceptance. Moreover, document all of this and get confirmation in writing. This will solidify expectations of what is to be delivered where and when. Continue to communicate with the business and IT stakeholders as to where we are in the process so that no one is surprised at the end.
At the end of the day, it is the consultant’s responsibility to engage the business, early and often. Think about the engagement as a relationship. Meeting with the business once does not make a relationship. A relationship takes work, communication, nurturing and maintenance. Make the business a partner and they will work with you. Ignore the business and your chances of success are as good as finding the right port for your passengers and goods.
It’s now you turn. Tell us your war stories and how you dealt worked through IT-Business dynamics.