The PMO as Change Agent and Business Partner

Early in my career someone described the information technology department as a dragon sitting on a pot of gold. It was incumbent upon business units to navigate opaque jargon and unending bureaucratic processes required by IT if they wanted to get anything done.

In this new world of digital transformation, the business no longer needs access to the dragon when seeking technology that will optimize business processes and transform the student experience. This might be a good thing. In today's environment higher education institutions can no longer afford to wait on an IT department still stuck in the Dinosaur—or in this case, the Dragon—Age. What they do need is the right technology that will allow them to innovate against the threat of what some journalists are calling the coming obsolescence of higher education institutions.

Today, technology vendors market directly to the business. Divisions and even departments have the ability to acquire technology or sign up for services without involving IT at all. Some have even suggested that the business no longer needs the involvement of IT to add new technology capabilities—until, that is, it comes time to implement or connect the new technology to the infrastructure.

If the abundance of white papers, literature, and magazine articles on the subject is any indication, IT departments are realizing that technology is no longer something that can be controlled by an elite few with specialized knowledge. As higher education institutions face questions of relevance and effectiveness in preparing students to thrive in the global economy, IT organizations have had to face questions about their own relevance and value to the institution.

This raises the question of how a university IT department can make itself more relevant in an environment where technology not only appears to be everywhere but is also perceived as being cheap and easy to get. One solution is by using the Program Management Office (PMO) to work collaboratively with the business. The PMO, which is essentially a change agent, is in a unique position to partner with the business to implement innovative technologies that will transform the university in order to meet the demands of today's students.

At University of the Pacific, the PMO understands the importance of partnering with the business on both a macro and micro level. The difference between portfolio/program and project management is one of breadth versus depth. At a broad or macro level, we link initiatives involving technology to the university's strategic goals, which include pursuing new student markets and maintaining the ability to adapt and be agile in the evolving world of higher education. Portfolios are broken down by division, so each business segment can see what projects are in the pipeline, which ones are in flight, and which ones have been completed for each area. While not quite there yet, we are starting to analyze data to communicate workload and the overall health of each portfolio. We are also starting to see what strategic initiatives have the most projects. In doing so, we soon will be able to determine whether our resources and efforts are aligned with the projects that are most critical to meeting the university's strategic goals.

More importantly, the PMO has added the business analysis competency to its capabilities. By training staff on this competency, we've started to change the language of IT. For example, each new project must have a corresponding business case. Project managers and projects led by engineers now include more discussion with the business partner. We ask questions such as, "What problem are we trying to solve?" and "How will the solution impact the business and business processes?" and "Who will be impacted?" We are using a business-problem statement to guide subsequent project activities (see figure 1).

Again, though we are not quite there yet, we have started to think about how we name projects. Instead of naming projects from an IT perspective, such as "Install XYZ System," we now encourage our project managers to develop a project name that better represents the problem we are trying to solve or the innovation we are trying to achieve for the business. "Install XYZ System" might become "Create XYZ Service." Changing how we talk about projects broadly will lead to a change in how we think about technology implementations. We don't implement technology for technology's sake but instead to enable creative change in the business.

On a micro or project level, we have reevaluated our approach to project execution to coincide with new thinking about best practices in widely used project methodology frameworks. As project managers, we recognize that project management is an art. Some projects are more suited for an agile approach, especially when it is acceptable to the business to start realizing some benefits early in the project rather than waiting until after the project is closed. If the business unit needs it fast, we can do it fast by negotiating a minimum viable product and a schedule for benefits realization. In addition, we have started to focus more on benefits realization and work with business segments to identify project outcomes and success metrics and discuss how the new technology will affect business processes. We ask, "What does success look like?"

With the new business analysis capability, we now have the skills on board to help business units visualize through modeling the impacts that new technology or changes to existing technology could have on business processes. An impact analysis through the lens of people, processes, and tools helps us tailor the project approach for the work at hand. Through modeling the business process, we can find and close gaps. Finally, each project has what we call an operationalization phase in which we measure to see whether we have indeed met stated success criteria and are realizing the expected benefits. During this "check" cycle from Deming's Plan-Do-Check-Act, we make any necessary adjustments to meet our objectives. We end the project with lessons learned. Plans are under way to store these lessons learned in a central location so they can be collated and incorporated into similar projects.

These new approaches were tested several months ago when the PMO was asked to jumpstart five stalled projects. Although each of these projects had an IT component, they were not all IT related. The desired outcome of each project was to implement new policies or make changes to existing university policies. The projects had been in flight for some time. Much work by committees of extremely talented people mostly external to IT had already been done—including some policy drafts, benchmarking, requirements, etc.—but efforts to implement appeared to have ceased.

After discussing the issues with the policy owners and implementers, the PMO knew right away that we were not going to be the change agent needed by solely relying on a waterfall approach to this problem. We knew we had to collaborate with the various business units involved to identify what went wrong and together develop a solution. Working with the business, we created an implementation framework that would get the projects rolling again (see figure 2).

Along with developing the framework, and using acquired business analysis skills, the PMO performed a document analysis to see at what point each project stalled. We analyzed the first project using the framework of people, processes, and tools or enabling technologies. We documented the results in an impact analysis where we could readily see the gaps and close them. Closing those gaps required that we change existing business processes or develop new ones. We still have four new polices to implement, and we plan to do so using the same approach and working collaboratively with the business units. We still have more road to travel, and the first policy implementation was not without bumps. Still, we believe that each successive implementation will be better than the last.

Using the PMO as both a business partner and a change agent, IT can work collaboratively with the business to stay competitive and relevant and meet the challenges stemming from the disruptions in higher education. Perhaps it is safe to say that IT and the business need each other to survive the disruptions of technology and of higher education and that the dragon has finally descended the mountaintop.

---

Faye Snowden is Senior Project Manager at the University of the Pacific.