Another Look at Project Portfolio Management
© 2004 By Donna Fitzgerald
A year ago, I edited a magazine issue on Project
Portfolio Management (PPM). At that time, our discussion was
focused on whether or not a good PPM process required tools and
infrastructure
or simply a decisive mind set. The consensus of all of the authors
was that without an infrastructure, even the most decisive organization
would eventually lose focus and begin to sub-optimize its portfolio.
Looking back over the last year I’d say that all of the columnists
were right, but our comments failed to address the single greatest pain
point for most organizations. Correctly matching resource capacity to
planned projects seems to be the problem that just doesn’t have
an easy solution.
According to conventional PPM wisdom the solution to this problem should
be obvious. Initiate fewer projects. But that’s advice most companies
don’t want to take at face value. The most frequent counter I hear
is that if project estimates are correct, and the organization has the
people, why drop projects below what the organization “should be
able to handle”? After all, the argument goes, given tight IT budgets,
no one can afford to have people sitting around doing nothing just to
solve an occasional peak loading problem.
PPM practices, at their core, focus on strategic fit, return, and risk
across the portfolio. Resources are a factor in the analysis, but good
portfolio analysis doesn’t really concern itself with details liked
named resources. At the highest level the goal is to look at what projects
should be done and why. If the project list that achieves all the company’s
goals can’t be accomplished because of lack of resources, then and
only then should the company decide whether to add more resources or scale
back the list of approved projects.
Some software vendors imply that PPM can be more efficiently done if
detailed resource information is available to executive decision makers
but from my perspective that simply wastes time asking executives to make
decisions that are better made at lower levels. It’s for this reason
that I have recently come to advocate a concept I’m calling Scalable
PPM. By this I don’t mean to imply that all generic PPM practices
can’t work at any level of the organization. My use of this term
implies that there are different things that need to be done at each level
and that the correct view of PPM is that it works best when the focus
is simultaneously on both the top-down process and the bottom-up process.
• Top •
Executive Responsibilities
Beginning with the top-down process, executive management needs to take
responsibility for the following activities:
• Evaluate the list of projects
• Confirm alignment
• Determine level of acceptable risk
• Define value threshold
• Confirm timing
• Confirm high-level resource capacity
• Prioritize Projects
• Bucket projects by Line of Business (LOB), Product, or Function
• Eliminate the bottom tier (that means cut, cancel and kill projects)
Once this review has been completed, the prioritized lists, segmented
by LOB, product, or function, can be given to the next level of management
for their review. Segmenting the portfolio by function or LOB has a number
of advantages. Most companies segment their IT resources by one of these
categories, so that even if resources appeared to be available at a high
level, they might not be there at the detailed level. It also ensures
that the responsibility for successful implementation rests with the people
who are on the front lines.
Since the focus of this article is on resource capacity, it’s important
to highlight that one problem with delegating a “pot of money” down
to the next level is that there is a strong possibility the organization’s
resource capacity will be artificially constrained, because the “best” resources
may not reside in the organization that has the highest priority projects.
Since the old concept of zero-based budgeting (which allows base-line
budgets to be reset every year) never gained much traction outside of
the consulting community, one infrastructure change that will facilitate
good PPM is something like a loose center of excellence, where resources
are available to move across functional lines.
I’ve seen different companies implement this idea in different
fashions. At Oracle we centralized some of the more highly skilled resources
into a formal center of excellence and then matched the resource to the
project’s needs and priority. When I was at Intel we solved that
problem a little differently. Rather than centralize any of the resources
organizationally, we created a virtual labor pool through a policy of
frequent transfers. An annual ranking and rating of all employees ensured
that highly ranked individuals were moved from group to group every year
or two in order to meet the ever changing needs of the organization.
• Top •
Another factor to consider here is that people really aren’t plug
compatible “resources,” even though we often talk about them
as if they are. As a PM, I can attest that a team of 100 people might
be a recipe for failure whereas a team of the right 15 people may be able
to succeed against all odds. The more closely people and projects can
be matched, the higher the probability of success. It’s actually
one of the reasons I would lean toward the “Intel” system
as being the more versatile technique. The ranking and rating is always
based on current performance which prevents some of the inefficiencies
of building an organization that risks becoming a “caste system”.
The role of a conventional center of excellence I think should be limited
to a very few people who can operate at the mentor or Guru level and whose
presence can elevate the performance of the team as a whole.
Line Management Responsibilities
Assuming that the organization has established some sort of flexible
staffing policy, the prioritized list of projects should then be handed
to the next level of management for implementation. Responsibilities at
this level include:
• Revaluate list of projects
• Confirm resource availability
• Confirm cross-project dependencies
• Evaluate maintenance and enhancement efforts
• Establish monitoring procedures
• Project steering committee
Reevaluating the projects at this level is not intended to give line
management an opportunity to completely readjust the portfolio. Rather
it is intended to recognize the fact that executive decisions made at
the 50,000 foot level now need to drop down to the 5,000 foot level in
order to have any chance of getting implemented. Focusing specifically
on resources this is the level were the matching of people-to-project
that we discussed above happens. This is also the level where the organizational
impact of maintenance and enhancement activities needs to be accounted
for, since it is standard practice in most PPM methods to exclude these
activities from executive review.
The first process change that needs to happen at this level in order
to more tightly align resource capacity to project is the mapping of all
enhancements activity into a product roadmap and the commitment to schedule
this work according to a product release plan. The impact of this one
change is significant. A product road map offers increased visibility
to everyone in the organization which will allow for the prioritization
of enhancements (which can’t happen if they’re received on
a piecemeal basis) and for COTS systems, it makes it easier to avoid duplicating
enhancements that the software vendor is intending to provide.
• Top •
The second way to control the resources consumed by M&E is to embrace
a more agile form of software development. By doing frequent releases
more of the product and by doing continuous testing, the number of post-implementation
bugs and required enhancements should go down significantly. After all,
there will be more people to work on new projects if they’re not
consumed by supporting everything they’ve worked on in the past.
Project Level Responsibilities
Assuming the right decisions have been
made at the executive level and that line management has implemented the
right organizational and support
systems, the final element of solving the resource capacity problem
lies with the project manager and/or the immediate department manager.
The bottom line is it’s the project manager’s responsibility to
know what’s going on with her staff. If a team member is completely
overwhelmed because he has too much work, then the problem needs
to be fixed, either as a one-off solution or at the structural level,
depending on the source of the problem.
This returns us to one of the reasons I am advocating the concept of
scalable project portfolio management. When a structural problem (we screwed
up and started too many projects) is identified at the lowest level it
needs to move back up the organization until it can be solved. Depending
on the culture of the organization, carrying this message back up the
line is the job of the project steering committee (of course the PM could
do it herself but some organizations still believe in shooting the messenger.)
Conclusion
A good PPM process does require structure, but from my perspective,
that structure isn’t necessarily dependent on software tools or a fully-deployed
project management processes. By taking a scalable approach to PPM, each
level of the organization can concentrate on making decisions and setting
up the management structures that will encourage the visibility and flexibility
an organization needs to have to obtain results.
After all, the most expensive
PPM software in the world coupled with the best project management
processes still won’t help if the organization continues to approve too many
new projects and fails to support those already underway. By
adopting a PPM process that focuses and empowers people to solve the problems
in front of them, I believe most of the resource capacity problems
that organizations are currently experiencing can be solved.
• Top •
Editor's Note: Donna Fitzgerald is asapm's past Director of Education,
and in addition to managing her own Project Management Consulting firm, she
runs NewGrange, asapm's official list serve, the "hottest place
on the web to discuss project management", at www.newgrange.org.
|
