I talk to plenty of people who view project governance as an overhead or even an unnecessary expense. I have heard some people refer to project management as insurance – but this is a terrible analogy. With insurance, you only get value from it after something bad has happened, and you must put the pieces back together. However, dealing with issues after they arise is only a small part of what project governance entails. Done well project governance is much more about identifying and managing risks to prevent issues occurring in the first place – where you can.
IT projects big and small have a degree of risk. A much better analogy for project governance is to think of it like the critical care team, which guides a patient through surgery. Just like our IT projects, all surgical procedures carry a degree of risk. But the critical care team do all they can to identify and quantify risks upfront and plan out mitigation strategies. The team constantly monitors vital statistics in the theatre, so should anything unexpected happen they spot it early and react.
Should a complication arise, the team works through a process to identify if this is a risk they have planned for. If it is then the mitigation strategy can be put in place quickly, or there is a procedure to stabilise and diagnose the issue.
The care does not end when they wheel the patient out of the operating room. Post-op activities will include follow up to ensure there are no unexpected side effects and perhaps education on actions to take to prevent a relapse or speed-up recovery.
All of these activities have parallels with what project governance should be providing for an IT project. Let’s explore this a little further.
Prepare, Prepare, Prepare
Before the surgeon barks “Scalpel!” and has the implement slapped (handle first of course) into his gloved palm the team has done a lot of work thinking what could go wrong and what to do about it if it does. The projects that we undertake are no different in that we begin our risk assessment during the presales phase. First, we have to identify risks, then we have to classify them, and then we need a plan to mitigate them.
Identifying risks
There are two main areas we need to consider when identifying likely risks. Firstly, we need to consider what types of risks are inherent in the projects we are undertaking. Risks exist in a mail migration which would not exist in a desktop refresh. Harking back to our analogy; open-heart surgery has very different risks to putting a plate into a broken bone.
The second area we need to consider is risks specific to the organisation we are working with. For example, there will be additional risks if we are undertaking work on an environment that includes lots of legacy operating systems or a highly locked-down environment. These are some of the areas we assess – just as a medical team assesses risk factors in their patients such as age, family history, or whether they smoke or exercise.
Identity
Identity is the core construct which underpins these types of migrations. Mappings of permissions, products, business processes, and toolsets in addition to the critical data governance portion, all start with identifying who and how. During the MAD process, we have found identity needs a lot of attention to ensure the correct transition and end-state. Changes to identity are disruptive and complex, so our user experience inputs are critical here to defining what identity will mean to the business. Here are some of the areas we make sure we cover with customers:
- Overarching identity strategy – This speaks for itself but needs to be discussed., Are we changing domains, what should the branding look like, are there any legal requirements in this process, and much more
- Governance – This can mean many things, here we are looking at how identity, access, and data are governed
- Security – What is the current security posture and what is the desired end-state for this? As identity is the core of security, this is the perfect place to delve into the security requirements of the project
- Policies and procedures – What are we moving from and too from a policy and procedure perspective? This can mean technological changes as well as fundamental process changes
Classifying risks
Having a comprehensive list of risks is excellent – but we need to make sure we give them the appropriate attention level. To do this we have to be able to answer two key questions.
- How likely is this risk to occur?
- What is the impact on the client if it does?
Putting a client lens on question two is critical. How a surgical team might prioritise if they are operating on a professional athlete than they would if they were operating on a knowledge worker.
Risk mitigation planning
Once we have identified risks and understand each of them’s relative importance, we can develop a mitigation strategy for them. This includes both understanding what steps can be taken to prevent the risk from occurring and what actions will need to be undertaken should the risk occur.
Monitoring the vitals
When the patient is on the table, there’s a lot of care and attention. A number of critical metrics are monitored which allow the surgical team to identify where problems might be occurring before they are overtly visible.
During an IT project, we monitor a range of metrics to ensure the health of the project. These would include your standard project management staples such as tracking against a schedule and budget and include some metrics specific to the risks related to this technology or this client. For example, if one of the risks is that data migration could be slower than expected, causing a significant impact to the schedule, we would be monitoring the throughput of the migration very carefully.
Complications
Regardless of how thoroughly you plan, the unexpected can and sometimes will occur. Having a communications plan with clear escalation paths is vitalas it allows you to quickly communicate issues to quantify the new risk and develop a plan. Depending on the risk, the response could be as simple as capturing it on the project risk register and continuing to track it. In more significant cases, the project may need to pivot, increase or decrease the scope or possibly even terminate – all of which can be managed through project change management.
Postoperative Care
A project does not end with the implementation. Firstly, we enter a period of care where we and the client pay close attention to make sure we are aware of any issues and can quickly respond to and resolve them. Once the environment is stabilised, we begin the transition process and hand over to the client’s IT team, their managed services provider or our own Enhanced Support Services – depending on who will take care of the future environment. Regardless of who we are handing over to, we need to make sure they have the right skills and understand the patients ongoing care plan.
In Closing
Sorry – I could not avoid that pun! Hopefully, this has helped you to look at project governance in a new light. If you would like to hear more, make sure you catch our upcoming webinar to explore some real-world experiences further.
