Prasanna Adavi, PMP, MCTS. MCITP, MCT
Beat the Half-life (t½)
GOVERNING YOUR PPM SOLUTION: POST-IMPLEMENTATION
1 | P a g e
Governing your PPM Solution: Post-
In Radioactive Physics, Half-life (t½) is the amount of time required for a quantity to fall to half
its value as measured at the beginning of the time period. (Ref: http://en.wikipedia.org/wiki/Half-life).
So, how does that apply to your recently implemented, brand spanking new Project Portfolio
Management (PPM) solution? The reason it applies is because your PPM solution, implemented
successfully, comes with an expiration date. If you do not take the time to plan, design, and
execute a governance process around the management of the PPM solution, you can rest
assured that the solution will get filled with stale data, bad design changes, processes that are
out of sync with actual organizational processes, and the list goes on. Just like a car that never
receives maintenance, your solution will stop yielding the ROI that is expected out of it. Your
users will become passive, and either stop using the solution or vociferously advocate a different
The goal of this paper is to discuss a framework to setup a governance model for your PPM
solution. A sample governance plan is also provided that could be used as a starting point to set
up your own governance strategy.
2 THE WHAT AND THE WHY
While the word governance could mean different things to different people, at the core, a
governance plan is a set of self-imposed policies and procedures, to make sure the application is
healthy in all areas and yielding the best return of value for the investment made on the tool.
Why is it necessary to have these restrictions, you ask? It is akin to the maintenance of the house
you are living in. Imagine, every time you need something to be fixed or added to your home, a
different contractor shows up, and does the work differently than the previous contractor. Pretty
soon you can be sure to end up with mismatching windows, multi-design door knobs, and so
on. That is why it makes sense for builders to have all those codes and guidelines to follow while
building something, standards of components they need to maintain, and so on.
Similarly, once your PPM solution is live, there are going to be several changes, enhancements,
and removal of features that will come up. Unless you set a standard on ‘how’ these changes are
performed, you can rest assured of a solution that is in complete chaos down the road.
2 | P a g e
3 AREAS OF GOVERNANCE
When you start considering setting up a governance plan for your PPM solution, you need to
consider which areas you actually want to govern. There are many theories and models for
establishing a governance plan for enterprise solutions, and you are free to choose the best one
that fits your organization. In this article, we will discuss one of these models that will fit most of
the PPM implementations.
The simplest way to figure out the areas of governance needed is to consider the areas where
changes are likely to happen, and then set up a governance plan for managing those changes.
Note: Even for items that are not ‘changes’ per se, and rather standard maintenance (Ex: Adding
new users, updating Timesheet Periods etc.,), it is important to have a set of standard procedures
In general, there are four key areas where changes could happen for your PPM solution.
3.1 INFORMATION GOVERNANCE
When your PPM solution is implemented, it is reasonable to assume that you start with good
‘master’ data in the solution. For example, these include Enterprise Resource Details, Enterprise
Calendars, related custom fields and so on - essentially all the ‘master’ data that will enable you
to use your PPM solution effectively. However, as you keep using the solution, people change
departments, some leave the organization, calendars need to be updated with new holidays,
time reporting periods need to be created, fiscal periods may need to be changed, and the list
goes on and on. Obviously, if this data is not kept updated, then all your reporting will be
inaccurate, and so does your security configuration.
'Process' in PPM
'Design' in PPM
3 | P a g e
Information governance is taking responsibility to keep this data updated and complete so that
the rest of your solution can take advantage if this core data.
3.2 DESIGN GOVERNANCE
The second area that needs to be part of your governance plan is the maintenance of “design”
of your PPM deployment. As you continue to use the solution, there are going to be requests to
tweak the solution design. These could arise out of a particular group wanting to change the
way they use the tool, or wanting to take advantage of new features. A classic example is
switching the way time reporting is done. You might have chosen to go with a % Work
Complete method, whereas with a new department added, you might need to switch it to the
‘hours worked per period’ method for the sake of integration with other financial solutions. So
the question is who will evaluate the impact of this change across your solution, and how are
the changes going to be rolled out.
Design governance is the plan to manage changes that impact your overall design of the PPM
3.3 PROCESS GOVERNANCE
It is easy to think of this area of governance as part of the design governance, because most of
the time, process and design go hand in hand. However, holistically speaking, this area covers
more than just the design. It addresses the governance of processes inside and outside of the
PPM solution that drive its effectiveness.
For example, take a scenario where your PMO is supposed to submit a report to senior
management every Wednesday AM. You might have setup a process to make sure that the
timesheets are submitted every Friday by a certain time, and all you project managers update
and publish their project plans by Monday AM, before the reporting happens. Now, let’s say the
senior management asks for reports to be sent Monday AM instead of every Wednesday AM.
This triggers a change in the process as to how the PPM solution is used, rather than a change
to the design of the PPM solution itself.
These kinds of changes will need to be governed by a standard set of rules, defined as part of
3.4 INFRASTRUCTURE GOVERNANCE
This is another one those areas that appears to be easy to silo, however can overlap the other
three areas mentioned above. Simply put, the infrastructure that supports your PPM solution
should be maintained with the installation. Some examples of the key items that should fall
under this kind of governance model are:
Installation of service packs or cumulative updates.
4 | P a g e
Installation of new add-ons, or apps.
Upgrade of the infrastructure (addition of application servers, Web servers etc.,) to
address performance concerns.
Changes to the infrastructure due to changes to other applications in the organizations
(for example, virtualization of all servers).
On one side of the equation, the decision to install something or not is purely merit based (for
example, whether it will impact any current production solution adversely). The other side of the
equation of any infrastructure is to look into the ‘process’ or ‘design’ changes that will be caused
by the installation. In some cases, the infrastructure change could be the result of any changes
in the other areas.
As mentioned before, while our attempt is to classify each change as part of one of these areas,
it is possible for some changes to completely overlap all four areas.
4 KEY QUESTIONS
No matter which area of governance you are trying to set up, there are three key questions that
need to be answered that will form the core of your governance plan.
How does the PPM team know that a change needs to happen (for example, what is the
trigger for these changes?). Sometimes, these changes are not ‘triggered’ per se, but are
part of regular care and feeding of you PPM implementation (for example, the addition
of new views for the Project Center)
Who approves these changes, not just from a Business ROI standpoint, but from a
Who actually makes these changes? For many of these changes, multiple teams are
involved. In some organizations some of the change capabilities are transferred to a
subset of end users, based on business needs. In these kinds of scenarios it becomes
even more important to define who actually will make what changes.
5 GOVERNANCE TEAM
A key component of any governance strategy is the team that actually works the governance
plan. While there are several ways to slice and dice as to what this governance team should look
like, the one recommendation that all schools of thought will agree on is to keep it simple.
The following is one way to set up the team structure:
Governance Area Owners These are the owners of each of the governance areas mentioned
previously in this article. In general, any change requests that will impact the designated area for
5 | P a g e
these governance owners will become the responsibility of these owners. It will be their role to
evaluate, provide recommendations, set up governance around the new features, and so on.
Central Governance Committee (CGC) This would be the team of decision makers who can
approve or reject the recommendations made by the governance owners. Having a central
governance committee not only helps reduce bureaucracy, but also helps bring all ideas to a
common platform, and evaluate them in cognizance of one another.
As mentioned above, depending on the size of the implementation and the current processes
that exist in an organization for other applications, the definition and structure of these roles
could be smaller or bigger. The important point is that to have at least a minimum structure in
6 OTHER KEY COMPONENTS
Some of the other key components for a successful governance strategy include, but are not
A Work Request solution, which allows users to request changes, features and
functionalities. This can be as simple as a SharePoint list or a currently used in-house
work request solution.
A process for handling changes, which includes reviews from IT, governance, CGC, and
other business functions involved.
A process for actually implementing changes. This could be a simple progression of
changes from Development Test Production Solutions or a full-fledged Release
Management per your organization standards.
7 THE PROCESS
Let’s take all the components discussed above as part of building a governance strategy, and
build a process around it. Here it how it might look (could vary based on organizational
6 | P a g e
Central Governance Committee
GAO-Infrastruture GAO-Design GAO-ProcessesGAO-Information
Implement the changes per
standard Change Control
within the Organization
Implement the changes per standard
Change Control within the Organization
While it is difficult to predict and plan for every change that can occur to your PPM solution, it is
important to have a strategy in pace that is flexible and scalable to any scenario.
As parting thoughts, please consider the following basic common-sense approaches to building
your governance strategy.
A governance plan does not need to be a tome with a lot of obscure terminology, and
language that no one can use in daily life. It can be as simple as an Excel sheet, with
quick answers to the key questions (addressed in Section 4 of this document).
Remember that a governance plan is not a documentation of your configuration. It is a
“plan” for protecting, maintaining and changing (if necessary) your configuration.
A governance plan needs to be easy to be implemented, and should integrate well into
the existing processes of the organization. It is not necessary to reinvent the wheel.
Understand that governance of your PPM solution is a constantly evolving process. It is
important to not get hung up with paralysis of analysis. Start small, deliver value and
then scale it up.
7 | P a g e
About the Author
Prasanna Adavi (PMP, MCTS, MCITP, MCT) is a Senior Enterprise
Project Management (EPM) Consultant and Trainer specializing in the
MS Project, MS Project Server, SharePoint platforms. His main focus is
to build/enable business solutions, which will help organizations
achieve the best return on their investments.
He also has extensive experience in leading projects end-to-end in a
wide spectrum of domains/verticals including IT, ERP (SAP),
Manufacturing, Application Development, Automotive and Creative
He is a regular presenter at various Project Server, EPM and SharePoint events across the country,
and regular contributor to the SharePoint and EPM Community.
He is a regular blogger at (http://www.prasannaadavi.com) and also runs a bi-weekly Podcast
(http://www.msprojectpodcast.com), mainly focusing on MS Project and Project Server solutions.
Prasanna is a Senior Consultant, with EPMA (http://www.epmainc.com).
You can contact him any time, through any of the mediums given below.
Phone: +1 248-417-3101
Company Email: Prasanna.firstname.lastname@example.org
Personal Email: email@example.com
Linkedin: www.linkedin.com/pub/prasanna-adavi-pmp-mct-mcts mcitp/8/634/919/
Personal Blog: http://www.prasannaadavi.com
Company Blog: http://www.epmablog.com
8 | P a g e
Appendix: A Sample PPM Governance
Note: The following checklist is provided just as an example, and is not to be considered a
complete plan/template. The names used are fictitious.
GOVERNANCE PLAN FOR PPM IMPLEMENTATION FOR CONTOSO
CENTRAL GOVERNANCE COMMITTEE
Stella Gonzales, Willis Razo, Cedric Novotny
GOVERNANCE AREA OWNERS
Governance Area Governance Area Owner
Design Marjorie Webb
Infrastructure Teresa Harris
Processes Rocky Ferro
Information Edmund Poland
WORK REQUEST PROCESS
All work requests will be logged in the SharePoint list http://abcd/Sites/123.
Work Requests will need to be evaluated by each business area before they are
presented to the PPM Admin Team.
CHANGE CONTROL PROCESS
All changes related to PPM will need to follow the organizational change control process
as defined in XXXXX.
All communications regarding the changes to PPM Solution will need to follow the
organizational communication process, as defined in ABCD1234.
9 | P a g e
Any communications (about changes to PPM) that are not part of the standard process
will need to come from the PPM Admin Team.
Item Trigger Approver Implementer(s)
Cumulative Updates Installation Automated Email Alert GAO- Infrastructure Infrastructure team
Service Packs Installation Automated Email Alert GAO- Infrastructure Infrastructure team
New Software Installation User Request GAO- Infrastructure Infrastructure team
Performance Related Changes User Request/PPM Team
GAO- Infrastructure Infrastructure team
Farm Infrastructure Changes PPM Team Request GAO- Infrastructure Infrastructure team
Item Trigger Approver Implementer(s)
Adding/Updating New Users/Resources User request GAO- Information Departmental Super
Adding/Updating custom fields User request GAO- Information PPM Admin team
Adding/Updating Lookup Tables User request GAO- Information PPM Admin team
Adding Updating Timesheet Periods User request GAO- Information PPM Admin team
Item Trigger Approver Implementer(s)
Time tracking methodology User request GAO- Design Departmental Super Users
Fiscal Year configuration User request GAO- Design PPM Admin team
OLAP Cubes configuration PPM Team GAO- Design PPM Admin team
Security Configuration PPM Team GAO- Design PPM Admin team
Item Trigger Approver Implementer(s)
Timesheet submittal cadence User request GAO- Process Departmental Super
Process of requesting new projects in PPM User request GAO- Process PPM Admin team
Process of Closing projects in PPM User request GAO- Process PPM Admin team
Process of requesting Resources in PPM User request GAO- Process PPM Admin team