For more slides and tutorials visit www.p6academy.com Source: Collaborate 14

1. COLLABORATE 14 Copyright ©2014 by Diana Hanna Page 1
Eating the Elephant: Portfolio Management One Step at a Time
Diana Hanna
Nu Solutions Consulting
Summary
Step by step accounting of the reasons and decision processes for implementing a set of Portfolio
Management processes using OPPM, describing pros and cons of various approaches with examples
from actual OPPM implementations.
You Know You Have to Do It
Understanding when the time is right for Portfolio Management
Portfolio Management is a set of processes that organizations can use to manage the selection,
funding, and subsequent monitoring of projects or activities. The level of formality can depend on a
number of factors. Eventually an organization will recognize the need to implement some aspect of
Portfolio Management practices.
Recognizing the symptoms - In the absence of Portfolio Management processes selection
processes are erratic (projects are often chosen subjectively); objective criteria is not well defined nor
aligned with business goals; and delivering what was promised is rarely assessed and confirmed.
Understanding why you have to do it – Generally people within an organization want to select,
fund, and deliver the appropriate projects for the organization. However, unless there is an agreed
and consistent approach, even the best intentions can go awry. If your organization has come to the
point where groups have taken matters into their own hands, and have devised varying ways to
provide the structure of Portfolio Management, then now is the time to formalize these processes.

2. COLLABORATE 14 Copyright ©2014 by Diana Hanna Page 2
Before You Even Start
Assessing your organization’s readiness
Identifying the business problems – It’s important to make a candid assessment of the overall
comprehension of the business problems that exist due to the lack of Portfolio Management. If upper
management doesn’t understand – it will need to be a grass-roots approach. If the problems are
recognized by upper management, but no one else, the top down approach will need to be taken. If
no one understands except for a few crusaders, then the approach needs to be very specific and
focused.
Typically, the choice is either to choose a phase in the Portfolio Management process which is either
already in practice (and thus a transition to formal structure will be relatively easy) or in extremis (and
the serious problems that are happening can no longer be tolerated).
Finding the pockets of solutions in your organization – In any case (with an in-place informal
practice or a situation in extremis), someone in the organization has usually already thought about the
business requirements, and have put something in place. These are the groups with whom to start the
first discussions.
Choosing the appropriate application – Choosing the underlying software which will enable the
Portfolio Management processes is an important decision. This presentation is based on the use of
OPPM, primarily due to its robustness and configurability.
A key factor in the decision is that Portfolio Management is a set of processes, sometimes complex
and rigorous, which require process control, decision support, defined and enforced roles and
responsibilities, a database, an analysis engine, multi-user support, and other facilities.

3. COLLABORATE 14 Copyright ©2014 by Diana Hanna Page 3
Although reports are important, Portfolio Management is more than reporting – it is the enablement,
enforcement and tracking of a series of human interactions and decisions based on a set of business
rules unique to each organization.
How Hard Could It Be?
Making the commitment to proceed
There are two aspects of committing to a Portfolio Management implementation – the impact of
business change, and the implementation project itself. The business change is the most important
element to consider. No matter if the project is a grass-roots, a top down, or a crusader approach, the
business change will be significant. Therefore, at least one member of the management team needs
to be aligned with the project.
Estimating, budgeting, and managing expectations – Like all implementation projects with a large
business change aspect, very strong and experienced project management needs to be in place.
Cost estimating is variable, depending on what will be implemented, but the budget should always
contain a generous contingency.
Managing expectations is controlled through effective communications. It is important to have early,
consistent, and very clear messaging. Again, top management alignment is important (if possible),
otherwise, an individual with organization-wide respect can be very persuasive.
Eating the Elephant – how much to take on and when – Implementing Portfolio Management, like
eating an elephant, must be taken in small bites. Choose ONE area to address, based on the urgency
of the business requirements. On a blank slate, starting at the beginning with Ideation (proposing
initiatives) is a good choice.
Who’s In - Who’s Out
Choosing the participants
The first participants are those involved in the implementation project. One common mistake is
assuming that since enabling Portfolio Management is based on a software application, the IT
department is chosen for the implementation. To reiterate, this is a mistake.
Portfolio Management is a process driven business solution enabled by software. Therefore, the
majority of the project participants need to be from the business areas that will be involved in Portfolio
Management. Of course there are technical staff involved, installing the software and hardware, and
configuring the application to support the process. However, the ratio of technical to business
participants can be 1 to 5, or higher.
How to represent everyone from the top to the bottom – No matter which part of the Portfolio
Management process is delivered first, all levels of the organization should be represented. To
facilitate this, a set of different roles and groups are established. Typically, from the top, is the:
 Executive Sponsor
 Steering Committee (senior management providing guidance to stakeholders and resolving
high-level issues)
 Stakeholder Group (business users and subject matter experts providing the business rules
and detailed design guidance)
 Users Group (a small group representing the larger end user community)
 Business project members (business users that are seconded to project part time)

4. COLLABORATE 14 Copyright ©2014 by Diana Hanna Page 4
 Implementation specialists (subject matter experts on the application, with Portfolio
Management and business experience)
 Technical roles
Choosing the right contributors – After the various participants groups have been agreed, the
individuals are selected. These individuals must be able to contribute the time required for the
particular role; and in the case of absence, have a delegate (already briefed) to fill in for them.
Storming, Norming, Forming, and Performing
How to get along with anybody and live to tell the tale
Groups which contain individuals with a mixture of skill sets, experience, opinion and attitude can
often achieve the best results. Having a group of early adopters is not a good idea. Groups containing
both early adopters and skeptics, but preferably not individuals overtly hostile, could presage
reactions by the larger organization later. This is beneficial for circumventing business change
problems.
Business Change Management – your #1 priority, right? – Managing business change is a
complex process and is often dependent on unique human relationships within and across the
organization. Effecting the business change must be in the forefront of the introduction to Portfolio
Management – and also be part of every task and action performed by the implementation project.
Maintaining effective communications – Establishing a communication plan early, continually
monitoring its effectiveness, and adjusting as required helps to ease the natural resistance to change.

5. COLLABORATE 14 Copyright ©2014 by Diana Hanna Page 5
How to Say No and Really Mean It
Scoping and Requirements Management
Managing expectations is always key; but interestingly, once users, stakeholders, and casual
observers begin to understand what Portfolio Management is all about, they can be like kids in the
candy store. This makes things difficult for the project manager, especially when the stakeholders and
sponsor are hoping to just ‘add one little thing’.
Establishing scope and boundaries – To help ease the pain of seemingly always saying No to
scope creep, a very clear and detailed scope document needs to be defined, circulated, and agreed
by all key participants. This should be done as early as possible in the project, before everyone
discovers the exciting features and what it really means to them personally.
Eating the Elephant – redux – The problem is that once the Stakeholders and Users Groups are on
board and begin to really think about the design and implementation of the solution, their
comprehension expands exponentially. Discussions on the ‘Art of the Possible’ abound. Gently
reminding the team that the basics need to be done first, and remembering that there’s an elephant in
front of us can help contain the scope.
Data – what’s all the fuss about? – and other gotchas
Unexpected hazards and obstacles
It is import to understand the data requirements to support the Portfolio Management process as early
as possible. Using the rule of thumb that less is more, take small steps, and wait until one set of major
functionality is stable (both technically and in end user take up) before adding another set of
functionality.
The infamous historical data load - Consistently, the most problematic area when implementing an
application that needs to take on data is the historical data. Almost every Portfolio Management
implementation is taking on historical data that has been managed in a variety of ways – Word
documents, spreadsheets, Access databases, Lotus Notes, or custom written applications on any
number of database back ends, and in varying combinations.
Whenever possible, try to start with clean data slate, and challenge any requirements that it will be
‘nice to have’. If that is not possible for business reasons, start the data analysis phase very early,
and test thoroughly.
Programs, Projects, Sub-projects – oh no! – Portfolio Management (in this context) is typically a
project-based architecture. However, a thorough understanding of how projects are grouped is
necessary when designing the way the Projects items will be managed. This is a case where planning
for the future can be helpful.
Connecting to other applications – let’s just take it slow – The Portfolio Management application
will typically join the organization’s collection of already existing project and financial management
applications. Design aspects should be considered in advance (naming conventions, data ownership,
data content formats). However, actual linking or integration to companion systems should typically be
done in a later phase.

6. COLLABORATE 14 Copyright ©2014 by Diana Hanna Page 6
If You Build It They Will Come
Establishing a series of quick wins, instead of one big bang
The age old problem with the big bang approach is that by the time the solution is delivered it’s
already out of date. Conversely, a series of quick wins can overwhelm users because things seem to
be changing all the time. Timing of releases and delivery of functionality is taken on a case by case
basis, and should be by agreement with all involved.
Agile vs. Rapid prototyping vs. Waterfall – The beauty of using OPPM for a Portfolio Management
solution is that it is very easy to rapidly prototype with stakeholders in a collaborative environment.
The keys being ‘collaborative’ and ‘stakeholders’. The Agile development approach is difficult to
achieve in the business environment, although aspects of it are part of rapid prototyping.
Some of the elements of Waterfall development – documents stating the scope, requirements, design,
and technical specifications – are necessary and should be produced. However, unless mandated by
an organization’s application delivery requirements, the waterfall approach is not necessary.
Engaging the Stakeholders – the unknown secret for success – The true secret to success is the
stakeholder and user engagement throughout the project. As the various users begin to take
ownership of the portions of the process they use, the overall solution begins to embed itself in the
organization.
Belts, Suspenders, Parachutes and Safety Lines
Testing, dry runs, briefings, early feedback, fallback plans
Testing the application is an excellent way to introduce the solution to an even wider audience. This
may be a last chance to obtain participants that haven’t been involved, and thus will bring fresh eyes
and viewpoints.
For the rest of the user community that hasn’t been involved in the implementation, briefings should
be held. The audience at the pre-release briefings should contain a good mix of highly involved
stakeholders, the management team or a sponsor, and the general user community.
Preparing for all potential problems - Always be prepared for the worst during the implementation
of a new system, with fallback plans and full availability of all project team members. Unusually,
sometimes there isn’t a requirement for a dry run. This is a mistake, and the project team should insist
on having one.
Dealing with the unexpected – Presuming all preparation work was done, the fallback plans written,
and the dry run conducted successfully, something may still happen. In this case, access to the
sponsor or decision maker is necessary, in order to review options, and choose the best resolution.
The End of the World as You Know It
Going LIVE and Business Change Management
Depending on which portion of the Portfolio Management process has been chosen for enablement,
the impact on end users could be significant. Usually it affects, even if only slightly, a large portion of
the user base.
Business Change Management – redux – If business change management has been a strong
focus area during the project, the Go Live event should be relatively painless. However, even active

7. COLLABORATE 14 Copyright ©2014 by Diana Hanna Page 7
stakeholders when sitting down to their new world on Day 1 have been known to burst into tears.
Once again, it is the personal level of engagement that can help mitigate these incidents.
Training, Lunch & Learn, Brunch & Learn, and other bribery techniques – Some users don’t pay
much attention to the new processes until they have to actually start using them. They aren’t
opposed, they’re just busy with their normal day job. Therefore, immediately pre- and post- Go Live is
when the various user briefing sessions and training classes occur. It’s been proven conclusively that
when food is offered, attendance is twice as high as otherwise.
It’s NOT all about the Money
Using your new Portfolio Management Processes
A common misunderstanding is that Portfolio Management processes are based on budgetary
constraints or financial analysis, such as return on investment. Although these are two important
facets of choosing to invest in a project, there are other considerations too. The other considerations
include alignment to corporate strategies, risk mitigation, regulatory or legislative requirements, other
organizationally-specific measurements, and a balance across portfolios from different viewpoints.
Validating, Scoring, Prioritizing, Selecting and Funding – The classic process in Portfolio
Management typically follows these stages:
 Idea Submission – proposing initiatives
 Validating – confirming enough information exists in order to score and rank the Idea
 Scoring – applying metrics to the Idea based on its type
 Prioritizing – ranking Ideas based on score, financials, alignment, do-ability, and other criteria
 Selecting – applying final management decision for selection
 Funding – obtaining funding and commencing project delivery
 Monitoring – monitoring project delivery performance
 Completion – conducting project closure activities, and commencing Operate mode
 Operating – monitoring ongoing operation (Benefits Realization)
How to compile a Portfolio based on various selection criteria – A portfolio is simply a collection
of monitored items (Ideas, Projects, or Operations) that are grouped by a specific criteria. Criteria can
be by ownership, location, life cycle stage, strategic alignment, score, financial characteristics, risk
level, or any other measurement or characteristic the organization wants to define.
Give me MORE!
Instituting Continuous Improvement processes
An indicator of success when implementing Portfolio Management is the subsequent interaction with
the user community. When an implementation has planned a series of releases to provide specific
functionality, the users are encouraged to provide feedback. If they don’t like something, they are
asked to speak up and offer suggestions for improvement. With a known release schedule, user
requests can often be accommodated quickly.
Setting up support, helpdesk, and feedback mechanisms – As with any business solution based
on a software application, there are standard support and helpdesk requirements implemented once
the solution is released. These are typically set up according to the organization’s standards.
The only difference is that with a Portfolio Management solution, which is more business oriented
than software oriented, the stakeholder group needs to remain active. This group often transitions to
become the Process owners for Portfolio Management, addressing process issues and
enhancements.

8. COLLABORATE 14 Copyright ©2014 by Diana Hanna Page 8
Configuration Management for fixes, enhancements, new functionality releases – Once the first
release of the Portfolio Management solution has gone live, configuration management must be put
into place. The configuration management process includes a change review board, and a change
manager that maintains the enhancement request log and the configuration management tracking log.
All changes in support of either the process or software configuration are documented.
In Summary
 Engage participants early and often
 Start small, Say No and stick to your guns
 Expand as knowledge and experience grow
 Plan to accommodate the future