By Eric Thomas
Your leadership warns of severe budget cuts. You are fairly confident that you have redundant systems and technologies in your infrastructure, but that is difficult to verify because your internal repository of IT assets is incomplete. Your boss wants more reliance on mobile, cloud and other wireless connectivity to customers, but you are unsure about which new pipeline initiatives best-fit those objectives. None of your service-level agreements meet expectations. You don’t know the status of current projects, or whether any will yield a positive ROI. If these conditions seem familiar or apply to your organization, you are not alone. It’s time to improve your IT Portfolio Management (IT PfM).
Organizations in the federal, state and commercial sectors languish under a poorly performing IT PfM process. The previously described workplace conditions aren’t contrived; they are real-life symptoms. Critical strategic decisions are sometimes reached based on the strongest voice in the room, not by the soundest analysis of a new proposal. Worse still, some decisions go unresolved because the process isn’t documented or responsibilities are not delegated. This can result in a mix of unsponsored or unjustified IT investments.
IT PfM is intended to solve these problems, and applying it expertly need not be difficult, expensive, technology centered or time-consuming.
Before exploring the process, it is important to define the process of IT Portfolio Management through which organizations evaluate and ultimately make decisions about existing or planned investments in IT.
Improving your IT PfM process can be as simple as gathering data, determining priorities, evaluating options, making decisions and, ultimately, implementing those decisions. You receive a holistic view of available investments, score them individually against criteria deemed appropriate and determine which IT investments should be supported or not.
Step 1: Validate Your Portfolio
This step can pose significant challenges. You will have to identify unapproved ideas or prospects; approved projects which may be in varied stages of planning, development or implementation; and existing assets such as hardware, software and son. As data is gathered, the following questions may arise:
· What counts as a system? Consider whether the system in question has its own licenses, service level agreements or standard operating procedures. Also consider how much money is invested in the system, and how many users would be affected. Use those criteria to cull the less important systems.
· How do I find all of the systems? Although tempting, don’t shut everything down and listen for the screams. Again, look for existing documentation, such as service-level agreements and standard operating procedures, but also check less obvious sources like your help-desk tickets and security or privacy information. Also ask your technologists. Most importantly, don’t let the quest for perfection (identifying 100 percent of the portfolio) be the enemy of good (identifying the vast majority of the portfolio).
· How is a project defined? This distinction isn’t critical. It is more important to know whether the project is active in production, currently advancing through your system development lifecycle or just a proposed idea.
· Do I include inexpensive projects or systems? All projects have some cost, if only resource time. If unsure, add it to the list.
Step 2: Determine Evaluation Criteria
This step is the most strategic in the process. Here you will determine what attributes are most important to capture for each investment or potential investment in the portfolio. Since the attributes will eventually provide the basis for decision-making, selecting the right attributes is vitally important. The sample list below is a good starting point:
· Project Level: Cost variance, schedule variance, projected ROI, schedule risk, cost risk, and time to deployment
· Strategic: Alignment to mission, alignment to technical direction, customer satisfaction
· General: Total cost of ownership, ongoing support costs, FTEs required to support, remaining technical support from vendor, planned technical obsolescence, dependent projects and systems
· Classification Schemes: Mandatory/discretionary, operational improvement/operational maintenance, application/infrastructure/information, transactional/informational/strategic/infrastructure.