It is an exciting endeavor for any business or PMO to take the leap and decide to implement a project management tool. Sales and Marketing for the companies that sell these tools have incredibly effective presentations that show expansive enterprise level reporting for Portfolios, Projects, Programs, Resource Management, Risk & Issues and much more. Provided below are a few lessons learned that should help in the effective implementation of the PPM tool of choice.
To start with, the sales and marketing team mentioned above made an amazing presentation to your PMO/Corporate leadership. After the sales presentation all affected stakeholders need to understand that the presentation they reviewed would likely represent a CMM level five organization. All the "bells and whistles" displayed in the presentation will not be a realistic representation of a primary installation of a PPM tool at most organizations. The first iteration of the PPM tool should be focused on only what is already capable of being delivered within the target environment. For example, if there is no current Portfolio Management practice, do not expect the tool to provide one. Portfolio Management done effectively requires processes for alignment, scoring, review and approval that are not tool functions; they are well defined internal business processes. Therefore, in order to avoid unrealistic expectations and disappointment from stakeholders make sure they understand how your current capabilities map to the PPM tools available functions.
Internal business definitions do not often align to the PPM tool terminology. It is incredibly important to clarify terms such as Project, Program, Master Project, and Sub-Project. What complicates matters here is that other applications being used may have different definitions for these terms. An Oracle financials project could equate to a program, or to multiple projects in your PPM tool. On the resource management side, understanding generic terms like allocation, capacity, availability and assignment are crucial. Defining and re-defining exactly what project management terms mean will help avoid misunderstanding and allow for more productive requirements and design sessions.
In order to proficiently implement a PPM tool, it is important to consider two critical factors. How much will the organization have to customize the application vs. how much process change can the organization tolerate. PPM tool implementation requires process change in itself and requires participants to adapt to new ways of doing their jobs. Conversely, all PPM tools require some level of customization/configuration for each organization. The key is to strike a balance so that neither the participants are overburdened with process change, nor is the solution over-engineered in the PPM tool. An example of over-engineering is to modify the PPM tool to look and function as the spreadsheets in use before PPM tool implementation. An example of abuse of internal processes is to abandon current successful process for what is considered "out of the box," without consideration of how existing processes will be affected. In summary, implementers should adopt a "meet in the middle" approach to modifying processes vs. tool customization. The business can bend processes and the PPM tool to serve an implementation, but either, if modified too much, will create a challenge for the successful rollout of the application.
Choose Integrations that Add Value.
The best integrations for PPM tool implementation are those that reduce overhead in system management and tie data across the enterprise. Integration to HR and Vendor management systems are examples of value-add integrations that reduce overhead. Without integration to these types of tools, resource centralization in PPM tools can become a cumbersome and time consuming administration activity. Integration to financial systems can prove very powerful, but often complex.
The ultimate success of PPM tool implementation is contingent upon how well defined and managed the overall project management practice is within the organization. Enterprise level reporting from the PPM tool is built from the project schedule up. What is captured in the project is what can be aggregated at the enterprise level. Therefore, the more standardized processes are for WBS construction, milestones, baselining and resource management the more your organization will be able to benefit from PPM tool implementation.
After taking note of the above lessons learned, communication and organizational change management practices are essential to a successful PPM implementation. Communicating the "why" and the "how" internal processes will change is important to aid in user adoption and acceptance. The use of mock ups in design, prototyping in development and conference room pilots are all effective in helping the participants set the proper expectation for your rollout.