This is the first blog to follow in the series I started on commencing the implementation of a project portfolio management tool. You can read it here. I shared 7 key inputs, or considerations, that we have found consistently emerge when we talk about this undertaking. Customers, prospects and industry peers have all said they encounter these to varying degrees and dealing with them effectively at commencement significantly enhances the chances of an efficient implementation.

In this blog, I want to share my thoughts on the value associated with the implementation of a PPM tool; the investment rationale if you will. More simply, how can we bring the value (benefits) we spoke about in the business case to life? Many articles speak about the benefits of implementing a PPM tool but often the value proposition lies in ‘reduced administration’, ‘more time for PMs to manage outcomes, not administration’, better decision making’, ‘greater agility’, and so on. All relevant and undoubtedly true to varying degrees. Certainly achievable with any good PPM tool and appropriately managed implementation, process and training, but I was keen to share my thoughts on how to help ASSURE these outcomes are achieved during implementation, ultimately helping realise your benefits; many of which will be qualitative rather than hard numbers.

1. Data hygiene is vital

A tool should aim be the single point of reference for all data relating to projects, programs and portfolios. While it is of course possible to connect different data sources, an ecosystem is a lot more complex to build and maintain than a PPM tool that is purpose built to store data of this type. Focus early on establishing the data set required at project (and program) level to ensure consistent and sufficient quantity and completeness of data. From here it becomes all about process and the rigour associated with maintaining adherence to it. Make it clear what the minimum acceptable requirements are for each period of reporting. Separate those things that change less often with those that are more frequent. We preach the ‘little and often’ mantra for updating data to avoid lengthy, lumpy spells of report-writing. If your tool allows for delinquency reporting, work with those that are behind or submitting poor reports to understand why, then support and remediate.

Stress the importance of quality content in project status reporting too. That is, write for an audience that may not know the intricacies of the project, but need a good understanding of its status. The important thing to remember here is that with good reporting at project level (quality, completeness and timeliness), anyone wanting the information at program, portfolio and any other level/view, can leverage the tool’s aggregation capabilities to see this, without the need for custom reports or bespoke spreadsheets. Encouraging people to self serve or providing ‘on demand’ reporting is very efficient but does require the most up to date source data.

2. Avoid duplication

If two or more tools are required, try to avoid duplication. Sounds simple, but it can be hard. Nothing is good about double keying… It is nothing but frustration for PMs and when the sources differ, leads to confusion for stakeholders and unplanned executive questioning.

Two common areas we see are risks/issues and scheduling. Often there is a corporate risk register in addition to those maintained by projects. There is usually some level of guidance, but focus on ensuring only major/significant risks or issues are reporting to corporate level. Keep project-level items in the tool and where possible, use APIs to push to other systems. Keeping the PPM tool as the source of truth is vital here.

With so many tools now available allowing simpler collaboration, many participants are using something for workflow, task/people management, kanban boards, etc. but still need to report up. In this case, we advise keeping/marking only major milestones and deliverables that are important for stakeholders and dependent activities. Similarly, if you are maintaining complex schedules, perhaps it’s best to keep using the tool you have been for this and make sure you only key in important information into the PPM or reporting platform.

3. Standardisation

Standardisation should exist across all core data assets to ensure consistent interpretation of information presented to decision-makers. This is not about stifling agility, but more about enhancing it. Removing/minimising any chance of misinterpretation or worse, interpreting incorrectly, goes far further towards damaging decision making and can result in sunk time/cost that ultimately needs to be recovered.

Executives and steering groups have a certain capacity to read, interpret and act on the information they consume. Status reports with data in the same place, report packs that follow a standard pattern and creating consistent definitions for things like RAG status are all fundamental elements for your PM framework, but are often missed and customisation starts to take over. A best of breed approach can help. That is, involve the PM community to identify what ‘great’ looks like from good reporting or successful projects/PMs and drive to standardise on this. Also don’t forget to educate the steering groups. Many are made up of SMEs or business unit execs who may not be experienced or indeed understand their role in the project/program decision making process.

Focusing on these three outcomes during implementation is critical to ensuring your organisation will be able to optimise its investment. They may sound obvious, but can be tricky to get bedded down during the implementation phase as they are more about people and process than they are about technology or the tool itself. It can be helpful to think about capability or maturity levels too. Don’t try to nail everything from the outset. Plan for a level 1 maturity and build on that using simple measures that help gauge the quality and completeness of reporting and data capture while making sure everything is being captured across all projects and programs. Place a special focus on agile teams to ensure they are part of the reporting process. Being agile does not mean you don’t report.

To extend the discussion or to offer any more viewpoints, contact me directly at gumley@zeno.pm.

Please feel free to leave comments.

#zenopm#zenopm #1000milejourney#1000milejourney #thefirststep