1. Program Strategy & Mission Alignment
Business outcomes have to be front and center in any new program--and an RMO should make this a standard part of doing business. With an RMO, the first step is to establish a clear set of benefits that should be delivered by the program directly from the business case, and develop a program strategy and roadmap for achieving them. From there, every decision the team makes is scrutinized through the lens of the overarching program strategy.
Every decision has tradeoffs. That's not news. The challenge is to determine the right tradeoffs based on business goals. For example, "option A" will improve cross-sell opportunities in the call center by an incremental 10 percent, but it will delay the implementation date by six months. What's the right answer? It depends on the business problem you are trying to solve. Is your current call-center platform failing, resulting in the loss of customers every day? That points the way to one decision. But if your top priority is taking market share from your chief competitor, that may lead to a different choice.
Measurement is another key to an RMO-based approach. There's always a lot of talk about measuring outcomes when the program is completed, but it rarely happens in practice. Why? Because nobody knows how to do it. The RMO should provide a clear set of criteria for evaluating whether or not the program is delivering the desired business benefits--during the life of the program and after it's completed.
When it comes to measurement, start simple. Use standard measures that can be easily tracked, and make sure you can obtain a reasonable baseline. It's also important to avoid the temptation to overanalyze the choice of measures. This isn't an exact science. Be specific wherever possible, but remember that it can be just as valuable to identify overarching trends.
Just as important, make sure accountability for measuring results is clearly spelled out. Establish accountability (often within your strategic planning function) and do the same consistently across the enterprise. In the end, this isn't the job of the PMO or the IT department. If nobody's on the hook for measuring and reacting to business results, the odds of actually achieving those results are slim.
2. Integration Across All Projects
It's easy enough to say that a PMO needs to achieve program integration. But how does it actually get done? In an RMO, that's the job of what we call the domain authority. This team of business and IT specialists should be responsible for establishing a common business and technical architecture for the program. Perhaps even more important, they should have the authority to make, communicate and enforce integration decisions consistently throughout the life of the program.
The success of the domain authority rests squarely on two things: the strength of its members and its ability and authority to drive overall direction without having to tangle with day-to-day delivery details. You need to have the right domain specialists in place to drive integration--people who have a demonstrated ability to see the big picture and are unlikely to get sucked into the minutiae of program management along the way.
3. Stakeholder Buy-In
Without a focus on people, even the most elegant solutions won't be successful. Which isn't news to anyone who has ever been involved with a successful program implementation. In an RMO, this responsibility should be clearly assigned to a team responsible for generating awareness, involvement and ownership among the community of people who will be affected by the program. At this stage, "what, when and how" are important--but don't forget "why." If everyone understands why their world might be changing, and what it means to the company, they're more likely to truly adopt change. Linking people with outcomes is a key aspect of an effective RMO.
The expected result? Stakeholders who are aware of the program and know what business impact it will have on their organizations. An organization that is prepared, trained and--most important--ready to adopt whatever changes are necessary to make the program successful. And a program that has a much better chance of actually being adopted and embraced once it's launched in the business. If you've ever seen a technically great program fail at the hands of an apathetic community of business users, you already know just how big a deal this can be.