Murphy's Law states, "if anything can go wrong, it will go wrong." Learn to keep Murphy at bay by wisely dedicating time to risk management and mitigation. In this video, Bob McGannon helps you combat the common risk types in technology projects including; the need for technical integration, preparing for organizational change, managing multiple vendors and sponsorship related problems.
- Murphy's Law states, "Anything that can go wrong "will go wrong." Sometimes I think Murphy is a ghost that haunts technology project managers. In order to keep Murphy at bay, you need to dedicate time to risk management and mitigation. In technology projects, there are four common types of risk. The first is technical integration. In every project, there's a genuine risk that you don't fully understand the interdependencies between various systems.
You normally discover this when you make a change, things fail to work, and you end up with a bunch of stakeholders you didn't know about screaming in your office. You can avoid this scene with the following mitigation actions. First, focus on documenting the integration components that are changing for your system and the other systems as well. Next, have an architect verify the accuracy of the integration documentation.
Then, test and test and test some more. Even a good technical team will miss things. Integration testing can identify problems prior to production cutover when your business would be impacted. Finally, don't overengineer the solution. Only integrate when it makes sense and provides business value. A second common risk is not preparing for organizational change. Many technical PMs focus on the technology when in reality it's the business change that presents the greatest challenge.
Actions you can take to mitigate the risk and ensure your organizational change is being managed effectively include development of an organizational change management plan. If organization change is not understood in your company, hire an organizational change expert to guide you. Ensure as is and to be process maps have been developed so you understand the magnitude of change to expect. Identify change champions to guide your business areas through change.
And finally, test the organizational change via new or changed process walkthroughs. The third common risk is when multiple vendors are required to implement your solution so your risk is multiplied by the number of vendors involved with your project. Each vendor may have a different approach to how they want to operate, yet vendors need to work together for your project to succeed. Let me recommend a few things you can do to mitigate vendor risk.
Consider dedicating a team member to vendor management. This person should be the single point of contact with all of your vendors. Hire as few vendors as possible. If you have a vendor that provides multiple services and they provide these services well, consider using that one vendor. Have a good contract administrator that can verify you have the right type of contract for the services you're procuring. Treat vendors as team members. They're part of the vendor team and should be included to ensure effectiveness.
And last, set expectations on how scope change management will be addressed. Everyone on your team should be educated on this process and it should be enforced to help you control vendor costs. And the final common risk is sponsorship-related problems. My toolkit of techniques to avoid sponsorship-related issues are as follows. Ensure your sponsor understands their role. Educate them if needed so they're comfortable with their responsibilities.
Use your sponsor's time wisely. Talk with them frequently but for short periods of time. Make sure your sponsor has the authority to make decisions and has sufficient time for sponsorship responsibilities. Try to find other sponsors if appropriate. Create a project steering committee to share senior management responsibilities and include technical and business management. Yes, technology projects have a lot of risks, but there are many things you can do to mitigate them.
Once the mitigation actions are agreed, add them to your project schedule so they can be tracked, managed, and reported. Do this and you're less likely to need to call the Ghostbusters to rid your project of Murphy and his relatives.
- Identifying and managing stakeholders
- Guiding process and organizational change
- Considering a cloud-based solution
- Planning a technology project
- Assessing risks and changes
- Executing a technology project
- Addressing challenges such as conflict and changing priorities