TUG Buzz! for September 5, 2012



Project Risk Case Study:
It's Just an Upgrade

By Debbie Gallagher

This case study is a true story.

Background
The project manager was developing a project charter for his new project. He and his supervisor expected this project to be low risk and quite straightforward, as it was just an upgrade to an application that had already been running for many years in the organization. The application was used daily by approximately ninety percent of employees across the country.

The project manager met with his assigned mentor to discuss the project.

Existing risk assessment
At this company, it was a requirement that the project charter include a risk assessment section. The project manager included as risks some items that had been problems on previous projects, such as business resources and IT code promotion resources not being available. When questioned, the project manager said there was no particular reason to believe these would be problems on the new project, but he wasn’t sure what else was relevant to include as risks.

What the mentor learned
In discussion with the project manager, the mentor learned more about the project, which was in the planning stage prior to charter approval and project launch.

The application vendor had been slow to respond to requests for help with planning the upgrade.  The vendor was apologetic about the lack of assistance provided and explained that they had recently sold a very large engagement and were very busy as a result.

The existing application had numerous customizations and interfaces, almost none of which were documented. Upgrades of this application had been attempted before, but the projects were never completed due to the difficulty in replacing the undocumented customizations and interfaces.

The project sponsor had just gone on medical leave for several months and appointed a junior manager to act as sponsor in her place.

The mentor helped the project manager to identify three significant risks: (a) unavailable vendor resources; (b) undocumented customizations and interfaces; and (c) inappropriate sponsorship.

Actions taken
The mentor suggested several follow up actions to the project manager to try and manage the risks before launching the project.

The project manager approached the application vendor about alternatives for resourcing the project, but the answers were discouraging. The vendor had no business partners trained to perform implementations and also could not recommend any other companies or individuals who might to able to guide the company through the application upgrade process.

A business analyst was assigned to start documenting the customizations and interfaces, but the work was progressing very slowly due to internal resource constraints.

Although the original project sponsor was available for a brief phone call, she was unable to suggest a more appropriate replacement sponsor for her expected several-month absence.

Unfortunately, none of the actions resulted in lower risks.

Updated risk assessment
After these follow up actions and further discussion with the mentor, the project manager had a much more realistic view of the project risk.

The vendor’s lack of availability during planning raises significant concerns about its ability to provide appropriate resources for the project itself. Noticeable lack of availability during the sales cycle made it clear that the vendor was overwhelmed by the large contract they had just signed and would not be focused on this company’s upgrade. Even if they managed to provide a few resources, the vendor would not be able to support them to the extent needed.

Undocumented customizations and interfaces had already caused previous upgrades of this application to fail. Proceeding with the project without developing a good understanding of the customizations and interfaces would certainly cause the project to fail once again.

The lack of an appropriate project sponsor is a risk that sounds alarm bells for any experienced project manager.  The appointment of a low-level resource shows a lack of understanding of the role of the sponsor. Someone too junior to determine business priorities and commit resources is not an appropriate choice.

Any one of the three risks described would put the project at significant risk of failure. Given all three risks, it would be nearly impossible for the project to succeed. 

Recommendations

The project manager discussed the revised risk assessment with his supervisor. The supervisor was reluctant to delay the project but did finally agree that it was too risky to proceed at that time.  However, the discussion of the risk with the sponsor would be a delicate matter, especially given the concern about the inappropriateness of the sponsor.

The supervisor arranged for the IT vice-president to have a discussion with the business vice-president (to whom the original project sponsor reported).

Epilogue

The two vice-presidents agreed that a different project was needed first, one with the purpose of documenting the existing customizations and interfaces. The IT vice-president agreed to commit resources to this predecessor project.

They expected that by the time that project was completed, the original project sponsor would be back from medical leave and the vendor would have had time to train new resources.

Conclusion

Given the risks identified for the project, the vice-presidents made the right decision. Delaying the project and starting with documenting the customizations and interfaces was the best option to set it up for success.

Evaluating project risk is frequently a challenge for junior project managers. It is typical for new project managers to focus on schedules and budgets, and develop their understanding of risks and issues at a later stage of their project management career. Providing a mentor for the project manager was a wise course of action for the company. The mentor was able to guide the project manager through the risk assessment process, leading to a more realistic evaluation of the project’s chance of success.

Debbie Gallagher specializes in project management and business analysis. Debbie previously worked as a systems implementation consultant, and as an IT project auditor. She can be reached by email at debbie@gallaghers.ca

Copyright 2012 – Debbie Gallagher

BackBack


TUG is the proud recpient of a 2012 Maxava iFoundation grant.

Maxava

TUG GOLD Sponsors

 
 
 
 
 
 
 
 

Do we have your current e-mail address and other contact information?
Email the TUG office to keep us up-to-date.   

Copyright 2012 - Toronto Users Group for Power Systems (Power Systems is a trademark of IBM Corporation.) IBM and the IBM logo are trademarks or registered trademarks of International Business Machines Corporation in the United States and are used under license by IBM Canada Ltd. Linux is a registered trademark of Linus Torvalds. Other logos appear in this message for reference purposes only, and are trademarks or registered trademarks of their respective owners.

     eNewsletter design by Eclipse Technologies Inc.