The Mindavation team has frequently seen situations where projects are clearly in trouble but nobody can seem to find a red pen. Amber or yellow projects abound in the portfolio, yet the dreaded “help from above” prevents the project and PMO management from whipping out the red marker of truth. Why is this so pervasive? In most cases, it is because the “help” that comes when a project is labelled as troubled is no help at all.
What usually happens when the red status of truth “escapes” is that management or the PMO swoop in with more reporting requirements, in an attempt to right the sinking ship. The additional reporting typically doesn’t improve the project; in fact it usually makes it worse.
In a large number of cases, the issue with the project is not the project manager’s lack of reporting; it is a lack of true sponsorship or major stakeholders that cannot come to agreement on the purpose and direction for the project. Additional administrivia won’t fix the problem; supporting the project manager to work with the stakeholders with more conviction and courage will.
More support, less paperwork.
In the instances where the project is languishing because the project manager has not managed his responsibilities well; more paperwork won’t help here either. They have not successfully utilised project management processes already in place; adding more tools and processes to the plate of the project manager will likely make things worse. Mentoring, coaching and support should help.
More support, less paperwork.
Are you avoiding the red pen in your organisation? So, what does your organisation have a tendency to do when projects go bad? What steps can you take today to reveal more truth (yes, use the red pen) and add more support to the project manager and team, rather than additional futile administrative work?
Project and program management, business analysis and business change professionals around the world sing the praises of appropriate risk planning. Many even attempt to do risk management, beyond the typical document that is created at the beginning of a project but is destined to become lonely sitting in the bottom drawer of one’s desk. We applaud that effort, as it is the first and most significant step in creating a “risk management culture.” We need to go way beyond that however, if we are to see a significant change in the statistics for failed and woefully over budget initiatives. What is the step we need to take? We need to create “shared risk” management plans.
The typical risk management plan we see addresses the risks as perceived by the technical project team – and at times, some higher level risks associated with business change. Unfortunately, the mitigation or response plans for those risks are typically limited to things the technical team will do, or address time or financial contingencies. Rarely do we see a risk response plan that proposes actions to be taken by both the customer organisation and the service organisation that provides project solutions. This one way street is typically not effective, does not reflect the business partnership that is required for successful initiatives, and is short sighted. It is fixable however, if we utilise our project management relationships, leverage our business analysts to the fullest and make a commitment to a premise: there are no technical projects! All projects are business projects; and many have a technical component. Our risk management plans need to reflect this reality, and be driven from the business perspective.
Are your risk plans truly shared risk plans? Does the risk analysis being performed consider business risks and response planning? Can you name (and address!) the top three risks you have on your current projects with shared risk response plans?