This is a true story. The company name
has been changed.
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 first risk assessment
The project manager met with his assigned mentor to discuss the project. 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.
The real story
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 as he was also assigned to a high-priority project.
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 raised 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.
Copyright
2015 Debbie Gallagher
