Getting the most from Information Technology

This is the last in a series of eight posts that examines the relationship between business and IT. Based on an article examining manufacturing by Steven Wheelright and Robert Hayes, I have talked about four different levels (or stages) at which IT can interact with the rest of the business:

Stage 1: Internally Neutral (Minimize IT’s Negative Potential)
Stage 2: Externally Neutral (Parity with Competitors or IT as a Service Provider)
Stage 3: Internally Supportive (Provides Credible Support to the Business Strategy)
Stage 4: Externally Supportive (Provides an Important Contribution to the Competitive Success of the Organization)

In the finale of the series, I'll talk about how to change your culture so IT actively contributes to the success of the organization, in order to unleash your company's potential by getting the most out of your technology innovation. To describe the change process, I'll leverage John Kotter's 8-step change method.

Step 1: Create Urgency

Let's face it, most people don't want to change. Staying with the tried-and-true is generally more productive in the short-term than trying a new approach. This can especially be true when you're talking about something such as allowing IT to contribute to the overall company strategy. Luckily, the breakneck rate of change for technologies that your competitors are probably using to improve their products and profitability is probably enough to create that sense of urgency needed to push forth change. Here are some things you can leverage to make your case:

Technology is changing how businesses work. If you're not leveraging mobile, data analytics, or smarter internet-connected devices, your competitors probably are.
Business leaders can't go it alone. Marketers can't know what problems might occur when connecting various platforms. Operations can't know what security problems they might be creating by purchasing automation software. They need help from the technology experts.

Step 2: Form a Powerful Coalition

Unless you work in an extremely small company, you can't push all of the needed changes yourself. You need to get the buy-in, if not active support, of other influential leaders within the organization. These leaders are not necessarily executives, though you need their support, so you should identify the most influential individuals and make sure they understand what you are trying to accomplish and why it is urgent that you do so.

In this case, you will want to get the most innovative individuals within the company understanding (if they don't already) why their ideas will reach their maximum potential if they work closely with the experts in technology. The executives within the company will likely be reluctant to let IT into their decision-making, so you may need to point out how previous failures could have been lessened with earlier support of IT.

Step 3: Create a Vision for Change

If you did a good job creating a sense of urgency around the change, people will want to implement their own solutions to the problem. Creating a common vision will help ensure that, as people work to implement the change, they work together towards a common goal rather than in parallel towards similar goals. Your specific vision will vary depending on your company and its needs, but starting with creating an environment where all employees are empowered to make decisions is central to a true Stage 4 environment.

Step 4: Communicate the Vision

Once you have a guiding coalition and a vision, it's time to communicate that vision to the company and get them on board. Having one meeting to communicate the ideal future and expecting results isn't feasible. Instead, communicate the need for change as much as possible in as many methods as possible. It's also vital that you do what you say - "actions speak louder than words" certainly applies here. To become a partner to the business, you may want to consider the following:

Don't hide your developers behind business analysts and project managers. Your development team needs to hear first-hand the problems the business is trying to solve, and business users need to hear first-hand the challenges to make issues go away.
Encourage your employees to actively participate in strategy discussions - these are more than just "business decisions" and the team needs to give them the appropriate attention.
Encourage new ideas and implement the good ones. Give individuals the freedom to implement their own ideas, even if the solution isn't the one you'd choose.
When you can, tie compensation and bonuses to the new objectives.

Step 5: Remove Obstacles

I've met a few people who were frightened of change merely because it is change, but most people have specific concerns that they want to have answers for before buying into the change. Rather than force the change through anyway, address as many of these concerns as possible. To do this, you can:

Encourage constructive feedback and visibly adapt your plan when valid concerns arise.
Give your change leaders the freedom and authority they need.
Alter organizational structure if necessary to reflect the new goals.
Minimize the influence of resistors as much as you can.

Step 6: Create Short-Term Wins

Creating short-term wins does two things for you:

Small changes, especially at first, are more achievable than large ones. Aiming for small wins means you can start making progress without needing a perfect solution.
Both success and failure tend to feed on themselves. You want to establish a few successes to prove to people that this is the right course of action.

In trying to create a partnership between business and IT, you can look for short-term wins by:

Celebrating a successful product delivered successfully because of collaboration between business and IT.
Implementing a new product idea from an IT person that improved a business function.
Creating a new award for employees that live the new ideal.

Step 7: Build on the Change

Kotter states that many change initiatives fail because victory is declared too soon. In one example, he states that he tracked the number of changes as the result of a change initiative, and the peak number of changes happened in year 5, a full 36 months after the first quick wins. (https://hbr.org/2007/01/leading-change-why-transformation-efforts-fail/ar/1) It is vitally important that you keep pushing the change. It is easy to get discouraged with the sometimes glacial pace of change, but stay vigilant!

Step 8: Anchor the Changes in Corporate Culture

This last change seems fairly obvious. If you're making a corporate culture change, it goes without saying that the change should be a part of the corporate culture. But if you read Kotter's article that I linked to in Step 7, you'll see that Kotter suggests you do the following to cement the change as a part of the culture:

Explicitly make connections between success and the new approach.
Ensure that top management continues to make a good example for the new way of doing things.

And though he doesn't explicitly say so, you should also emphasize your new values when hiring new candidates, setting their expectations that the ideal way is, indeed, "the way we do things here".

Summary

It's easy to say that in order to achieve its fullest potential a business must integrate its technology team with the rest of the business. It is much harder to make that happen in companies where the established normal mode of operation is to treat IT purely as a service provider. Merely telling people that collaboration is better isn't good enough to push forth change. Instead, you'll have the best success if you carefully plan for a cultural transformation.

Unwillingness to change staffing

Central to Agile's core principles is responding to change well. This is important because software needs change quickly and often. In some cases, this can occur because business needs can change on a dime, e.g. a new competitor enters the market. In many cases, change occurs because people working with new software improve their understanding of the underlying need. Whatever the reason, though, software makers need to be able to change quickly.

Because such change is expected, it is impossible to set firm budgets, timelines, or scope for an Agile software project. But it's largely a project manager's job to track and maintain timelines, budget, and scope for projects. Sticking a traditional project manager on an Agile software project is at best a waste of the project manager's time. At worst, though, his/her presence and influence can undermine the newfound agility of the software team.

Unwillingness to embrace uncertainty

As I said earlier, change is expected within the course of completing an Agile software project. Agile teams are built to adapt to these changes by handling the most important issues as they arise and dealing with the rest later. However, some business leaders want to have a plan for every possibility. Spending time to plan for a situation that will never happen is a waste of time and resources under the best of circumstances. But when taken too far, this can lead to "analysis paralysis" and kill the progress of a software team.

Lack of leadership

When ever-shifting priorities are built into your process and mindset, it is easy to get distracted with items of relatively little importance to the organization. Leaders with a strong sense of true business priorities who can persuade others what the right path is will keep the software product moving in the right direction. Weak leadership will allow individuals with a personal agenda to hijack the effort of a software team. Or just as bad, multiple people can try to take the product in multiple disparate directions, creating confusion and frustration in the team while leading to an unfocused product.

Lack of personal responsibility

If you had shown all the items on this list to me five years ago, this one would have surprised me the most. After all, who doesn't want to do a little extra work in order to do much less work in the long run? Agile requires constant communication between the software team and the business leadership, but it also requires business leadership to make decisions and make their teams ready for the coming changes. But not all leaders are willing to do so, unfortunately. There are two attitudes that I've seen from these people:

People who believe that software is the job of the "techies", so they don't wish to make any decisions regarding the software
People who avoid getting deeply involved so they don't have to take blame if the project fails, but try to stay superficially involved so they can claim a portion of any successes

Regardless of the reason, to depend on these people who won't take responsibility for the success of their area will almost certainly derail your Agile effort.

Inability to see the big picture

When you are constantly reprioritizing your queue, you need to have a grasp of the big picture, both in terms of current state and ideal future state, to know what features/fixes should be worked on first. When you don't see the big picture, everything seems like a high priority. And to quote a former co-worker of mine, "when everything is a high priority, nothing is a high priority". In such environments, it becomes nearly impossible to know when anything will get done. This will cause people to first lose faith that their items will get done, then to lose faith in both the project and process as a whole.

Extreme change aversion

Few people like change. But there are some people for which change is something that causes extreme anxiety. You can tell who these people are fairly easily in meetings - at the mere suggestion that they might have to rethink what they do their eyes get wide, they literally brace themselves in their chair, etc. When the mere suggestion of a single change can cause this level of anxiety, the thought of constant change can lead to mental shutdown.

Conclusion

Change is hard under the best of circumstances. Changing to Agile is no exception. When you're not dealing with the best of circumstances, it's vitally important to identify that as early as possible to make appropriate adjustments. If you have a team that's smart, is willing to take charge, and is willing to change, then you'll likely have a relatively smooth transition to Agile. If not, then you'll need to take additional steps to prepare your leadership team and the rest of the company for the change.