PORTFOLIO MANAGEMENT FOR SMALL ORGANIZATIONS: RIGHT-SIZING

by Donna Fitzgerald, Senior Consultant, Cutter Consortium

Based on my discussions with managers throughout the years, it appears that when an IT group reaches a capacity of roughly 20 to 30 people, the alignment between people and incoming work becomes difficult to manage. At this point, applying project portfolio management best practices makes sense, specifically by creating a functional system roadmap and aggressively managing resource capacity and utilization.

Small IT organizations generally function on a "service bureau" basis. Demand comes in and reaches the limits of available resources; demand gets satisfied on either a first-in-first-out model or a squeaky-wheel prioritization model. There's nothing particularly wrong with this approach. Important projects always jump to the front of the line, and bad ideas are usually handled quietly with a back-pocket veto. The system can balance on the edge of chaos for an extended period of time until someone quits or functional areas request one project too many, and then everything slides into a self-reinforcing negative-feedback loop of too much demand, too few resources, and slipping projects.

For a large company, the general advice at this point would be to focus on the project portfolio and align everything with the company's strategy, then eliminate projects until the portfolio and available resources are in relative alignment. But small companies usually don't have lots of large projects to focus on, and it's necessary to prioritize demand on a functional basis, focusing specifically on system enhancements and small upgrades.

Getting a handle on a lot of small work requests can be daunting. A friend of mine refers to the process as "projectizing everything," right down to an eight-hour service request. It's important, though, to understand that the process of "projectizing" doesn't mean imposing a high-overhead structure on a work request. It just means listing it so that judgments can be made and priorities assigned.

My approach to this process is to begin by right-sizing the portfolio and then fine-tuning it in relation to a real work plan for members of the department.

For the sake of simplicity, I'm an advocate of what I call "balanced scorecard-lite." Once the IT department has 20 or 30 resources, it makes sense to begin sorting work into high-level buckets that are aligned with business objectives and not just functional-area demand. In this case, full implementation of the balanced scorecard approach probably isn't warranted, but simply articulating a single financial goal, a business process goal, a customer service goal, and an innovation goal provides guidance on how to approach the project to achieve the highest return.

Once high-level strategies are determined, the current list of work can be triaged and a system roadmap can be defined that cross-maps the strategy and the functional areas (finance, market, etc.). By developing a system roadmap, everything is placed on a list and planned within the context of a specific release in the same way that commercial software companies use.

For example, a small company could decide that its financial goal for the year is to improve its days sales outstanding number in order to have more cash to fund internal growth. The customer- centered strategy might be better-quality postsales support, while the company's internal process might be improved document management, and the innovation goal might be to create a better collaborative environment throughout the company.

For anyone who's actually experienced this process, I'm sure that I've now struck fear and trepidation in your hearts. To quote a CIO acquaintance, "I had my plate full before [the company] set strategy; now they've added 32 projects based on their strategy. We were overwhelmed before; now we're under water."

The simple answer is that everything goes on the list and is evaluated against the four strategic goals and the one operating goal (keeping the lights on). That means nothing gets done unless it enables strategy or has a higher value. Doing so doesn't require anything more sophisticated than an Excel spreadsheet and a willingness to ask about the value of something in relation to what's important to the company.

Take a classic example of a request to automate a manual process. It currently takes one person-day a month to do the work, and it is estimated that it will take 20 person-days to develop the solution. In lots of shops, this would just go on the list and end up having a 60-day project duration, since no one can work on it full time, and the overall hours would end up approaching 35 days rather than the estimated 20. By using (1) alignment with strategy and (2) a system capability map, it's possible to make a much better decision. If the project is in support of days sales outstanding (it's a project system that will allow for better tracking of costs and therefore better invoicing), it goes on the list. If it's something that isn't a regulatory priority or aligned with another strategic goal or isn't a capability that supports an important activity, it goes on the we'll- get-to-it-later list.

The secret here is to understand that this is an exercise in prioritization, but it's not the final prioritization. The goal is to say yes to some things and no to others. In a small company, information is still directly available. If Susie wants the process automated, it's generally possible to go to her cubicle and look at what she's doing. It's also possible to ask the question, is the work in and of itself valuable enough to do, let alone to automate?

Once strategies are set and a system roadmap has been fleshed out, the next step is to ensure that it's assigned to the right resources at the right time. My guess is that asking people to do anything once they feel completely overwhelmed automatically subtracts at least 20% from their productivity. To get control of the situation, it is necessary to manage not only demand but also capacity.

-- Donna Fitzgerald, Senior Consultant, Cutter Consortium