As an IT consultant, I’ve worked with hundreds of clients at small and large organizations. One of the key strategic challenges I’ve experienced in my dealings is the breakdown in communication between the business and IT. A majority of organizations struggle with alignment issues between the two sides. Part of the problem is the perceived role of IT in the organization. Accountability, ownership, and politics also play a big role in this issue.

Let me give you one example. In 2011 my company worked on a project for a large Federal agency gathering business requirements for a large-scale system. At the time, it was announced that IT was going to become more “Agile.” Agile is a software development methodology that has become extremely popular over the last decade, specifically Agile Scrum.* Agile is about short / iterative development cycles called Sprints which occur typically over a 2 week period. The approach that most Federal agencies and many commercial organizations use today is more “waterfall” based. Waterfall has been around for decades and is really about doing everything in very large chunks, as opposed to quick iterative cycles. I won’t get into all the details about these two methodologies; just know that Agile is meant to be much faster than waterfall. It is also meant to reduce risk and cut out waste. In the case of our client, the IT department started independently forming their own committees and teams. When I learned about this I asked the simple question, “How can the business side become more agile as to complement IT’s new strategy?” IT had moved forward with its agenda without really trying to figure out how both sides could be more agile together. Agile was perceived as a silver-bullet to IT’s development problem.

The key take away is for business and IT to communicate with one another regarding strategic direction so both sides have the will and motivation to move toward a common goal. This may seem obvious, but it’s not the norm. In the process of adopting Agile Scrum, many IT departments alienate segments of the business. In the case of our client, we started presenting, promoting and writing articles on the subject of Business Agility with the hopes of mending disparities between the two groups. We developed our own business side methodology called Agile Requirements Definition and Management (RDM) which mirrored the agile process on the IT side.** This enabled business stakeholders to implement a common process to work from which tied in seamlessly with IT’s strategy. It’s important to be aware within your organizations of any siloed strategies and to take proactive steps toward alignment. IT cannot operate on an island and it’s important in some cases for business stakeholders to step in and propose enhancements and changes to IT’s strategy to help communication run more smoothly and to strengthen alignment.

*To learn more: http://scrumalliance.org/ & http://en.wikipedia.org/wiki/Scrum_%28software_development%29
**http://scrumalliance.org/articles/398-agile-requirements-definition-and-management

Leave a Reply