When I got started on my first PPM project way back in 2005 we implemented cProjects 3.1 and xRPM 2.0. A lot has changed since then and PPM has evolved and grown from a fairly primitive solution into a robust feature rich solution for Enterprise Portfolio & Project Management. As important or even more important than the functionality of the module itself is the quality of the design and implementation. As a consultant I have seen many PPM implementations where the success of project can be considered questionable not because the PPM tool did not have the functionality to meet business requirements, but because the implementation (design, configuration and custom developments) was not done as well as it could have been.
In this blog I would like to share some of my experiences so that you can avoid these common pitfalls in your projects. I would like to preface this by mentioning that these are my opinions and all of my experience has been implementing PPM for new product development project and portfolio management as part of a PLM solution.
- Having multiple portfolios when all you need is 1 – the Porfolio in PPM is an extremely high level object and for most companies you only need a single portfolio. You need multiple portfolios if your projects are completely independent and separate. For example, you are consumer good company and use PPM to manage NPD projects and IT projects. In this case 2 portfolios, 1 for NPDI and 1 for IT makes sense. You should not create 2 portfolios if you want to segregate your product development projects for food vs personal care categories. In this case buckets maybe a better and more flexible option. Other considerations are authorization requirements and portfolio type dependent config.
- Too many portfolio item and project types – you primarily need different item types if they have different project management processes or Decision Points. You need different project types if you have different integration requirements, field settings, scheduling settings etc. You DO NOT need to have multiple types for reporting purposes which is mistake I have seen only too often. So if you have 25 item/project types and the configuration setting for each is the same or similar, chances are you don’t need that many. If you want to categories items/projects use standard fields such category, subcategory, group or buckets or build custom fields.
- Too many project templates – a template is a starting point for creating a project structure. The intent is to minimize the work that a project manager would do when planning a project. The keyword being, minimize not eliminate. Due to the unique nature of projects it’s not possible to create templates for every possible scenario. Therefore, the recommendation is to limit the templates to a manageable number and control the creation of new templates.
- In general when it comes to portfolios, types and templates I try to follow the “less is more” school of thought.
- Financial integration with PS when it is not required – If you are not going integrate with Portfolio Management Financial Planning or calculate resource/task costs based on an hourly rate and post to WBS elements, reconsider if you really need the added complexity of the standard financial integration. Solutions that I have implemented in the past for a “soft integration” was using a combination of object links to PS project definition and BI reports to analyze date from PPM and ECC.
- Custom developments that are not required – I’ve seen 2 variations of this. Custom developments have been done when the same standard functionality exists, primarily due to a lack of knowledge of the configuration options. The other variation is doing custom development because standard will do the job, but not exactly the way it is requested. The recommendation here is if “standard” is good enough use it. On the flip side, there are certain custom developments which you are expected to do. SAP provides a sample implementation but it was never intended to be used in production. An example of this is the Project Status Report and Approval Document. Ideally if you are using the function, use the SAP standard form as an example and create your own.
- Not planning for BW/BI/BO reporting – “Are you sure we can’t do reporting without BW?” is usually the response I get when I bring up the fact we need to plan for BW to do PPM reporting. SAP provides some good standard content that can be leveraged and the ability to do analytical reporting out of PPM is a key benefit for implementing PPM. At the very least plan for basic reporting to start with and make sure BW data modeling / data warehouse design is part of the blueprint phase. Do not treat BI reports as a just another WRICEF object which only requires a developer in the realization phase.
- Not using ACLs – The PPM security concept is to use traditional PFCG roles with ACL’s and in combination can greatly reduce complexity of your security design and provide more flexibility to end users / power users in managing authorization. All too often I have seen ACL’s not being used and the authorization object ACO_SUPER provided to end users. Doing this in my opinion is a mistake. There is an interesting thread on SCN that discusses this topic in detail - http://scn.sap.com/thread/3452522
I hope this helps you in your projects. Of course, there will always be exceptions and unique scenarios where some of these are not applicable. Feel free to comment if you have any other common pitfalls to share or any questions.
