Driving adoption of your project portfolio management system

Introduction

Organizations have suspected for some time that they can improve their project, program or portfolio performance by gathering all project-related data into one large bucket. The software industry agreed, and in the mid-90s the product class called PPM—Project Portfolio Management—more broadly emerged.

Like many software products, offerings in the PPM space range in price and complexity from a skateboard to a fighter jet. The skateboards typically have limited functionality, such as time entry against a project, task scheduling, or perhaps issue management. At the enterprise level, products add resource capacity management, sophisticated reporting engines, personalization, and other features.

In general, the enterprise-class PPM products help organizations:

• Select and prioritize the right projects
• Balance their project demand with their supply of project resources (both money and people)
• Deliver and control their projects more effectively.

Unfortunately, this is rarely simple to do, largely because managing a projectized organization means managing many moving parts (project schedules, resource availability, shifting scope, emerging risks, changing priorities, and so forth). We find many organizations have someone driving a project management office who understands these multi-dimensional relationships, but is frustrated because both higher (sponsors, senior executives) and lower (project managers, team members) stakeholders do not. Helping stakeholders “get it” is an exercise in cultural change, and is one of the reasons PPM initiatives have largely underperformed against expectations.

On first glance, many people attribute these challenges solely to culture. But experience indicates a more subtle, complex set of challenges. Understanding these roadblocks is critical to a successful deployment, as ultimately they drive adoption of the PPM tool. And without adoption, regardless of by whom — executives, directors, program and project managers or team members — the value of PPM cannot be realized.

This paper looks first at why PPM products have struggled for adoption, then groups various challenges into four broad categories, and finally offers some ideas founded in experience to overcome these challenges and help ensure the success of PPM in an organization.

A Couple of Underlying Assumptions

Entrekin (2005) said, “Without understanding the role of projects in driving an organization's maturity and progress toward their goals, they'll be unable to effectively deliver the projects that meet those goals…” The problem becomes apparent when an organization wonders why they never really adopted their PPM standards. Often it is because the cultural change that drives project management maturation has been under-managed. Without carefully mitigating the cultural change, the organization can't build its PM capabilities, nor execute those critical projects that move it toward its vision or “future state.” (Ibid.)

Effective change management also drives adoption of the supporting PPM software. If the foundation of an organization's project capability is its methodology and standards, then PPM software is the steel beam that supports the initiatives that use the foundation. The beam can be strong, but if the foundation is cracked, the beam still falls. This paper is written to help the PPM “champion,” or the person charged with driving adoption of not just the PPM solution, but the lifecycle standardization and capability-building initiative behind it.

This is important because PPM software won't make ineffective standards and lifecycle models better. It will simply provide the means for your project managers to comply with ineffective processes. So don't blame the software, because garbage in (useless data) equals garbage out (useless reports). This paper assumes you have a robust methodology in place already, and that the data you wish to collect is the data you really need.

Pick Your Pain

We see PPM initiatives fail largely for four interrelated reasons:

1. Lack of senior leadership – senior managers aren't effectively engaged, don't drive compliance, and don't lead the cultural change.
2. Underdeveloped management skills – without applicable experience and training, middle managers and project managers don't understand the value and benefits of PPM. This is less about training to use the product and more about professional training and insights.
3. Overly aggressive scope – the organization “bites off more than it can chew” at the outset.
4. Onerous “administrivia” – the methodology, accompanying standards, and reporting requirements are so detailed and extensive, and add so little value, that no one is willing to embrace them.

This paper looks at each reason individually, and what you can do to help overcome them.

Lack of Senior Leadership

The PPM sponsor, whether it's an executive-level officer, a vice president of development, a director of the project management office, or whomever, must be visibly out in front leading the effort. They must understand the benefits of PPM and its supporting tool, and communicate them broadly. If your organization intends PPM to drive compliance with lifecycle standards, it's the sponsor who must say so. They should share the report that monitors compliance, and publicly acknowledge the teams that comply. Similarly, if the goal is to catalogue projects and report on them, the sponsor should share the reports, so the project organization sees the data being used. This is important if the teams are to believe the learning curve is worthwhile, and move along it without rebellion.

This is easier said than done, as few people intuitively understand the benefits of PPM. Yet without such understanding, the organization as a whole will not reap them. For this reason, it's incumbent upon the PPM champion to educate the sponsor, who in turn must evangelize the benefits up and down the organization.

The sponsor must also be prepared to hear bad news with the good. A new PPM system may point out projects misaligned to strategy, and with unexpectedly lax oversight or significantly higher labor costs than anticipated. If the challenges aren't embraced as warmly as the benefits, the organization can't sustainably improve, and undermines their own efforts to optimize performance.

To help senior leadership step up to the PPM challenge:

• DO educate sponsors on their role, so they can play it effectively. DON‘T expect them to realize they even had this role to play.
• DO guide sponsors, so they expect and understand reports coming from the tool. DON‘T expect them to understand the value in any information that doesn't have their reporting currency associated to it.
• DO create reports that show senior management things they haven't realized. Proactively create a prototype and walk it around for feedback. We find a simple pie chart showing the number of projects aligned under each strategic driver to be extremely effective in opening people's eyes. Similarly, for organizations that track time against projects, a bar graph can show time spent on all projects aligned to each driver. DON‘T be surprised to discover how much time is actually spent on low-priority or misaligned work.
• DO champion, deliver, educate about, and evangelize one or two key reports upon which senior management will come to rely. As users learn about those reports, the data supporting them will be maintained and in turn the tool adopted. Make these as important as any other reports critical to understanding the business.
• DO monitor that sponsors look at their reports, even if it's just a simple status report. It's the sponsors’ insistence on reporting from the tool that will drive all projects to use it.
• DO simplify how the sponsor retrieves their information and reports. If the tool has personalized dashboards, this is a good place to use them. If it allows you to limit visibility into tabs, menus or other navigational aids, do so for the sponsor. DON‘T expect them to actually retrieve the information themselves until the value is proven. Run the reports for them, and deliver them personally if necessary until one day they miss the information when it's not there when expected.
• DO insist that sponsors state their expectations that the teams use applicable standards, which you will drive and monitor with the tool. Use the project managers to drive this message down to the teams.
• DO have expectations of your executive leadership, and let them know it. DON‘T let them off the hook.

Underdeveloped Management Skills

The challenge of poor management skills applies on two fronts. The first relates to project management skills; the second relates to the management skills of the people managing the project managers.

Underdeveloped Project Management Skills

Less “mature” project managers unversed in lifecycle management don't see how standards and project management tools make their lives easier. Satisfied by managing the task list in a spreadsheet, they see standards as extra work that doesn't move the project closer to completion, and PPM technologies as Big Brother telling them how to execute with no understanding of the day-to-day challenges.

Why do project managers think this way? Our experience seems to show that it's related more to role-training than experience. Project managers often find themselves in the role because they execute tasks well. Such “execution experts” seek any tool to make their jobs easier. Yet, many successful project-centric organizations insist that project managers don't execute projects — they manage the project's execution. Project managers trained in this perspective may resist adopting PPM software, because they fear losing control. They know projects require a firm hand, and don't want their decisions second-guessed by people not involved in the execution.

To avoid underdeveloped project management skills from becoming too great a challenge:

• DO overcome the project management skill shortfall with specialized lifecycle training, but DON‘T forget that experience is the best teacher.
• DO communicate to experienced project managers how the software enhances their control over the project lifecycle. DON‘T expect them to adopt it simply because they should know better.
• DO give projects a structure by using templates that impose only your standard phases, milestones, and deliverables. This helps project managers begin to understand the interaction of budgets, estimates, resource time, and resource cost at the phase level. But DON‘T take these principles further down the task list until they are ready to try it, and you're ready to support them in it.
• DO train the project managers on how certain features enhance control. DON‘T assume they're all project management theorists who passed the Project Management Professional exam with 100% scores.
• DO remember project managers are creative people. DON‘T let them believe you want to take the art out of project management.

Underdeveloped People Management Skills

The second area of management shortfall is with the people who manage project managers. Regardless of their background (project management or line management), managing project managers requires a basic understanding of how to keep projects under control. While PPM solutions can easily report the actual time or money invested in a project, if the manager doesn't understand what “budget vs. actuals” really tells them, or worse, doesn't even require the data be maintained, then the standards become “binderware” and the software becomes a boondoggle. Therefore:

• DO plan to train the project managers’ managers on the metrics: why they were selected, what they can tell you, how they are calculated, how to generate the reports, and, crucially, how to interpret them.
• DON‘T expect them to find this interesting, easy, or intuitive, nor to see the value in it immediately. This is often something PPM champions must drive over time.

Finally, people who manage project managers need a basic understanding of resource management. As the people who help project managers remove roadblocks, they can't help identify, develop, or allocate resources without knowing how shuffling resources will impact projects individually, and the program or portfolio as a whole. When you're ready to tackle resource management:

• DO carefully explain allocations and illustrate them in a grid as typically found in a PPM tool.
• DO keep it simple. DON‘T expect resource managers to understand, for instance, the difference between being allocated or scheduled unless they come to the role from the project management ranks.

Overly Aggressive Initial Scope

Your initial implementation will almost certainly not be perfect. You'll find process steps, configuration decisions, and data points that just don't fit the needs or the business models of some stakeholder somewhere. Therefore, expect your tool to be highly configurable, and expect to refine that configuration as you become more experienced. Also, as the tool helps your project organization mature, expect the configuration to evolve right along with you.

So, if you're sure to miss the mark at the outset, how do you come as close as possible? Focus first on the top priorities. We've seen organizations characterize their needs into three broad “domains” of:

1. Selecting and prioritizing the right projects.
2. Balancing project demand against the supply of project resources (human and financial).
3. Controlling, executing, and delivering projects more effectively.

Obviously there are features in PPM tools that cross all three domains (resource allocations is one example), but by characterizing the priorities according to their needs, you'll find it easier to engage your stakeholders. This will help drive initial consensus, particularly around the configuration, and make it more likely that the tool that can “grow” as the organization matures.

Regardless of the domain you choose first, it will have a lifecycle model associated to it. Even if the scope is so narrow as to be simply project request and selection, each request represents a lifecycle. And as PPM tools are essentially lifecycle management tools, think in terms of your lifecycle models, or “project processes,” when designing the configuration.

At a minimum, you must identify the lifecycle attributes critical to consistent reporting. Examples may be lifecycle health, phase, or customer for whom the work is being done. And as lifecycles have phases under which you structure tasks, you'll also need to at least identify those phases. This is the source of the consistency needed to report across iterations. You don't need to identify milestones or standard deliverables to still see value.

As regards your current lifecycle models:

• DO take this opportunity to refine and clean up your methodology.
• DON‘T use a PPM implementation as the time to deploy a new methodology. The cultural change that accompanies new methodologies is significant, and it's far more important to digest it before taking on the cultural aspects of PPM.

A Word About Modular Features

Thinking they were being cautious, some organizations have approached PPM thinking, “we're only going to roll out time entry and not project scheduling” or “we'll just deploy standard deliverables, but not the rest of project management.” Although there are some limited aspects of PPM that can be “broken out” separately, by and large, multiple feature sets are required for success. In terms of software, it's the degree to which you leverage features in each module that determines your scope, not the decision of whether to include a module at all.

For example, you may want to deploy time entry and not project or resource management. But if you don't use the resource module, you won't know who spent the time being entered. And without a project, there's no entity against which to charge that time. Because so many aspects of PPM are interrelated, managing scope doesn't mean limiting the functionality you deploy; rather, it means using it only to the degree needed to deliver value without depriving adoption. To manage your scope of initial deployment:

• DO plan on using at a minimum the project “profile,” task scheduling to the phase level, the resource list, and team assignments.
• DO put your phases, milestones, and key deliverables in a template, but DON‘T go down to significant detail. Rather, let your project managers add the detail they need to manage the execution. This gives the project managers control over how they use the software, lets them adopt it at their own pace, and still gives you the consistent cross-project reporting you need to oversee projects in-flight. And be comfortable that it's extremely common for organizations to deploy PPM and still let the project managers manage the task schedule in other, more familiar, tools.
• DO enter time against phases or key deliverables, but DON‘T enter it against lower-level tasks unless two prerequisites are in place: your project managers have the experience to manage at that level of detail, and you have reporting and control needs to justify the extra effort.
• DO add every resource to the database, even if they won't be “users” of your system, so you know what they're working on. DON‘T create a detailed profile for each resource unless you will be searching for available people based on that profile.
• DO consider requiring that all project documents and/or links to artifacts be stored in the PPM software. DON‘T insist on managing project issues there until you're ready to digest more collaboration. Keeping artifacts with the project control data saves time for the team and simplifies internal and external (Section 404, SAS 70) audits.
• DO present only the fields you truly need to drive quality, generate metrics and make smarter decisions; hide the rest. Users will perceive complexity if they see a feature you only intend to introduce in a year or two. Some organizations will use budgets (top-down financial expectations), but hide estimates (bottom-up financial expectations) until they can manage them effectively. DON‘T overwhelm your people.

However you decide to scope your implementation, keep in mind there are small bits of several modules needed at the outset, and that you can dive deeper into a feature set as your organization matures.

Onerous Administrivia

Project managers are busy people, and to them, tracking data for which they see no value is worthless. This is exacerbated when the project manager, who is often more focused on getting the work done than controlling the lifecycle, sees reporting as a chore that detracts from execution. So it's important to weigh an executive's desire for a report against the project manager's time to maintain data for it.

For instance, if your project status reports present “tasks due this week.” is this list evaluated item by item at a weekly program, sub-portfolio or portfolio-level status meeting? If not, you can reasonably consider reporting only milestones or key sign-offs.

An interesting corollary to this point regards project managers who DO focus on lifecycle control. These project managers, who don't execute tasks themselves, stay on top of their projects through understanding activities underway and upcoming. As a result, they typically have information at their fingertips to provide accurate and insightful status reports. In such an instance, the choice of tool becomes irrelevant, so long as it provides the information needed to maintain control.

To reduce unnecessary data administration:

• DO invest time upfront with senior management to define the information they need to drive smart decisions. Engage your business analysts in this effort. But DON‘T immediately recreate all your current reports just because they're what people are used to. You'll be surprised how many reports you can do away with before anyone notices.
• DO train the project manager, program managers or portfolio managers on the data sources for your organization's key reports, the meaning of each metric, and its implications. This helps them manage their projects so as to provide the results you want. DON‘T expect that they'll be aware of your key metrics if executives aren't consistently using them.
• DO insist that team members be assigned to at least the phase level on the task list. DON‘T assign them lower unless it's absolutely necessary. Project managers can still control their plans without putting specific resources on specific tasks for specific date ranges. Unless you have a large project with a dedicated scheduler, you're very unlikely to ever report such detail, and it generally won't help control the project more effectively. So don't waste time capturing it.
• DO assign project roles in your templates, but DON‘T assign specific resources. We've seen companies that have a team of eight or ten people, any three of which may be assigned to a new project. Thinking they would save effort, they assigned the entire team to their template project. Since this template is used to create every project they undertake, the entire team is assigned to every project. As a result, they have no visibility into who is really working on what, or what anyone's availability really is.
• DON‘T let the PPM system expand into a de facto CRM system, despite having so much useful customer-focused information in one place. Doing so raises two risks: (1) you increase unnecessary data entry for the project managers, and (2) you lose accountability for data accuracy once the project ends.

A Few Miscellaneous Tips

With thanks to the organizations with which we've worked over the years, we've learned a few other tips that don't align as neatly under the four categories above. But if they can help drive a successful implementation, they deserve mention.

• DO ensure regular meetings with project management office leadership (or whomever “owns” the PPM) and key stakeholders to:

• Ensure they're using it
• Train them to understand a report
• Show them something new they can do with it
• Show them the value their efforts have created for them and the organization as a whole

• DO train each audience by focusing on what they need to know. DON‘T overwhelm them with everything. Start perhaps with training on managing the details for just the phase and milestone or deliverable level tasks. Follow that up later with more detailed task management training, or perhaps with time entry training.
• DO remember each audience has different training needs. The project managers may need to know how they'll approve time cards; executives just want to find the dashboard.
• DO find ways for the project managers who have embraced the tool to mentor others. Leveraging your user community is a powerful way to build adoption among more users, and grow your project managers.

It Can Work

No one said implementing and adopting a PPM system would be easy. The need for standards when people don't agree drives dissention; the need for monitoring makes people uneasy; and sometimes the need for leadership is simply ignored because it's not available. But the value PPM brings, from better decisions to better control over expensive investments to better allocation of resources and other benefits, make the effort worthwhile.

Fundamentally though, PPM is just a big bucket for your project-related data. And if that data isn't used to:

• Balance project demand with supply of project resources,
• Select and prioritize your projects or
• Deliver and control your lifecycles…

…you can reasonably question why you're capturing it in the first place.

There is no question that PPM systems can present an adoption challenge, and this paper explored several reasons why. To summarize the findings, focus your attention on four broad goals to increase buy-in from all your stakeholders, and drive to adoption:

Expect your leaders to lead—Help your senior leaders understand their roles in PPM's success. Communicate early and often about their needs, and about what you need from them to make your initiative successful.

Help your managers manage—Plan to develop your organization's management skills. In particular, plan to train project managers and managers above them, in three important areas:

1. What the software can do for you (PPM theory)
2. How the software does that for you (applied PPM)
3. How to make the software do it for you (user training).

All three aspects must be addressed if you're to fully leverage your PPM solution.

Keep it narrow—Reel in your initial scope based on your organization's capabilities. And focus on the worst pain first.

Keep it narrow—Don't let people get bogged down in valueless work – work to understand why someone is asking for something, whether it's a report, a time entry policy, or maybe a new data field. Every time someone requests something, it will almost surely mean more work for the project managers. If it's simple and makes life better, people will more than just use it — they'll actively embrace it.

Finally, keep in mind your project managers are the one group whose support you absolutely cannot do without. By recognizing that a new PPM solution is more about cultural change than technology, you can drive the adoption you need to balance your project demand with your supply, select and prioritize the right projects, deliver and control them more effectively, and ultimately move your organization to its “future state.”