5 lessons for managing massive IT projects

At the 2015 AWS re:Invent conference, Choice Hotels CTO Eben Hewitt shared his top lessons for managing transformational IT projects within an organization.

Choice Hotels CTO Eben Hewitt presenting at re:Invent.
Image: Conner Forrest/TechRepublic

Even if you know it will benefit your organization, beginning a massive, transformational IT project can bring with it a host of challenges that you'll need to overcome.

Eben Hewitt, CTO of Choice Hotels International, hosted a breakout session at the 2015 AWS re:Invent conference where he shared five lessons for managing these large projects that he and his 500 person team learned while they worked on a three year, $20 million IT project for Choice Hotels.

Hewitt's general thesis is that an IT project itself is actually a system. Therefore, you can design the project according to system design principles to achieve the best results.

Here are the five lessons Hewitt learned and how you can apply them within your business.

1. Find the sine qua non

Sine qua non is a Latin phrase that roughly translates to "that without which, not." Hewitt calls this the necessary component of your project.

Begin the project by asking what is essential about this project, what is the defining feature or capability that is central to its identity. Once you have found those essentials, you should group these components together and place them on your roadmap.

One of the problems you'll run into is the project being too big, so many employees can't see the whole vision. If the system could do one thing, define what that is and go from there. It helps you create a "cookie cutter" for everyone to return to.

As you begin to design and program your services, Hewitt said, do those from the middle-out. Not from the bottom up or top down. By doing this, he said, you can maximize what you can do in parallel, because if the middle contains the essential piece, you can have two separate teams work on the portions on either side of it at the same time.

2. Find the Candy Crush

For the uninitiated, Candy Crush is an object matching game where users line up colored pieces in order to have them cleared from the surface. Or, as Hewitt said, it's "the new name for Tetris."

To find the "Candy Crush" in your project, it means you find the places in your project that, when completed, will clear a column in the work itself. It clears the path for a new piece of the project to be worked on, or for a new team to come in and help.

To utilize the Candy Crushes, Hewitt said, front load the things that open the most opportunities for change. Look for what enables the most parallel work, and find the capacity milestones to ship.

As you set on this path, try to constantly reduce the problem set to get variables out of the equation. Look for ways you can "close off" groups of features so you don't have to think about them anymore.

3. Define what will help you learn the most the earliest

When Hewitt and his team first began looking at load testing, despite outside urging to increase the load gradually from 1% to 5%, Hewitt instead pushed for an increase from 1% to 30% so that he could learn more about how the product handled load.

Hewitt encourages IT leaders to perform tests like load testing early and often. This helps the team determine if there are any obvious bottlenecks early, and it helps them learn from any mistakes they've been making.

In addition to testing early, Hewitt said IT should define the metrics early, or how they'll measure progress. Once you have those metrics, bake them into your services as you build them.

4. Design for resilience

If a project fails, often someone in the company will perform a post-mortem to determine why it failed and what went wrong. Hewitt recommends creating a pre-mortem document that helps you mitigate potentially disastrous circumstances.

In the pre-mortem, IT should consider what to do when:

  • Events that are supposed to happen don't
  • Events that are not supposed to happen do
  • Surprise events that no one thought of occur

After creating a pre-mortem and talking through possible scenarios, the next step is to perform due diligence on your project as if you were buying it yourself.

Finally, establish a competency center. Enforce a standard development platform and provide guidelines and design reviews.

5. Make the uncertain certain

The first step in this lesson is to define the architecture formally, although Hewitt realizes this won't be very popular with some folks.

"This is not the groovy Silicon Valley thing," Hewitt said.

He said the purpose of architecture is to create integrity, show how the design supports "ilities" (portability, extensibility, manageability, etc.) and manage trade-offs.

As you envision the project, start at the end with a concrete visual of the end state of the project and work backwards from that vision.

In Hewitt's case, the end goal was powering down the legacy system they were replacing, meaning that no one was talking to it, and all the ends were already tied up. Figure out all the steps you must take to realize that end state.

To make things even more certain, Hewitt said, make sure that you clearly define your elevator pitch so that, if you meet the CFO in the hallway, you can articulate what you're trying to do.

Also see