This article is courtesy of TechRepublic Premium. For more content like this, as well as a full library of ebooks and whitepapers, sign up for Premium today. Read more about it here.
A little education can go a long way toward helping the business understand things from IT's perspective. Use this presentation to explain the development process and the impact of change requests.
"They just don't get it."
How often have you heard that when people talk about the relationship between IT and the business? It's a sentiment expressed regularly. It is expressed by the business. And it is expressed by IT. It can frequently feel like the two organizations are in a bad relationship.
There are scores of articles on "aligning IT with business." Everyone stresses the importance of engaging with the business, bi-directional communication, benchmarking, and many other often-repeated buzzwords. And that's all true.
Enjoying this article?
Download this article and thousands of whitepapers and ebooks from our Premium library. Enjoy expert IT analyst briefings and access to the top IT professionals, all in an ad-free experience.Join Premium Today
It just isn't always very practical.
As the CIO of a midsize company, I need results a whole lot faster than that. We don't have the luxury of being able to allocate a team to "align each function with enabling technologies." Maybe I can get an hour with the business leaders to discuss some of these issues. Maybe. And then everyone is going to go back to doing what they have to do to keep the business running and growing. Crafting whitepapers on alignment strategies is most definitely not on that list.
So what can be done?
One approach that results in immediate value is education. Create an informal program to educate business leaders on why IT does some of the things it does. This approach doesn't require any takeaways or weekly workgroup sessions. It isn't a master plan to solve everything. What it will do is help the business, little by little, understand IT's perspective.
The reality is that IT and the business look at an initiative very differently. And that's good. They each have to focus on different aspects. The business needs to be primarily focused on customers, product differentiation, revenue targets, and the like. IT needs to be primarily focused on architecture, stability, maintainability, interoperability, and all the other "ilities."
Pain point: Change requests
One situation I have run into a lot involves the business asking for multiple features simultaneously. Because they don't know much about the development process, they can't understand the impact all those change requests have on our projects.
What seems obvious to the dev team (even concepts like dependencies and source control), is completely off the radar of some business leaders.
I was working on a consulting engagement once where our client had a bad case of change-request-itis. We were in the midst of a carefully prioritized set of changes to a specialized retail management system. The business lead came to me with a quick change.
"This would be something that we'd really like to see go out immediately. And I know that it is a pretty minor change. It would probably take only a couple of days to code, right? We can afford to give up a couple of days on the next phase to have this now."
He was right. Sort of. Taken all by itself, the change would require only a couple of days to program (and some time for testing and user-acceptance… something that this particular client always overlooked). But he was requesting that this change be made at the same time as some other changes to the same system. What he didn't realize was that these affect each other.
I explained that the overall impact on the project would be longer than two days (plus time for testing and user acceptance) because of the dependencies between his small change and the larger initiative.
"Agile!" he said.
Okay, yes. We recognize that business needs change and that a key precept of the agile philosophy is to "welcome changing requirements." But that doesn't necessarily translate into efficiency. "That change might have been two days (plus time for testing and user acceptance) last month and it might be two days (plus time for testing and user acceptance) next month, but it's not two days right now."
To help explain why, I used the metaphor of home construction. I articulately explained how multiple projects could require access to the same resources and how adding more workers didn't necessarily make a project easier. I then explained the different tools that software engineers use to manage these problems. He left the conversation with a stronger knowledge of software development and a full understanding of the impact of his request.
Okay, that's not entirely true. I actually fumbled through a probably-too-technical explanation of what he was asking. He left frustrated and confused. Full disclosure: I might have used the word "semaphore."
But what I did next was prepare a write-up that went through the explanation I wished I had been able to give from two paragraphs ago. I walked him and some of the other business leads through it during a program status meeting a few days later. And that actually did result in giving him a stronger knowledge of the impact of requests and how their timing could affect efficiency.
I created a presentation based on that write-up and discussion. It explains some basic concepts to our business leaders and stakeholders and demonstrates how requests can sometimes be ordered differently and completed more efficiently.
It covers some simple concepts:
- What is "a build"?
- What is "source control"?
- Why are some changes dependent on each other?
- How does that affect IT's ability to deliver changes?
- Why can't we just throw more developers at the problem?
If your organization builds software of any kind, some — or all — of this presentation will be relevant.
I kept the presentation fairly general so that it can be customized for any organization. Some generic system names are referenced, and I encourage you to replace those with names of systems from your environment that your business leaders will understand. (If you happen to know how many source files your applications encompass, there is a place to put that in, as well. It is a somewhat meaningless number that can be very impressive.)
Feel free to modify the content and formatting to fit your needs. Put it in your company's PowerPoint template; put your corporate logo on there.
The presentation is also designed to address only a few specific issues. My experience is that these knowledge-sharing efforts are most productive when they are targeted. A likely follow-up topic might be agile vs. non-agile approaches and the importance of early user feedback.
The goal of an educational session like this is not to turn everyone into an IT person. The audience doesn't need to come away as experts. A major objective is to reinforce the understanding that IT's decisions are not arbitrary. They are based on best practices and are rooted in the desire to deliver the most value to the business.
Simply getting that point across can make the relationship a whole lot smoother.
About the author
Keith Faigin is the CIO of EHIM, a health services company in the Detroit area. His 20 years of professional experience have included positions as an executive, a consultant, and as the founder of a startup company. Keith recently published his first novel, The Bone Eaters: Nick & Amato Investigation #1.