10 Things To Ponder When Implementing
An Integrated Portfolio Management Application

Over the past 1 ½ years, I have been involved in implementing a portfolio management application. While there are many success associated with this endeavor, there are many lessons learned. In no order of importance nor severity, I have captured several thoughts that you need to ponder when implementing a portfolio management application.

I. You’ll Have To Become An Evangelist
The application champion (business side and application administrator) will find themselves constantly ‘selling the benefit’ of the tool. You will need to become evangelist for portfolio management and have the stick-to-it-ness to weather the storm. Resistance will be strong and critics will most likely outnumber advocates. You will need to continually prove the value of the application and its data. This is not easy, its not pretty, and it will become frustrating. You will find yourself doing some behind the scenes magic (see reports below) to prove the application has value.

There will also be a significant training and learning curve. Even if the organization is mature in its artifacts, processes, methodology, and terminology, there will be a new means of recording and reporting it. Plan for this – share the wealth, do shared learning’s. Don’t expect one class and ‘documentation’ to carry the burden of training everybody.

II. You’re Now Exposed
In the past, a project manager had control over when information about the project was shared and available for all members of the project team and for executives. The project manager could masks blemishes and possible lapses by controlling when information was shared. For example, if the project manager led a project status call every other Thursday, they could possibly wait until Wednesday night to update their issues report. If an issue was due a week before, the report might not get updated until before the review. Now with a portfolio management system, the day the issue becomes past due it can be flagged in reports. The PM might now have to do daily management of the issues.

III. You Sacrifice Flexibility For Conformity
One of the benefits of a portfolio management system is the ability to track information consistently across projects. Additionally, OPM3 type maturity models call for consistency across the organization. A portfolio manager enforces conformity and an individual PM will loose some of the flexibility they have in tracking and reporting project status. For example using issues again. A PM might want to have a way to indicate an issue is resolved prior to being closed. This way they could have a report that shows issues ‘resolved’ and ready to go off the list. Another project manager may be more of the mindset that it goes straight to closed. People can refer to a closed issues report to see what’s been closed in the past week. While I’m not in a position to say which method is better, a portfolio management issues workflow will force the process. If a program manager wants to have consistency in reporting of all projects across the portfolio, an individual will need to sacrifice some of their individual style to conform to the portfolio work flow.

IV. The Needs Of The Many Outweigh The Wishes Of A Few
As you take project management from desktop applications and non-integrated artifacts, you have risen to the level of application management. With application management comes the entire cycle of enhancement requests, workflow requests, and even field names. A PM might not get the feature he/she wants – or may have to compromise.

V. The Application Is Alive And Needs Care And Feeding
First thing to do when implementing a portfolio management system is to appoint an application administrator and an application change control process. Budget a person’s time into the care and feeding of this application. There is no rule of thumb regarding how many Full Time Equivalents (FTE’s) are required for application administration, but it will have a direct relationship to the organizational maturity, the business process maturity, and the breadth of the audience. One of the workgroups we brought onto the Portfolio Management Application involved new people, new business model, Beta applications, and new customers. This group ended up with an application administration team that looked at the business request and 2 trained administrators that did the physical administration (defining views, reports, filters, adding users, creating work flows etc.) There were also 2 team members who looked at templates and business needs and helped set priorities with the application administrators. Application administration is a different responsibility than a system administrator or a data base administration. An application administrator needs a strong skill set balanced between knowledge of project management principles and methodologies, knowledge of the business, and technical knowledge of data bases, SQL, report writing, and trouble shooting. A system administrator focuses on making sure the operating system and the hardware work, the application administrator makes sure the application meets the business need. Your organization is headed for failure if you think a system administrator can provide the business needs fulfilled by an application administrator. Finally, there will be changes and churn on the application. Its going to need someone to manage those, train the users on changes, and prioritize the work. I would imagine many organizations under estimate the care and feeding needed to keep an application viable.

VI. People Do What Is Inspected Not Necessarily What Is Expected
Everybody has the best of intentions, but taking care of the low level minutia that makes up a portfolio management system is cumbersome, time consuming, and some people may see it of little value. A basic premise of a portfolio application is that executive levels of information can be gleamed from multiple projects at one time. However, to get that executive level, the lowest of details must be there and many project managers will not put it in, unless they are hounded to put it in, or they are ‘punished’ if they don’t. Excellence is a mindset and the middle manager MUST maintain vigilance to insure compliance. There’s an entirely integrated thread with this thought and that involves cross-organizational compliance so the portfolio management tool transcends a project management application and becomes a business management application. The impact, both cultural and technical, aspects of this concept are way to deep to cover in this pondering. I have developed both a presentation and an in-depth workshop on dealing with implementing project management and this aspect of it. My advice here is to the middle managers, there will be a large amount of energy required to make sure all the details are nurtured to make the executive view accurate and usable.

VII. One Good Report Leads To A New Request
I knew this going in and it just continually gets reinforced. Input is one aspect of an application, output is another and there is an exponential demand for output. The main outcome of a well organized report is that you will get a request for a new report or the same report with a ‘slight modification’. I don’t think there is a way to stop this!!!! The requests will continue to flow in and, even if you have an opportunity to do ad-hoc reporting or exporting to a comma separated value (CSV) file, you will still be brought into reports.

VIII. People Will Blame The Tool For Their Own Defects
It’s a rule of human nature. People will blame the tool to hide their own insecurities and lack of knowledge. No matter what tool is created, it will have its own set of idiosyncrasies and there will be some things the application will require that make no sense at all, but the application requires it. Be thick skinned and prepared for people to blame the tool for their problems. One of our frequent tool blamers does a lot of work via a dial up connection instead of the office on the intranet or from home via broadband. This tool (as most server based applications) does not perform well over dial up. It is slow, even on the network, and with dial up it might even time out on requests. Thus it is a great excuse for the PM not paying attention to the previous mentioned minutia.
IX. Some People Just Don’t Get It
No matter how much you train, hand hold, and evangelize, some people just won’t get the idea of project rolling up to program, rolling up to portfolio. You will encounter resistance as to why do I need to do it this way? Portfolio management is a completely different perspective and does require a certain amount of abstract visualizing (is there any other type?) – some people who are GREAT silo-based project managers, will just not get the inter-dependencies of projects within a portfolio management system. Work with these people, be careful and understanding, the odds are that they want to do well, and they have a wealth of knowledge and experience, but they have a mental block. Plus one day the light might come on.

X. An Ounce Of Customization Equals A Pound Of Maintenance
Every salesman who pushes a portfolio management system touts its flexibility and the capability to customized the tool to meet your business need. Most give you the capability to add custom fields and create your own reports, but as stated earlier the demand for various output never ceases. In the infancy of the tool you will be able to quickly add a custom field to meet a need, but after months of customization here and there, the ripple effect can be enormous.

Well that concludes this little bit of pondering. I’m an evangelist on portfolio management and wish anyone who undertakes implementing a program wide tool the best of luck. One thing I do to keep everything is perspective is to sign all my emails with the salutation: “We’re All in This Together” and with a portfolio management tool that is so true.

© Copyright David L. Davis, PMP
This has also been posted at:
http://projectmanagement.ittoolbox.com/white-papers/10-things-to-ponder-when-implementing-an-integrated-portfolio-management-application-1481#

I. You’ll Have To Become An Evangelist
Agreed – and you will never stop training and re-training.  You will find that the documentation is only the backstop for you (the subject matter expert), everyone will call, e-mail, stop by, etc. to get info from you before they will even consider looking at the training documents or manuals.  

II. You’re Now Exposed
Keep up with the PMs that don’t like this exposure, they may have “issues” with the tool that prevents them from reporting on time.  See # 8 below too!

III. You Sacrifice Flexibility For Conformity
I agree with your issues example.  Another simple example for conformity is the naming of the product line or project.  A Portfolio Management App will require that everybody use the name for the product, project, etc.   

IV. The Needs Of The Many Outweigh The Wishes Of A Few
While the 80% - 20% rule for needs might apply here, I find it’s the “CIO wants it this way ” rule that really applies.
V. The Application Is Alive And Needs Care And Feeding
Application administration will most likely take much more daily time than the system administrator.

VI. People Do What Is Inspected Not Necessarily What Is Expected
Yes, yes and yes!

VII. One Good Report Leads To A New Request
I don’t see a way to stop this either, but have found that report pruning must be done occasionally since it seems that too many similar reports dilute the usefulness in individula reports..

VIII. People Will Blame The Tool For Their Own Defects
It’s also a rule of adult education.  You can send adults to class, but you’ll never know how much attention they gave (or did not give) the class until they start blaming the tool or process.

IX. Some People Just Don’t Get It
You said it all.

X. An Ounce Of Customization Equals A Pound Of Maintenance
To the point of where you may even want to consider a major review of customization vs. performance occasionally.  A major “Patch” or system change by the vendor is a good time to do this.

I agree with you well-stated points.  You will also become the "go-to" person for all aspects of project information.  You will be invited to all status and steering committee meetings because you will posess all the information on all active and future projects. 

David is certainly right about portfolio management being a team effort. So in the spirit of "we're all in this together" one way to avoid being made the scapegoat for the system's perceived shortcomings is to involve project managers in the process of specifying and selecting the solution. This will inevitably involve some compromises, but if they understand and had a say in the choices that were made, they are much less likely to antagonise. 

In a large organisation, it may not be possible to get everyone's view, but the practitioners should have some involvement. Perhaps this can be done in the form of a steering committee or feedback loop.

Well, a wise person once told me, "None of us is as smart as all of us!"

Yeah, but don't forget that an elephant is a mouse built to committee specification!

LOL...good one!   

I will have to remember this wise saying!