8 Mantras for Managing Risk in Your PPM Deployment
As with any kind of major technology implementation, the deployment of project and portfolio management (PPM) software, such as Microsoft Project Server or SharePoint, comes with risk. Those include lack of consistent support from senior leadership, ineffective change management, or tepid commitment on the part of the stakeholders affected by the implementation.
One of the most common mistakes I have seen is not managing scope or requirements effectively. This can lead to a litany of issues: scope creep, loss of adoption momentum, even project failure. In this article, I share common pain points and risks in implementing PPM technology along with appropriate measures to manage and mitigate those risks. The overall goal: to help you get optimal value for your investment.
Mantra #1: Engage early to secure and sustain executive sponsorship
Right from the earliest stages — during the kick-off meeting, the requirements workshop, the pilot and design sign-off, the change and deployment team needs to engage with the senior executives, sponsor and senior users to ensure they understand what’s changing and how it will benefit the business. This practice will help mitigate the risk of reduced levels of sponsorship as the project advances during its lifecycle.
Mantra #2: Get your scope right, lock it and hold the “key”
Change agents and technical leads within the business need to be aware of scope and to manage it well. Documenting what’s in and out of scope can help you “lock” your agreed boundaries in implementation down to a baseline document. This document needs to be reviewed with the senior user and signed off. Then you need to refer to the scope requirements document constantly throughout the project to ensure control. This helps manage change control and reduces the risk of scope creep. Other benefits of this practice will be more effective management of project cost, better management of team reputation, and a reduction in the risk of the project being delayed due to scope creep.
Mantra #3: Involve end users right from the start and make them feel part of the success.
You can develop a solution to a degree of near-perfection, but unless the frontline and the end user group is regularly engaged and involved from early stages of design, development, testing and release, the risk of poor or no user adoption is imminent.
When you have agreement on requirements and the design phase starts, send out a “teaser’ communication for the design kick-off and introduce end users to a high-level view of the system and its benefits. In parallel with development, test cases can be developed with a focus group of end users that can feed into the “user acceptance test” document. This document can later be used to carry out user acceptance testing (UAT). Since the end users would have already taken part in the development of the test cases, the assumption here is that they would accept the system more readily, would be willing to devote time towards the UAT exercise and also would gain familiarity with the enterprise system. This way, you’ll reduce the risk of project delay due to time spent in user training or seeking buy-in.
Give your sponsor and senior user regular updates on your plan and progress status and gain agreement on next steps during the reporting interval. The senior user must have full visibility of the effort and the amount of time end users are spending in their daily schedules for testing and related activities.
Mantra #4: Regularly review your best practice for making change
How well defined and applicable is the organisation’s best practice in executing the technology change strategy? Is the approach relevant and up to date to support the deployment of the latest EPM technology to deliver a programme? The team needs to review its method regularly with the consultant and subject matter experts in programme controls to ensure that this best practice can be applied to achieve the desired result on time and cost effectively.
Examples of best practice are not confined to the implementation of technology but also involve governance and risk management. One example is carrying out a detailed risk assessment to obtain an overall risk “score”; this summarizes the aggregate response to the risk questions and can be used to understand the “risk tolerance” and “risk appetite” of an organisation or business unit.
Mantra #5: Engage independent quality assurance
The work executed by the team on a solution needs to be reviewed by an independent and fresh pair of eyes to mitigate the risk of errors and quality defects in the end product. Quality assurance is hardly a new endeavour, but it’s not always applied to real-life technical deployments that are constrained by resource, cost and tight timeframes.
While the topics of defects and variability in products are prevalent in Six Sigma for the manufacturing domain, they haven’t gained much of a toehold in EPM or other forms of technology deployments. If we visit the cost of poor quality, we understand that both internal failure costs (incurred before delivery of the system) as well as external failure costs (incurred after delivery of the system) are involved. In Six Sigma terms, a five sigma level of 233 defects per million opportunities results in up to a 15 percent hit to sales. It is therefore necessary to introduce quality assurance as a crucial exercise in reducing defects and increasing certainty.
Mantra #6: Do not be afraid to constructively challenge the requirements or design
Is the system viable and easy to use on an operational basis? While requirements may be agreed upon, the result might still be unfeasible for the business, especially if the requirements haven’t been analysed or tested. For instance, if it is agreed as part of the requirements that an existing business system for HR payroll should be replaced by the new system being implemented as part of an ERP implementation, you need to analyse this business objective and requirement. If the objective is to move or migrate to a new system in place, factors should be considered such as:
- What is the business objective driving this need?
- Will this move support the business objective?
- Is the proposed approach the only option and have other options been evaluated?
- What are the risks in following this approach? (For instance, if data isn’t migrated or backed up from the old system, there’s a risk of data loss.)
- Has this move been tested for feasibility in the form of a pilot?
The software requirement should support and be aligned to meet the business need, and not the other way around. The business rules should drive the technical requirements of the system being deployed.
Mantra #7: Manage and embed the change effectively
Maintain the human touch during the implementation. Industry experience teaches that PPM implementations shouldn’t be viewed as mere “tool” deployments; these encompass a technology-enabled business and people change — particularly, their acceptance of the change. There’s a good reason that change management is defined as the process by which to win hearts and minds. Day-to-day, the business units that rely on this system must feel confident and comfortable in using it. To achieve this sustainability in adoption isn’t easy.
However, the risk of increased training effort and cost of poor use is of high probability if the transition to the new system isn’t managed effectively. This requires robust communication and testing and training plans with regular assessments to ensure users are on board.
Mantra #8: Define early-warning indicators and conduct regular health checks
When you’re given a warning early on in the journey, you get more time to respond. It’s essential to define early warning indicators while deploying a system. Regular programme health checks need to be conducted to understand how the implementation project is going. The performance measures can be used to provide early warning to the programme office.
Here’s an example of an early warning indicator. If priorities of the programme leadership are regularly changing, the amount of time and the valuable input that is required from the senior stakeholders can vary with their availability. If this behaviour is identified, it can serve as an early warning indicator of the possibility of a problem at a stage in the deployment project when timely input is required — such as feedback on a system pilot. Reduced levels of interest by stakeholder group is another consequence of changing programme priorities.
The early warning indicator can be used to detect risk and plan the mitigating response. A “lessons learned” document and an “issues log” from a previous deployment can guide your thinking about what to watch for.
Keep your eyes open, always
The Pareto principle applies: 20 percent of risks will create 80 percent of the impact to your technology deployment. Measuring the potential impact of risks and then prioritizing those is critical to managing risk effectively in a PPM or other system deployment.
Although this doesn’t rise to the level of a “mantra,” I would recommend that you keep your eyes open at all times to the small cues and clues that would indicate new kinds or risk. Applying that kind of data in your work can add up to fewer issues during the deployment and optimal financial benefits.
Sharath Kumar is an EPM Consultant in MI-GSO | PCUBED’s CSG Team and based in London. As a certified project and portfolio management practitioner, he has worked on initiatives with public sector, time-to-market, manufacturing, financial services, energy and nuclear clients. Sharath’s advisory experience covers a broad range of services: portfolio optimization, value engineering, change management and IT transformation. Sharath currently owns the Knowledge Management workstream that champions thought leadership in the organization.