A project manager of a failed project gives 6 tips to his colleagues.

I recently met a young project manager whose project was in the early stages. He started off by telling me that the project was going well. They had purchased a ready-made software that will be implemented for their business. The Vendor´s sales person had told me that they had done dozens of similar projects. “Professionals at work”.

At the company management’s request, I interviewed the project manager and I conducted a feasibility study to find out if the project is going to succeed. After a couple of questions, it became apparent that the project manager’s response to the status of the project was based on complete ignorance. In the project plan, the timeline showed that about 50% of the definition phase was ready, so he assumed that the readiness of definition phase is 50%. The project manager blindly believed the vendor’s promises. So foolishly, the conditions for managing the project had not been built.

Normally, I investigate the status of the project n by asking a few questions, but this time I made an exception. We decided to call one of the vendor’s customers and asked them for some feedback. The feedback was eye-opening!  Here is a small piece of “referencing” experience:

The definition was implemented so that the consultants interviewed the business experts. They probed with questions and the questions were answered the best they could. Current or target processes were not described. The work was slowed down by the lack of key personnel for each meeting.

Our project manager commented: “Sounds familiar, we have the same situation now.”

The specification document included descriptions of different functions. More specifically, there were features that caused modifications. The resulting solution was not described. Because the business experts were not familiar with the new application, the overall image could not be formed.

The vendor made a fixed cost estimate based on the definitions made. The customer thought that fixed cost would mean that the project had a fixed price. But the actual price was more than twice the original. Numerous change requests increased the cost of the project. In addition, the timetable for the project stretched more than three months beyond the original schedule. Roughly about half of the desirable benefits were achieved. Now the system is being further developed in order to achieve the original goals. However, the final budget will be more than triple.  In addition to this, only the subcontractor’s costs have been included, the overtime of our own staff still uncalculated.

We have lost incomings because we are not able to reach our deliverables.

On the other side of the table, the project manager’s faces varied between horror and disbelief. “No, we’re in bankruptcy if we do this. We are launching a critical software for our business. If that doesn’t work, then the entire business is paralyzed. We cannot afford to pay even double the cost, let alone triple costs.”

The Referencee clarified the problem from his point of view:

The biggest problem was that we did not run the project, but we were the vendor. We no longer had control of the costs anymore thus giving the opportunity to increase costs. The problem with the fixed-price project was that because of the poor quality of the definition, the supplier was able to charge for change requests. And because the vendor answered the definitions, they would not want to make it perfect. When we realized the severity of the situation, it was too late. We were in a situation where it would be far too expensive to interrupt the project. Similarly, the continuation of the project was too expensive. So we deployed an unfinished solution that we were able to continue to develop all the time. We strived to eliminate daily user problems.

The project manager stood up and walked around the table. He asked us to wait a moment and returned with the CEO. The CEO received an abbreviated version from the reference customer. After a moment’s silence, he asked how to proceed.

The reference person’s proposal was as follows:

-If you’ve ever got a project with a waterfall model, here are a couple of tips:

-Focus on the definition. Describe the current mode and target mode. Make sure each workshop has the right people.

-Slip the specification document into smaller sections according to business operations. This way you have manageable partitions to handle.

-It is difficult to find the missing items from a traditional definition that are important to your solution. Be careful that you have a clear enough picture of all your business requirements.

-Make a note of all your open questions for yourself and handle them effectively.

-Think of a way to fix, test and record bugs.  Forget those excel and emails.

-And most importantly. Build reporting so, that you can lead your project. And when you lead, you react. If you do not know, purchase some help. Although it is expensive, it so much cheaper than failure.

-There was an unbelievable silence in the room. The CEO asked if they had the chance to succeed. What should we do now? I frowned on the CEO, nothing has been lost yet. We will lead the project and ensure success.

We started to take the project with the following measures:

–  We imported the project’s project plan to ProjectTOP and supplemented it with the other activities of the firm.

– It was made clear which other projects in the business are ongoing.

– Definition phase was underway.  Afterwards, the customer will choose the vendor for the delivery project. We made a plan on how to get the definitions so comprehensive so that we can genuinely choose the right vendor.

– We collected all the open issues and wrote them into ProjectTOP.

– We made sure that the project’s solving ability is in order.

– We built reports that enable the project manager to have a real-time status on the project.

– We introduced the ProjectTOP model for the key persons.

The end result was that the vendor changed after the definition project. When a customer had described the business needs, it was found that the solution offered needed to make too expensive customizations. In the original tender, one vendor was rejected because their offer was more expensive. But after business descriptions, it was found to be the most advantageous option.

The project is currently doing just fine. So really the status is OK. The project manager has a real-time progress report. And with the ProjectTOP model, he knows what activities need to be designed and why. And most importantly, the project manager understands now what the implications of his decision are.

Recent articles

ProjectTOP - Platform for managing development

Platform for project management and all development work for businesses and the public sector.