Make IT Work: How to Learn From Failure
BIZTECH: When planning a technology project and building a business case, when and how should different teams be pulled into the process, and what are the factors to consider?
NIEL NICKOLAISEN: The first thing I want to do is align every project around the organization’s strategic goals and initiatives for the year. Then we get the right people together and work through what the business case is, what the value is. Each project will have a mini team that does “iteration zero” planning. We use an agile approach to our projects, which divides projects into phases or iterations. Before we start doing anything, all we do is plan. We define the business case. We do the build versus buy analysis, the traditional stuff.
When we do a business case, it’s with a cross-functional group because it’s rare today to do an IT-only project. If I do something for client services, I will have client services people there. If I’m doing something with the sales group, I’ll involve sales. I want other members of the organization involved to understand what we’re trying to achieve, what their goals are, how we measure success and the acceptance criteria, which is how we know when the project is done.
It’s not necessarily the high-level executives that join the team. It’s probably the next level or two levels down. What I have found in practice is the top executives don’t know enough or they aren’t close enough to help implement the project.
BIZTECH: What works well and what doesn’t when different teams within a company work together on a business case?
NICKOLAISEN: The most important thing is to constantly remind people why the work matters and make sure we answer that question first. If people understand the why, they get really passionate about what they are doing, and the why drives positive behavior in everything you do.
The first questions in my business case templates are: What needs to be done? Why does it matter? And what happens if we don’t do it? When those questions are answered, the rest starts to take care of itself — the planning and execution.
BIZTECH: How do the lines of business continue to be involved after the business case and strategy are developed?
NICKOLAISEN: I take the core team that I got together to brainstorm and do the business case, and now they’re doing the implementation. Unless it’s purely an IT project, like a network upgrade, then only IT needs to be involved. But if it’s changing an application someone is using or needs, I want that department or those departments involved.
It’s a group, thing because not only are we going to implement technology, we are going to change processes and practices. We might change policy, so I need the people who own the processes involved because I will lean on them to fight battles. For example, it could be a person in manufacturing that helps me with any barriers we encounter in manufacturing.
BIZTECH: As the buy and deployment takes place, how should the group morph to ensure a smooth transition to rollout, and then training and support?
NICKOLAISEN: What happens over time, as this core team gets deeper in the project, is that you add the right people to it. If we need to train client services on the new technology, the client services person says, “OK, I’ll talk to the person who does training at client services and get it scheduled.” We’re adding more people, but we still have the three, five or eight people we started with — they will see it through to the end.
For example, we just finished upgrading our enterprise resources planning system. We had a core team of one person from every department that our ERP touched. By the time we finished our go-live upgrade, there were 110 people involved on a regular basis.
BIZTECH: What’s the best lesson learned, tip, critical consideration or best practice you would share from being involved in major IT projects when it comes to smart business case practices and working with teams within a company?
NICKOLAISEN: Pilot everything. Fail fast, fail cheap, and fail early.
You have to think through your system and processes and figure out how you can make everything pilotable. The best thing I’ve ever done is embrace the idea of small, rapid pilots. The ERP upgrade we just did at O.C. Tanner was a non-event. Everyone was in a war room waiting for panic to break out, and we had two calls the entire day.
There were no surprises because the pilots had already shown us the problems. We solved all the problems, so when we went live, nothing unexpected happened.
Nickolaisen was previously CIO at Western Governors University and led the creation of predictive analytic models that improved student retention. He has authored two books about how to create agile, nimble organizations.
Get more smart tips from tech leaders on how to create and manage successful IT teams today.
