Home

More Papers

Project Portfolio Management Tools: Which Approach is Best? Part 3: Tool Costs and Risks

Printable version

Part 1 identified available tools for project portfolio management and Part 2 described key tool differences. This part provides information on PPM tool costs and purchase risks, and offers advice for preparing for a tool purchase.

As with other investment choices, the selection of a PPM tool should be based on tool costs, anticipated tool benefits, and the risks involved.

Tool Costs

When comparing tool costs, remember that the price you pay for software is only one component of the total cost of ownership (TCO). Cost components impacted by tool choice include software license or subscription fees, software support and maintenance fees, costs associated with software customization and implementation, data transfer costs, hardware and infrastructure costs, and training and change-management costs.

Software License and Subscription Costs

For standalone and on site server applications, vendors typically charge a one-time fee to grant a perpetual license for the software. The price may be fixed, dependent on the features or modules that are "unlocked," or based on the number of stations or users accommodated. Some vendors charge a separate fee for a database license. Tools with more features, that support more activities related to project and resource management, or that provide greater analytic power tend to cost more, but the more expensive tools are not always more capable. License fees range from a few thousand dollars (for the simplest desk-top applications) to half a million or more for some comprehensive, large-scale, enterprise-level solutions.

With SaaS, most vendor costs are bundled into subscription fees, but fees may increase based on extra features like mobile and offline access, industry-specific functionality, storage capacity beyond some limit, and premium help desk support. SaaS fees are mostly priced under $100 per user per month and may vary depending on each user's level of use. Like license fees, subscription fees are set to enable the provider to earn a profit—although the upfront costs for SaaS are lower than for a comparable on site deployment, payments in out years are likely to be higher.

An Economic Analysis of PPM Tools

An independent research firm compared the economic costs, risks, and benefits of PPM deployment options. The example assumed a fairly large organization (250 users) seeking a tool to formalize existing PPM processes, with scope limited to IT portfolio management. The data was obtained largely from interviews with providers and customers and relates to 8 comparable "enterprise-level" PPM tools (relatively comprehensive tools that include project and resource management capabilities — 4 on site and 4 SaaS).

Total costs of ownership were estimated to be initially lower for SaaS, but by the third year, cumulative costs for the two options were very nearly equal (roughly $740,000).

Total Cumluative Costs ($1,000's)

PPM benefits, which included fewer project failures and overruns, faster project completion, fewer low-value projects, and improved PPM process efficiency, were slightly higher for SaaS based on an assumption of quicker implementation.

Cumluative Benefits ($1,000's)

The two options produced similar and, despite their relative high costs, excellent ROI's— greater than 250%.[2]

Software Support and Maintenance Costs

On site applications also typically include an annual support and maintenance fee (usually 15-25% of the net license fee) that provides the customer with on-going vendor support and normal software upgrades. Although the fee may be described as "optional," few organizations would be wise to do without vendor support. In addition, of course, on site applications generate in house site costs, including time from a software administrator.

Software Customization and Implementation Costs

Vendors provide consultants to design or configure the tool, conduct tests, assist in the design of PPM governance and process, and otherwise support the implementation of their products, all of which can add to what the vendor charges. Although software configuration is typically included within the license fee, asking the supplier to customize computation algorithms, interface with other software, or provide special displays or reports can add significantly to the price tag. Internally, there is the cost of resource effort to work with the vendor and to manage the implementation. Since you will want to engage your stakeholders in the PPM design, internal time commitments can be substantial. Internal implementation costs are likely to be the single, largest cost component.

Hardware Costs

In some cases, hardware upgrades (e.g., additional servers) may be needed to run the software. This is most likely to be the case for enterprise or suite applications wherein PPM is just one part of the capability being acquired.

Training Costs

The amount of training required depends on how many people are involved in the process, your current level PPM understanding and skills, the PPM approach that you select, and the complexity of your PPM software. In addition, your training costs will depend on the training delivery mode (e.g., train the trainers). As you'd expect, training costs are significant initially (e.g., 5-10% of the total), but should decline significantly after the first application cycle.

Tool Risks

There are two main risks associated with the acquisition of PPM tools: adoption risk and productivity risk. Adoption risk refers to the possibility that the organization will end up not fully utilizing the software-there may be a prolonged delay, scope of use may be less than expected, or the software might be abandoned. Choosing a tool that does not really address the needs of the organization and inadequate executive support along with stakeholder resistance are the main sources of adoption risk. Productivity risk refers to the risk that the benefit per dollar of cost incurred will not be as high as it should be. If the software does not provide useful or accurate information and recommendations, if it doesn't provide functionality that is needed, or if it ends up costing more or is more difficult to use than expected, the software will be much less productive than it should be.

Poor productivity, of course, can and often does lead to abandoning PPM tools. Experience shows that many organizations replace or make major upgrades to their PPM software within a few years of initial implementation. This is not bad so long as the tool payback period is short and tool replacements do not lead to the need for wholesale process redesign, large data transfer costs, and major retraining. Take care in the initial decision to avoid having the repeat the cost cycle later.

A key consideration for assessing adoption and productivity risk is tool flexibility. Flexibility refers to the ability to adjust and modify the solution. Tool flexibility reduces adoption and productivity risk because the solution can be modified and refined over time and as information and needs change. Aspects of flexibility that are relevant include technical flexibility (ability to integrate with other systems), scalability (ability to handle more projects, more users), and analytic flexibility (ability to change and refine models and algorithms to accommodate new project types, changing business conditions, and learning). Flexibility is a key virtue, especially for organizations in fast changing, uncertainty, and dynamic environments. A flexible solution helps defend against unforeseen risks (e.g., the imposition of external requirements for project valuation or prioritization) and enables the organization to realize opportunities (e.g., by answering new questions) that may not yet recognized.

Stand-Alone versus Tool Suite

On the question of stand-alone tools versus tool suites, the major advantage of a suite is avoidance of data transfer problems—creating interfaces for integrating products from different vendors can significantly complicate installations. Another plus—tool suites support a "big-bang" approach to tool implementation. If the organization can afford it, a suite can enable the fastest path to achieving a wide range of tool benefits. And, the more you spend with a vendor, the more opportunity you may have to negotiate price discounts, training, and software customization.

Focused PPM tools, on the other hand, generally lend themselves better to phased implementations. If the interest in portfolio management is localized within a particular business unit, then it may be far easier to generate the needed internal support if the PPM tool is selected to meet the specific, limited needs of that unit. Also, the price of buying into a suite may not be affordable, and you may not want to replace your legacy software. Acquiring focused tools enables a "best-of-breed" approach. Vendors that focus have the opportunity to excel in their respective specialties. Furthermore, small vendors often provide better business-partner service and attention, and their tight-knit user groups ensure that identified bugs are fixed quickly.

Understand Your Needs

Choosing the right PPM tool requires not just knowing what tools do well and not so well, but, also, knowing what you want. Do a readiness assessment, and ask yourself these questions (and do it before you begin your search for a PPM tool):

PPM maturity level. How mature are we currently with regard to the foundation of practices and capabilities needed to support PPM? What level of PPM advancement is it resonable at this time to aim to achieve?

PPM understanding. Do we have a reasonable level of understanding of PPM and the steps for building PPM capability? Do we need training from internal or external PPM experts?

Executive buy-in. Am I going to get necessary executive support to implement PPM? What level of funding, people and time can I expect?

Project and process management. What are our current project and portfolio management processes? What tools do we currently use to support these processes? What works well and what doesn't?

Business needs. Do we need formal project prioritization (because we seem to be conducting too many or the wrong projects or because projects aren't generating their promised benefits)? Do we need help with budget allocation (because the allocation across activities or business areas is wrong)? Do we need better project oversight and issues tracking (because projects frequently fail or go over budget)? Do we need resource balancing (because people are poorly utilized)? Do we need improved communication and collaboration?

Governance. Do we have roles and responsibilities identified and defined (including executive, portfolio manager, project managers, software administrator, etc.)?

Prioritization framework. Have we defined the framework for evaluating and prioritizing project proposals and for measuring the value derived from projects? For instance, what types of benefits are created by the kinds of projects that we conduct? What metrics and models should be used to quantify these benefits? Is project risk or project-deferral risk important? How should project value be adjusted based on risk and our organization's risk tolerance?

Scope. What is the appropriate scope for PPM rollout? Will I pursue a phased approach, or a one-time change?

Organizational culture. How prepared are we to adopt PPM principles and processes? How much change is acceptable? Will senior executives accept priorities based on logic, and how will they react to an environment wherein they will be expected to justify deviations from tool recommendations?

Automation. What part of the PPM process must be automated? Draw a box around it and create a clear statement of what the software must do.

Technical. What are our technical requirements? Do I have the required network, hardware, and related software to implement the technological base needed for a PPM tool? What import and export capabilities are needed to communicate with the data in your other systems? Are there special requirements, for example, does the tool need to accommodate the Japanese language?

Selection criteria. Have we established appropriate, realistic, measurable criteria for evaluating candidate tools?

Before shopping for a tool, design your PPM process. Then test it. Make sure it works for your projects and your organization. If that means delaying the purchase of a tool for a bit, so be it. It is better to manually manage a good process than to automate a bad one.

Do Your Homework

Having a clear idea of your requirements is the first step. It is also important to understand what the key weaknesses are of current generation of PPM tools, particularly with regard to being able to accomplish the fundamental goal of identifying the project portfolio that creates the most value for your organization. This is the topic of Part 4 of this paper.

Notes

1. Jeff Monteforte, "Making Sense of PPM Software," CIO Update, May 17, 2005.
2. Craig Simmons, "The ROI of Project Portfolio Management Tools," Forrester Research Inc., May 8, 2008.
3. Adam Bookman, "Project Portfolio Management: Three Dangerous Myths," CIO, February 17,2010.
4. Reported by CA Inc., "CA PPM Proejct Health Check," a research study conducted by Loudhouse Research, February, 2010.
5. "Magic Quadrant for IT Project and Portfolio Management," Gartner, 15 June 2007, R2351 09282007.
6. Roger Bly, "The Next Wave," Gantthead.com, November 15, 2006.

Part 2: Tool Differences

Part 4: The Weak Link