Putting Change Management to Work

The Horizon project is using several techniques to manage the project through to success, and has developed best practices that work well (at least for United). Some of these are organizational.

For instance, United business sponsors and IT leaders are aligned through a strong executive governance board. The full, dedicated team exists to help drive change through the company—especially during the phases where many people say, "Oh, it's just an infrastructure change" or "It's just an IT project." At United, this is a nontrivial department: 40 people report to Patel.

The company established a "Guidance Coalition." This is not a matrix organization with business on one side and IT on the other, explained Patel. Participants make decisions for the division. Nor are they just a bunch of strangers who only see each other at meetings, she added; true alignment is a necessity. "The truth is that there is always a divide and a schism [between IT and the business]; on a project like this, that just won't work," Patel said.

United created a job title of "business engagement manager" to be a consistent point of contact between the IT project and the division. This is broader than the role of the business analyst, she said; it's a trusted business operations person who can engage at all levels and act as "the single voice of the business across all aspects of the development lifecycle." The business engagement manager is sourced from the business, not from technology professionals, Patel stressed: Choose someone who is "great at connecting the dots."

Bring business process management into the company. Horizon uses enterprise process models and techniques to maintain a strong cross-functional perspective, Patel said. "Everyone [in each department] uses a different language, but we're building a system that affects 20 divisions."

Additional suggestions can help you get the design just-right before you write a line of code.

Put risk in a framework, she suggests. Identify which scenarios are high-versus-low impact, which have high or low probability of occurring. Doing so is critical for long-term projects. "It's better to be prepared than to be surprised," Patel said. Charting these in a graph or framework is an exciting exercise, she added; get a facilitator and get the team involved.

Determine the process architecture. (Finally: technology!) Identifying the process architecture sounds complicated, said Patel, but it's about understanding what you're doing and it gives more transparency to both business and IT participants. To determine how to create the SOA building blocks, and map processes relevant to the project scope, the Horizon project had a LEGO party. Each group of two or three team members was given tagged LEGO blocks and asked to "build a reservation" in a controlled scenario. Everyone learned what each of the pieces involved added to the process and, she implied, the competing team approach helped the Horizon personnel understand the different ways a "simple" transaction could be addressed by IT.

The Horizon project created a business integration roadmap. At first glance, it looks like a typical project management application, showing the order of software subprojects and their dependencies. But the roadmap is presented in a business way, since its intention is to communicate expectations to the businesspeople rather than to techies. It reflects dependencies from all business teams, not just IT; a call center move or union negotiations can impact the software rollout schedule, after all. Identify which migrations will happen, when.

And, added Patel, be sure to factor in the benefits realized from each stage in the project. "Tell them the value," she said, "Or they'll stop giving you the money."