How to return Business As Usual when the Project has not delivered the requirements?

Question

A product has been released with several open issues that have been ranked as minor by the PM and Project Assurance.

The Board believes that with the functionality released the Business Users can operate and have agreed that Minor releases will be delivered throughout the year to resolved the open items.

Nevertheless, the facts are the following:

• The Business Case required translation into more technical specs and expected behaviours were missed.
• The Development Team communicated that certain bits of the functionality were not working as per the Business expectations and advise a process change that was not aligned with the Business Processes.
• The Project Board approved the content but did not approve any changes to the Business Processes.

The user cannot return to Business As Usual since the functionality is preventing operational processes rather than improving them. Heavy manual intervention is required from Ops to deliver the service to the ultimate customer. The project has just failed.

From my personal point of view, the lack of communication between the Business Users and the Project Team led the project to this position. In order to fully resolved the open items according to specifications throughout the next releases, what level of involvement in Operational side (real business) is required by the PM?

Answer 1

If the project has concluded ("ended"), then the project manager's work is finished.

In either case, it sounds like the Right Thing to Do is to initiate another project that will get the product aligned with the business. A good PM would sit down and do an after-action report/lessons learned on why the original project failed:

• How were the requirements gathered incorrectly and/or incompletely?
• How did the design fail to take into account the users' needs?
• Where did User Acceptance Testing fail?

The fact that the product failed to meet the actual business requirements sounds like a flaw in the requirements gathering/design phase. If the product was delivered and the user acceptance testing phase passed somehow, something is fundamentally wrong.

Answer 2

So the main problem is actually that all involved people don't have the same perspective about the output of the project. Changing this is mandatory.

A project which has failed is not a project which has almost delivered all the features and needs some minor changes. So what needs to be done is to make sure everybody get the same perspective about the status of the project.

After that, the business part will be ok with the current situation OR go back to the old tools they used before the delivery and the project team will schedule minor changes OR schedule some major work to finish the project.

I'm not sure what your role is in the story, so I don't know what you need to do. If you are with the sponsor, you need to explain clearly your disappointment to the project manager. If you are part of the project team, I'm not completly sure about your motivations, at this point.