Whether you are moving help desk support in-house or application development to a provider, changing the ‘who-where-how’ of your critical IT functions is one of the most challenging projects facing CIOs today. Planning and preparation will only get you so far, it ultimately comes down to execution. So, let’s say the business case is complete, the executive management team has signed off, the project team / vendor is assembled, and you’re ready to get started. Here are three lessons from the field that have proved to minimize project risk and deliver value.
1. Every organization has them.
These are the teams who are consumers / producers in the new sourcing model and ultimately ‘get it’; they are with the program. They are often the ones who were experimenting with the new sourcing model in the first place. Make them part of the initial pilot / wave. Empower them, support them, and give them the resources they need. Once they are successful (and they will be), they become your ambassadors for the rest of the program. Use them in subsequent waves to share best practices, assist those who are struggling, and to convince the doubters.An example of this in action involved the recent transition of application development from offshore vendors to an offshore in-house development center by a Fortune 500 retailer. A team involved in the transition embraced the objective and, through trial-and-error, developed a number of innovative methods to speed up team integration and learning. The project team codified these methods and became an ongoing consultative resource to other project teams for the duration of the effort.
2. Rethink the definition of stakeholders and tailor the way you engage with them.
It’s part of project management canon that we should engage our stakeholders during this process, but it’s easy to lose sight of which individuals and teams are most vital to the success of the project. Within the IT organization itself, we often identify the CIO and his/her direct reports as key stakeholders. This group is certainly important, but it is helpful to push a level or two beyond the leadership team to identify a handful of high-performing line managers and directors to pull into a working group that serves as a sounding board for the project.
The working group should be composed of individuals who directly manage teams and workstreams that will undergo change as a result of the project. Select a balanced mix of individuals you believe will be supportive, neutral, and opposed to the project. You definitely aren’t trying to build an echo chamber. By providing a safe place for this group to provide feedback and promoting healthy debate, you will get much more actionable intelligence that will lead to course corrections that can prove vital to the overall effort.
"It’s tempting to make an upfront effort to borrow or build out a complete set of scorecards and presentation decks that will be used to measure and report to the steering committee on progress."
Looking outside the IT organization, we know to build strong relationships with finance, legal, and HR to help us navigate their respective elements of the overall transformation effort. It will prove useful to work outside of the conventional norms of these stakeholder relationships during the course of a sourcing effort. For example, look to build an ongoing relationship with the attorneys that participated in the initial contract phase. Establishinga regular cadence to apprise them of progress and review legal matters will prove beneficial and could result in successfully navigating project pitfalls down the road.
3. Take an agile, open approach to developing your methods for tracking and communicating progress.
It’s tempting to make an upfront effort to borrow or build out a complete set of scorecards and presentation decks that will be used to measure and report to the steering committee on progress. Instead, take a measured, iterative approach. Focus on a minimum viable product and work from there. This allows your reporting to develop organically and results in a more flexible, adaptable reporting process. Some key metrics will only become apparent and important over time. This also increases stakeholder interest and decreases the ‘white noise’ factor that often comes into play when publishing progress reports.
Another aspect of communicating progress is to ensure the message and the metrics are getting out to the entire organization. Although the amount of detail may be different, it is important that all parts of the organization that are involved in the transformation effort have visibility to the progress being made. This extends beyond IT into the stakeholder teams that are enabling and contributing to the success of the overall effort, including finance, legal, HR, procurement, and beyond.
To the extent possible, the metrics and reporting should be transparent. Teams and individuals should understand upfront what will be in the scorecard, when it will be measured, how it will be measured, and what they can do to have an impact on the end result. Previewing the scorecard with key stakeholders, such as the working group mentioned above, will help catch errors and iron out potentially misleading progress indicators earlier in the reporting cycle.
Project already underway? It’s not too late, these practices can be implemented at any point in a project lifecycle and can provide a needed correction or accelerate the progress already being made. And with each successful project delivered, we gain new perspectives and an opportunity to contribute our knowledge back to the IT community.
