5 reasons why project managers will resist project portfolio management systems and 5 reasons they will embrace it

Exhibit 1 - Mind Map of Results including Graphics of Results

Overview

Over the course of the past 5 years, I have been actively involved in implementing an Integrated Portfolio Management System. The different organizations have had varying degrees of success for a multitude of reasons. Many organizations have developed broad based teams to evaluate the best tool to implement. As part of an organization that was recently acquired by another company, I was fortunate, or unfortunate depending on your perspective, to be involved in a new evaluation process. As I was pontificating to the team about tool selection, I kept referring to a mantra,, “It's Not the Tool, It's the People”

During one vendor presentation, the claim was made that almost 70% of Integrated Portfolio Management System (IPMS) installations are abandoned or completely redone within 3 years. This led me to analyze why certain team members embrace the implementation of IPMS tools, while others resist their implementation.

I use the term adoption to define the success of a tool implementation. This means that the key stakeholders (data owners, data users, and data champions) use this tool as their source for all information on projects and work initiatives in the organization. An individual can adopt a tool, but not embrace the tool, and the inverse is also true, an individual can embrace the tool, but the organization chooses not to adopt it.

A Human Issue

It's not the technology, it's the people.

As I investigated adoption, I quickly came to the conclusion that the IPMS tool ecosystem is constantly evolving and thus leads to the challenges in embracing and implementing IPMS tools. Program Management Methodology is just now becoming standardized to provide a model for tool structure. Tool vendors are consolidating into a smaller subset of companies participating in the marketplace and, thus, consolidation of features and functionality. Tools themselves are converging, with a single interface provide capabilities to provide project status, track individual knowledge areas, collaborate across the enterprise, and finally, incorporating the project work with other mission critical work such as Business Process Management Tools, Quality Metric Tools, Workforce Management Tools, and desktop productivity tools.

This turbulence is certainly a factor in the entire tool adoption equation, but not entirely. The challenge isn't the tool, it's insuring the organization is prepared to use a tool, the Project Manager is trained to use a tool, and the executives use the tool to manage the business. The adoption challenges are pretty much the same regardless of an IPMS or not. The trust of how information is used, the ego of the team members, the political influences of an organization, and accuracy of data are more important.

Since this landscape is fragmented, the approach of this paper is somewhat fragmented. This paper is constructed using a mind-mapping approach with limited focus on hierarchal structure and more focus on pockets of information. The sections will be spatial in nature and the information will consist more of snippets than detailed prose.

Antidotal

I had devised my own theories as to why some people embraced tools, while others resisted them. I decided to solicit the opinions of people I know within the profession. I assembled a short survey to accumulate antidotal data about adoption and the perception of professionals. I sent emails to members on a list I had accumulated over the years of people who have either emailed me, been included in an email list of a large distribution, or have contacted me electronically over the past 10 years. I sent an invitation to these people, and also posted a link on a PMO forum and my ITTOOLBOX blog and offered people to take the survey.

I was surprised at the overwhelming response and the need for information regarding the realm of tool adoption. Many people are looking for statistically significant information, but this paper will not have it. It does have a basis for opinions and thoughts on tool adoption.

Participant Profile

The following information provides and overview of the response rate and time frames for the survey. Project Management Paper Survey

• Email Invites: 2,026
• Visits: 1325
• Partials: 262
• Completes: 422 (Does not include blank responses)

PMI Members

95% of the participants in the survey are members of Project Management Institute (PMI^®}

Organizational Buy In

First and foremost, for any tool to be embraced, the organization must buy into the concept of an IPMS. The executives must commit to the tool as the sole source of information. Stakeholders must commit to providing current and accurate information; project manager coaches must be vigilant about reviewing the information in the tool and associated reports. Finally the project manager must ensure the low level minutia and detail is current, accurate, and complete. There is no rule that says only the project manager can interface with the system. In an ideal adoption environment, all stakeholders will frequently interact with the system and own issues, risks, and task reporting to the team.

Mindset

The individual's approach to the tool is the most significant factor in adoption. If the individual does not want the tool to succeed, their behavior will most likely cause poor adoption. All members of the project team must be willing to make the tool, with all its flaws and blemishes, work.

Perception

A fundamental human component to adoption is how does the Project Manager perceive the tool, how will it help the Project Manager.

Aptitude

Aptitude involves the individual's ability to perform the technical functions required to interact with the system. This would include navigation of screens, pulling of reports, and checking in files. In implementing an IPMS tool into several organizations, aptitude is rarely a problem. The mechanics of using a tool are pretty much a fundamental skill set in 2007.

There may be international issues regarding aptitude, but those can be quickly over come with a training class. My experience has shown that most training questions are focused more on values within the tool. The aptitude for adoption is aligned with the understanding of the business process and the project management methodology of the organization.

Attitude

Henry Ford is often sited as the source of this quote: “If you think you can, or if you think you can't, either way, you're right.” That quote summarizes the attitude of adoption of a tool. If the individual wants the tool to work, they will find ways to make it work and if they want it to fail, they will find ways to make it fail.

Attitude is the primary human element in embracing or resisting a tool. Attitude is contagious, if the organization has a positive attitude toward the tool implementation, it will help overall adoption. If the organization does not want a tool to work, it most likely won't.

Motivation

The acronym, WIFM, What's In It For Me, is fundamental in the motivation for the Project Manager to use the tool. Will their performance evaluation or pay be directly tied to how the individuals embrace the tool? If there are no consequences for not embracing the tool, then adoption will be difficult to achieve. Additionally, if resistance is accepted, there is no motivation for adoption.

Executives Don't Understand Value

Most top managers (including sponsors) do not understand the significance of IPMS for the success of their projects. Many responses referred to the lack of understanding of executives of the value of an IPMS. A quote from the survey that summarizes the impact of executive understanding:

Turf

Many respondents of the survey indicated the tool success is based more on the political structure of the company than the tool itself. Ownership of the data and reporting will dominate adoption. Many people referenced different agendas among executives as a major concern for adoption. If an executive does not buy into the output of the tool and frequently challenges it, then the tool is doomed to failure.

Organizational Maturity

Seventy-three percent of the respondents stated that organizations try to implement tools without a solid business process to build upon.

Lack of Consistent Methodology

A sample quote from the survey: “No resistance, just unable to get it running partly due to lack of consistent methodology, partly due to complexity of tool”

General

Many of the adoption issues referenced in the survey involved acceptance of the role of a project manager in general and not just the adoption of an IPMS. If the organization and key stakeholders do not embrace the project manager as the source of information for the Work In Progress, no tool will work.

Project Manager Authority

Many project managers referenced they do not have any authority to change individual's behavior on project team. Project managers indicate a frustration that a tool is expected to solve many problems, but many stakeholders think the tool is an administrator application for Project Managers and they do not have to be involved in tracking that low level of information. They feel the Project Manager is only there to take notes and perform clerical functions.

An organization must create a culture where everybody owns information in the IPMS and that the Project Manager is not the clerk to the other members of the team.

Project Manager an Administrator

Quote: “ Project Managers do not have adequate authority to either resist or embrace IPMS. In our organization, a Project Manager is more akin to a Project Administrator. As such, they are following the dictates of the hierarchical management of the organization.”

Management Buy In

Quote: “I’m not sure I agree with your premise. I don't think project managers are key to the decision to a successful Project Manager. Management buy-in is essential. Project managers are iconoclastic, but in general they do not have enough management tools to work with.”

Adoption Factors

As stated previously, I entered into this paper with some previous ideas as to factors for IPMS adoption. The survey included a straight forward yes or no question regarding if certain factors impact adoption.

• 60% of the respondents stated that Overall Project Governance was a factor in its adoption. The tool must have some many things “checked” before a project can be moved from one state to another (For example a software project cannot go to production until a User Acceptance Test has occurred).
• 52% thought the tool helped to better align with corporate goals.
• 45% thought the clerical work aspect of the tool was a major factor to adoption.
• 36% thought it was another form of reporting - the information had been sent before and this was just another channel of presentation.
• 33% said it didn't matter - politics determined priorities, the business did not make rational decisions based on empirical data.
• 29% said Project Manager ego was a factor.
• 19% indicated that many organizations didn't want to know the actual status.
• 15% said that the threat of a project being cancelled was a factor and 13% thought it was a threat to the project manager being eliminated.

Resist

Resistance represents items that will justify a behavior to not adopt the tool.

Wide Variety of Reports

Vendors push their systems based on the way they can read out information on all the projects in the IPMS. Some tools offer as many as 250 canned reports or dashboards out of the box as well as the capability to customize the reports. This myriad of reports is a strong argument against adopting a tool. Project Managers will reference that the reports are too convoluted and inconsistent.

Reports Misunderstood

Reports, or system output, is often misunderstood or used as a focal point for an individual not understanding the business model or the meaning of various data points with the project life cycle. While vendors push the reporting capability of the tools, organizations spend inadequate time defining the input and output of the reports and the appropriate business response to report data. For example, it is easy to set a project in Red, Yellow, or Green status, but what are the criteria to meet that status?

Ignored

Many project managers fell they are forced to fill out information for an IPMS that generates a report that is promptly ignored by key stakeholders.

Organizations do not reward the documentation with the tool, but instead reward a “chicken little” approach. Other team members feel they should have special notification of anything and that reading a report is above them, thus, demotivating any Project Manager from keeping the data in the tool current and accurate.

Complain / Escalate on Perception

Quote: “We have this feature. Mostly the customers do not bother to use it. When they get mad enough they prefer to complain to the CIO directly, in order to make a point and get a personal reaction.”

Reports Focus on Wrong information

Many reports focus on what middle managers want to communicate and not on the true status of the projects. Many projects will indicate a per cent complete, but that often does not reflect the true disposition of the project. For example, a software testing phase may have 10 cases of which 2 involve connectivity, 1 involves creation, 2 reflect updating, 2 reflect cancelling or deferring and 2 reflect closing, and 1 reflects billing. Within the first day the connectivity and creation works and the status is 30% complete, while in reality 80% of the lifecycle of the work is done in updating and billing - and none of those tasks that have been started. So is 30% accurate of the lifecycle of the application?

Bad Reports

Quote:” Although, if the Project Manager understands that the system provides crappy reports (due to inconsistent/crappy data on the input end), then I can see how a Project Manager would not want those reports provided to Executive Management.”

Executives want their own Reports

Quote:” I haven't seen a standard executive report that any executive agrees to. This is a big time consumer on most of my programs. Everyone wants what they are used to for a dashboard……….and since they are the holders of the money bag…….they get what they want!!”

Overhead

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. 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.

Exposure

Now that the PPMS tracks all aspects of the project, the project manager's attention to detail is now exposed to peers and managers. 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 mask 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 Project Manager might now have to do daily management of the issues.

Force Compliance to a methodology

Project Centric organizations should follow a process and apply a methodology. This will look at the challenges of combining the process, methodology, and application. Once this is combined, then the tool tracks Project Manager compliance with the above – it can become a measuring stick for project progress, compare multiple projects on a level playing field, and force application of a methodology.

Used as a Weapon

Quote:” Who will be doing the comparison and for what purpose? Project managers are already compared, especially at performance review time. If it is used as a weapon against project managers, of course they will resist it, but this is more of a line management immaturity, petty, insecure issue.”

Big Brother

Big brother is watching aspect - looking only for bad.
Quote:” Most of the peers already know about the lack of executive support and sincere interest in the project teams. Executive only reward good news and punish bad news, rather than providing the necessary resources and leadership assistance to ensure success.”

PM Attention to Detail

Many people indicated that the major cause of resistance was forcing the Project Manager to focus on too much detail. The Project Manager has more important work to do. As businesses are driven to higher productivity and avoiding busywork - many project managers state that this detail is a waste of their time. However, there is the issue of where is the detail, where is the audit information, who can recreate the origin of assumptions and issue mitigation once a disagreement occurs.

This is clearly a cultural issue and a Project Manager self perception. There is not a sweet spot for the appropriate level of detail, but the Project Manager will be expected to have the detail if obstacles arise to the completion of the project and intervention is required.

Appropriate Level of Detail

Quote:” To be effective, Pgm Mgmt tools need to be at the appropriate level. Trying to work at too low a level of detail is probably a big reason they fail, in my opinion.”

Tool Forces too low a level

Quote:” A project manager can easily get dragged down into the detail of a complex project, especially when he or she is working in a Portfolio Management tool (or other tracking tool) that demands attention at the detailed level; unless he or she can delegate the control of details to others. Unfortunately it is in the nature of even complex projects that resource management must be addressed at the task level, and it is best practice to break down the scope into small work packages that are delivered by small tasks; so there can be many tasks and therefore many resource assignments to manage. This is not something that a Portfolio Management tool (or any other advanced project planning and tracking tool) introduces; it is a consequence of achieving the fine- grained planning that such a tool helps one to achieve. If the Project Manager cannot manage at that fine level of detail, then it would be better to break up the project into several projects each under the management of a subproject manager or team leader. In practice I have found that this gives limited benefit (in terms of keeping the Project Manager away from details) where the team leaders do not have sufficient training in project management; very often I must use IT Architects or other specialists as team leaders and they do not, in general, have sufficient exposure to project management to use a Portfolio Management tool or other project tracking tool as a Project Manager would use it. Ideally a Project Manager would only work at the higher level, allowing each team leader to manage to the plan for their part of the scope. A Portfolio Management tool such as the one that I use supports this by allowing aggregation of numerical data from project to program.”

Project Manager Attitude

Along the lines of reason 1, but taking it to a greater level, this will look at ways to overcome the obstacle and also that the PPMS tracks the portfolio – it doesn't control content and it doesn't prohibit complex projects from complying to the methodology.

Project Managers Don't Think Tool Adds Value

Quote:” Before the tool, the projects had some way to share information; in that case they don't see the tool as adding much value. If you did not have a shared drive or something, then they would probably welcome it.”

Project Manager Arrogance

This item could be its own paper, or even short book. Many people referenced Project Manager arrogance as a major factor in adoption. The responses ranged from being too busy to have to deal with the low level details, that an IPMS takes away from focusing on real business issues, and that people don't understand project management and the Project Manager doesn't have time to train them. A quote from the survey: “Misuse and abuse of cross reference items would introduce red herring interference into the project manager's scarce time and divert attention from the critical elements that need to be analyzed and managed, to the exclusion of others.”

Set in their ways

Quote:” Many Project Managers are set in their old ways to modify their process to the tool”.

Tool does not align with work

Many Project Managers will flat out state that the tool doesn't appropriately perform Project Managementfunctions, align with their communication model, provides proper detail, etc.

Quote: “If I understand this correctly, this is where I think you’ll run into most of the difficulty in trying to create a one- size fits all tool. There are politics, other good tool ideas, tried and true processes. “If it's not broke, don't fix it” and “Not invented here” attitudes”, let alone natural resistences to change. (Look at how much Cobol is still in use!)“

Too Complex for Project Manager Skill Set

Quote:” In this case, the resistance (or just plain ignoring of the processes) is actually driven by the over-reach of the implementers. The system (MS Project Server) and processes were established for a PMM level 4/5 while the vast majority of the users and their orgs/teams are not anywhere near that level.”

Executives look for different reports

Quote:” Most Project Managers like to have a consistent set of report templates, and automated tools. However, they resist the extra workload that is required to manually duplicate project accounting data to support management forecasts and reporting when that same information is readily available in the integrated project management solution. The resistance, IMO, stems from sr. management's reluctance to fully embrace an enterprise Project Manager solution by trading “hard-copy” or static “snapshot” reports for on-line access to info on-demand. When Project Managers are expected to do both, they will do what management expects, therefore reducing their maintenance of information in the EPM system where the same info is available in a legacy system and format that management is used to receiving. This undermines the quality and completeness of the info in the new EPM solution and limits its potential for full and complete adoption. I have also observed that some Project Managers(a significant minority) do not want fully automated reporting because they feel that they need to edit the information provided to management (because they do not fully trust management or because they feel the EPM reports need to be annotated so that they can be interpreted properly”

The Tool Stinks

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 Project Manager not paying attention to the previous mentioned minutia.

Embrace

Embrace refers to project managers who will use the tool to assist them in managing the projects and all knowledge areas.

Audit Trail

The tool provides an audit trail of all major milestones of the project. It will date/time stamp when issues are assigned. It will be able to track baselining of artifacts; it will provide reference material for supporting various aspects of decisions made during the life of the project.

Essential

Quote:” Experienced Project Managers know that if it is not documented, then it did not happen. Portfolio Management Tools such as the one that I use provide rich (in the case of RPM, very rich) functionality to document all objects (such as but not limited to: tasks, risk items, issues, phases, activities, change requests, action items) using property sheets, and further to attach standalone documents (such as text files, email captured in PDF, spreadsheets, and so on), which can be attached to any object. The portfolio management tool that I use also provides a repository to hold documents (including those linked to objects such as tasks, action items, change requests, etc.) with version control and automatic change history.”

How it's used

Quote:” If the Project Manager can see it from the perspective that it will supply them with information on process bottlenecks and blackholes then it is a plus. If only to catch their errors then partial transparency of the information is a negative.”

Artifact Management

The tool provides a Document Management system and will be used as a library for all critical documents within the project lifecycle. Additionally, it can assign and track compliance by key stakeholders and allow an avenue for comments. With the document management process, a history of various artifact versions is available to stakeholders, with date time stamps.

Baselining

The only way that artifact management is useful within an IPMS is if it tracks baseling and a snapshot in time. As a part of an audit trail, it is an effective means of combining other formats (excel spreadsheets, word documents, etc.) within the project deliverables.

Quote:”Baselining is the real key here. Artifact management can be done with any number of tools that are documentum and/or sharepoint based.”

Integrated

Quote:” Coupled with methodology and audit, it makes the artifact management and baselining an easy and convenient matter.”

Consistency

This forces all project managers within an organization that uses a tool to have consistent reports, consistent workflow status, and consistent stage gate information.

Issue Management

The tool provides a Document Management system and will be used as a library for all critical documents within the project lifecycle. Additionally, it can assign and track compliance by key stakeholders and allow an avenue for comments. With the document management process, a history of various artifact versions is available to stakeholders, with date time stamps.

Reports

The Project Manager will be relieved of having to provide a spreadsheet or other report at the end of the month that shows the project status and other administrative information.

Quote: “A project manager can easily get dragged down into the detail of a complex project, especially when he or she is working in a Portfolio Management tool (or other tracking tool) that demands attention at the detailed level; unless he or she can delegate the control of details to others. Unfortunately it is in the nature of even complex projects that resource management must be addressed at the task level, and it is best practise to break down the scope into small work packages that are delivered by small tasks; so there can be many tasks and therefore many resource assignments to manage. This is not something that a Portfolio Management tool (or any other advanced project planning and tracking tool) introduces; it is a consequence of achieving the fine- grained planning that such a tool helps one to achieve. If the Project Manager cannot manage at that fine level of detail, then it would be better to break up the project into several projects each under the management of a subproject manager or team leader. In practise I have found that this gives limited benefit (in terms of keeping the Project Manager away from details) where the team leaders do not have sufficient training in project management; very often I must use IT Architects or other specialists as team leaders and they do not, in general, have sufficient exposure to project management to use a Portfolio Management tool or other project tracking tool as a Project Manager would use it. Ideally a Project Manager would only work at the higher level, allowing each team leader to manage to the plan for their part of the scope. A Portfolio Management tool such as the one that I use supports this by allowing aggregation of numerical data from project to program.”

Referral Tool

As new participants join the project, the Project Manager can refer the individual to the PPMS to obtain information on the project history and its audit trail. Instead of having to compile an email with all the critical artifacts, the Project Manager can just send a URL to the participant.

Executive Support

While this was listed as a resistance factor, it also rates highly as an adoption factor. If executives demonstrate use of reports and the tool, adoption will greatly increase.

Better Use of time

Quote:” When Execs get regular, standardized reports, they make fewer ad hoc report requests of the Project Manager in his/her ‘spare’ time.”

Objectivity

Quote:” Whether they know it or not, the Executive staff would benefit from having a comparison of “apples to apples” as the workflow would glean out like information across all projects. Now, it is very subjective and the information is very “managed” before it gets to the steering committee.”

Cross Reference

A good PPMS tool will allow the Project Manager to cross reference among modules and entities within the life of a project. The tool can link an issue to a risk item or an assumption to a risk item. It can track a change request with a task or other means of associating items within the project, or across multiple projects.

Cause and Effect

Methodologies must be followed and discipline development to utilize cross reference and dependencies consistently. For example, an assumption prior to project charter should drive a risk item in the project plan. An issue that arises might be the realization to a defined risk and cause mitigation to be implemented. The challenge will be cross referencing across projects. Can an issue identified in one project be cross referenced to another project and then defined in portfolio analysis? The tool gives that capability. Is the business process mature enough to react to it?

Reuse

Quote: “Co-ordinated cross reference reports can minimize existing multiple versions of same report for different audience.”

Observations

After implementing a tool in multiple organizations and looking over the survey results, I have made several observations

Does Not Replace Fundamentals

Most of the comments involved the human aspect. Respect for roles, use of the data, and acceptance of the project management profession are all aspects of tool adoption.

Quote: “Experienced Project Managers know that they should listen to their customer. Portfolio Management tools are not a substitute for engagement with stakeholders.”

Overuse of Electronic Messaging

A tool is nice, but many organizations use it as a means of just sending email and not really managing the projects.

Quote:” Portfolio Management tools such as the one that I use provide rich functionality for notification of events (changes in the status of objects such as issues, risk items, change requests, defect reports, and so on) either within the tool or by email. Overuse of this mechanism should not be encouraged, since it can lead to a flood of messages that cause more confusion than co- ordination of effort.”

Overhead Perception

There is a perception that the tool adds overhead. This must be addressed as the tool is implemented. I do not disagree with this assessment, but I think it can be turned into a positive by eliminating many mid year “fire drills”.

Time to Implement

Several people commented on the fact that an organization needs time to successfully implement a tool. They also reference an attitude of quick implementation and rapid savings without taking the time for team members to familiarize themselves with the tools and business processes.

Quote: “I think the major challenge I have experienced is communicated the value proposition to executives, program managers and project managers. The cost and time of an implementation for a tool that should be designed to automate relatively standard processes is high, mostly due to the fact that executives do not agree on utilizing standard processes for their projects across an organization. The amount of time and money spent standardizing business practices and nomenclature is where a majority of the difficulty and cost in transacting effective, sustainable change lies. And having another “non-core” system to upgrade and maintain is also a difficult sell to executives, even to CIOs.”

Conclusion

I have just scratched the surface of a very emotional and complex subject area. There was much more information obtained than could be included in this short paper. Expect more analysis and survey data to be posted online during the course of the next year. You can email [email protected] to find out when and how this data will be offered. But the bottom line is simple, IPMS implementation is a human issue, not a technical issue.

Enterprise

Quote: “It seems that IPMS needs to be an enterprise-wide tool, which companies had a difficult time justifying the cost, time, and disruption that it will have on the company. Companies will need to train and generate acceptance of a new methodology or process and that is difficult to swallow. You are right that IPMS implementations fail because only a few are willing to adopt it and others resist because they believe that it's too much work and effort that takes them out of their comfort zone. Also, individuals and companies are looking for the quick fix and not the long-term results. Several companies are living from quarter to quarter trying to keep stockholders happy with a strong stock price. Poor, self- centered executive management is the blame for this.”

We're All In This Together !!!