The Right Projects Done on Time: Seven Steps to Successful IT Governance

Proper intake and governance of IT projects is critical. If colleges and universities don't have a well-designed process for evaluating requests and scheduling those that have the most merit, confidence in the institution's ability to deliver effective IT services falls apart.

At Miami University in Oxford, Ohio, we have developed a carefully controlled process for assessing and scheduling IT projects. As a result, we have a reliable schedule of the work our IT teams will undertake in the following six months. When a project launches after going through this rigorous vetting process, confidence is high that it will land within the time frame to which we've committed.

Although the needs and culture of each institution vary—what works for one college or university might not be the best solution for another—we have found these seven strategies to be effective in creating a strong governance process for campus IT projects.

1. Have a single system of record for managing project portfolios.
Using a single, web-based platform for project and portfolio management (PPM) gives leaders easy visibility into the full scope of work being done by IT teams across the institution, which improves planning and decision making. We are using the TeamDynamix platform to make project governance more transparent. Because we can see who is working on which projects now and in the future, we can schedule projects and manage IT resources more effectively.

2. Limit the number of people responsible for initiating projects.
At first, we allowed representatives from each division to enter project requests into the system. However, we found there was no consistency among requests when we took this approach. Often, we did not have all of the information we needed to evaluate, compare, and prioritize requests.

Our experience taught us it is a good idea to designate a few individuals who will oversee this process. At Miami, my colleague Dana Miller and I—both senior business analysts for IT Services—initiate all project requests to ensure they follow the same format and can be properly vetted.

3. Develop relationships with senior-level executives from each division.
Dana and I meet informally with the director or associate vice president in charge of each campus division on a regular basis. During these casual conversations, we talk about the challenges each division is facing and how we might solve these with the help of technology.

For example, in a recent conversation with an AVP of our Enrollment Management and Student Success division, I learned that we were experiencing strategic limitations with a long-in-the-tooth course registration system. The division wants students to be able to walk out of freshman orientation with an eight-semester plan for how to graduate with a bachelor's degree. This would help put students on a path to success while also helping the university forecast the demand for classes; our current system doesn't give us that ability.

This is where the governance process for IT projects begins. At this point, we simply want to give others who might be eyeballing holes in our portfolio a "heads up" that we're doing this planning. We refer to these potential projects as "dugout" items. They are not set in stone, but they are on the list so that everyone is aware they might be coming up to bat in the future.

4. Involve seasoned IT professionals in the discussion of project proposals.
Next, we invite the appropriate division sponsor to a "value engineering" meeting with a "brain trust" of IT professionals with deep historical and technical wisdom. Because they have a wealth of institutional knowledge, they know why we have taken certain approaches in the past and how other divisions have solved similar problems.

Together, we discuss the request and what it would take to accomplish. We consider whether we have existing technologies that might fill the gap, and we explore possible solutions in the market. From this meeting, we decide how the project would unfold architecturally—whether we would adapt an existing piece of software, develop new software, or put out an RFP for a commercial solution.

Our value engineering meetings also solve one of the key problems that IT organizations struggle with, which is that IT staff often hear about endeavors late in the process. Our approach gets IT involved from the start so that we can participate in vendor conversations, help draft the RFP, etc. We can make sure that important aspects such as security and accessibility are part of the conversation from the outset, protecting the institution without slowing down the process.

5. Identify the value that each proposed project would bring to the institution.
The next step in the process is to come up with a rough estimate of how much time the project will take and how much it will cost. We also assess the value the project will bring to the institution. In fact, we work with project sponsors to assign a dollar value even to the intangible benefits.

For example, one of the improved capabilities we have been rolling out is a campus calendar and event marketing platform that students can turn to for a single, coherent list of all the lectures, sporting events, concerts, and other activities occurring on campus each day. Users will be able to click through to buy tickets, reserve a seat, or receive more information about each event.

The tangible value of such a system is easy to measure. Our crisis response team wants to know everything that is happening on campus, so currently they spend a few hours every day combing through various calendaring applications and other resources to pull together a coherent picture of what is happening that day. When this application goes live, it will do that work for us, allowing us to assess the dollar value of the time the response team will save.

Intangibly, students might attend more lectures and have more enriching experiences if they have a single source to find this information, which would advance our academic mission. How can we express this value in terms of dollars and cents? It is a hard question to answer, but the standard we put to project sponsors is this: If you are in front of a committee of your peers arguing for IT time, what is a good-faith estimate you can use in assigning value to the project? This helps us come up with a rough figure we can use to determine the ROI to the institution in moving forward with the project.

6. Weigh all of this information in choosing if—and when—to move forward.
Besides having casual conversations with division leaders to discuss their needs, we also have a monthly committee meeting with all of them together to discuss and formally decide which IT projects to pursue.

To evaluate project proposals, the governance committee looks at the costs and time involved, and we weigh those against the value to determine the ROI. We also look at the IT teams that have the necessary skills to take on the project and see when they might have availability. We use a visualization tool that we developed to run on top of the TeamDynamix platform to make this determination. Projects that we approve and schedule move out of the dugout and are considered to be "on deck."

7. Create a separate process for smaller projects.
One of the challenges for IT organizations is finding a process for the smaller projects that involve more than a support ticket but will take only few days to accomplish. Because it is not worth going through a rigorous evaluation process for something that only requires a few days of work, these types of projects tend to be overlooked unless institutions have a separate, scaled-down process for advancing them.

We have built a separate process to address these projects and have developed a separate desktop view within TeamDynamix for these requests. We collect less information from the request sponsor—just a title and a description of the problem, need, and benefits.

Having a well-designed IT governance process boosts your chances of success dramatically. Since we adopted this seven-step process, our IT workflow has become much more sane and predictable. I can tell you who's going to be in what room working on what project four months from now—and that would not have been possible otherwise.

---

Jeffrey Toaddy is a Senior Business Analyst in the Information Technology Services division at Miami University of Ohio.