In my last blog, I wrote about IT agility. I wrote about three items that, if embraced, can enable IT agility:

1. 1. agile software development;
   2. strategic leveraging of SaaS and PaaS; and
   3. virtualization.

However, besides these process and technology opportunities, what can an IT organization do to enable agility? The real question is how can the IT organization structure itself to enable business agility? I believe the answer involves Release Management, Solutions Architects/Liaisons, R&D, and Service Management.

1. Release Management

One of the biggest frustrations I often hear from the business is the lack of transparency and visibility around when they will receive enhancements to their core platforms to enable business objectives they need to achieve their goals. This lack of visibility is usually caused by lack of transparent governance, which can be partially fixed with process and communication changes. The harder item to fix is how long it takes IT to deliver enhancements to core platforms. I believe this problem can be solved by adopting a mantra of “don’t do big projects” when enhancing an existing core platform.

When you work on big projects they take a long time (duh), and then scope inevitably becomes a problem because the business or priorities change during the project, and you have inevitable delays and frustration. Therefore, the solution is small releases managed by relentless focus on prioritization and short sprints. This release focused process delivers huge benefits including easier scope management, quick time to benefit, full transparency into what will be delivered, and IT & business sponsor agreement on prioritization. The stumbling block for many companies is they get hung up on how often should you do quick releases?

Don’t get hung up on that. It’s better to set a goal, such as once every month, but then focus relentlessly on prioritizing those items that can fit into your goal, and deferring those items that cannot till the next release. This is hard to do, and takes enormous fortitude on behalf of your IT business liaison personnel. Lastly, be willing to adjust your goal if you have bigger individual enhancements that don’t fit into your goal window.

Just be transparent in your communication to your business sponsors on what the adjustments will be to the timeline, and don’t let the delays be bigger than twice your original release goal.  What this leads to is quick releases that deliver constant value to your business partners with the resulting you improve the perception of IT’s agility because you constantly deliver.

2. Solutions Architects/Liaisons

The IT business liaisons role has been around for quite some time. However, I have seen these roles fail because the personnel are only facilitators rather than individuals who can help collaborate on solutions to business problems. Changing your liaison personnel to be combination facilitators and solution architects is the solution. Now don’t be fooled by the term “architect”.

I do not mean these people should be super technical and part of the traditional Enterprise Architect organization. What I am referring to is the ability to solution a vague business need into an architecture that works within the constraints of the current core platform you are trying to enhance. A solution architect/liaison understands how your current core platform operates at a business process level. They also understand some of the technical features and limitations of the core platform. They can help translate business requests into viable solutions that can be built quickly on top of the core platform.

I’ve found that these people usually come from the business operation department, not from IT, and they often are fairly technical because they have been the “go too” people for their business unit when it comes to understanding how their core systems work. In other words, they understand the business, and usually have a technical aptitude that allows them to envision solutions that can be built on top of your core platforms.

Bringing these folks into the IT organization and making them official solution architect/liaison builds credibility with the business by showing that the IT organization understands the value these people deliver in enabling solutions that meet the business goals.

3. R&D

Too often many IT organizations talk about R&D, but rarely do they have anyone permanently assigned to do R&D, nor any process for evaluating R&D activities. Sound familiar? Too me this is very strange, because if there is any group that is constantly exposed to potential R&D solutions it is the IT department. Vendors call on us constantly, startups try to reach out to us with their new solutions, and the conferences we attend are full of potential improvement ideas. So, why is it that IT doesn’t embrace these R&D opportunities?

Often I have found that IT would rather act as the “catcher” of R&D ideas instead of the generator. The funny answer I hear often from IT is that the business would not like IT bringing ideas to them, because the business considerers R&D their turf.  Really?  I challenge that the real answer is one of the following:

1. 1.  IT doesn’t bring ideas to the business, so how would IT know how the business would react, or
   2. IT brings solutions to the business without being able to convey how they would improve the business, so they are ignored, or
   3. IT gets too wrapped up in the potential change impact of a new R&D solution such that IT focuses more on why something can’t be done instead of how to make it happen.

The answer to combat all these problems is to build a true R&D organization inside of IT. This can start off as just one person to lead the effort, leveraging others inside of IT on stretch assignments. The important point is the leader of R&D needs to relentlessly focus on finding solutions that would help the business achieve their goals. When those solutions are found, R&D needs to quickly bring in the right business sponsors to see if they are excited about the opportunity.

Believe me, if you can articulate how the R&D solution will help the business sponsor achieve their goals, thereby helping them get their bonus (which is mostly goals driven) they will at least listen. Usually what I’ve found is that some business departments are incredibly excited about R&D, and others are not. That’s ok. That just means that R&D focuses on finding solutions for those departments that are receptive. Over time, other departments start to notice that the majority of R&D solutions are targeting certain departments, and they start clamoring for more attention, thereby bringing them on-board with the concept.

IT management then needs to give stretch assignments to your High Potential personnel to work on these R&D efforts. This becomes an incredible motivator inside your IT organization, because people see that the best performers get to work on new R&D projects, so they strive to achieve that level so they too can get these assignments. In addition, your high potential people are likely to bring their skills to bear to ensure R&D projects are successful and can be sustained, thereby ensuring the business receives the benefits, while also ensuring you keep your high potential people motivate to stay with your company. It’s win-win all around!

4. Operations Service Management

so far I’ve talked about items that primarily improve the project side of IT. What about improving the agility of the operations side of IT? Many organizations have been following the ITIL roadmap towards overall Service Management. Plenty has been written on why this has benefits, so I won’t cover that here. I believe the biggest benefit to adopting an ITIL service management orientation can be encompassed in three words: plan, implement, and measure. I’ll re-phrase these three words into what I believe this really means  — run IT like a business! People always ask me what does it mean to “run IT like a business”.

In response, I ask what does a typical monthly business unit meeting look like? A business unit spends the majority of time reviewing the “numbers” that indicate how they are doing at achieving their goals. Now, let’s contrast that with most IT meetings. Most IT meetings I’ve seen spend the majority of their time on project status, discussions around recent outages, and lastly a discussion of resource contention.

Does anyone see the discrepancy here? The biggest gap in IT running its operations like a business is a lack of numbers that indicate whether IT is achieving its “business goals”. Remember, IT is part of the business and therefore we do have our own business unit goals, and even better, we help enable most other business unit goals for the enterprise. So, reviewing the IT “numbers” is what the majority of an IT meeting should be spent on, just like it is for a business meeting.

Sadly, IT usually has lots of metrics/numbers, but hardly any of which are actionable or relevant towards the goals of IT and the business services we enable. So, as part of moving towards a service management approach to running your IT operations, you need to first plan what your goals are and align them to the services you provide that enable the business to achieve their goals.

The important thing is to define measures and metrics that tell you whether you are achieving the goals that you planned. I’m a big believe in the quote “what get’s measured, get’s done”.  I even think IT should be reviewing some of the business unit numbers in our meetings specifically to see if our IT activities are impacting the business unit numbers in the way we expect.

It’s amazing the change you’ll see in your IT organization once you adopt a service management approach that is based on measuring the numbers for the items you’ve planned and implemented. Amazingly the numbers will improve, I guarantee it. Even better, your IT personnel will be better aligned with the business because they will speak the common language of numbers.

Explore More

• Making Enterprise Portals Work!
• Redefining Enterprise Architecture
• Getting the Best Out of an Enterprise Network
• Global e-Commerce – Realizing the Full Potential
• Steps to Boosting Business Agility
• The Agility – Stability Paradox
• Mastering Recipe to Business Agility
• The Cost of Business Agility
• Will Business/IT Agility Eat Strategy for Breakfast?