Recently I was involved in a project that taught me several valuable Project Management (PM) lessons. I would like to share these lessons with the PM community, especially with new project managers. I inherited this project from an experienced project manager. Like many government departments, we have several high profile online applications that people use coast to coast on a daily basis. Our business client wanted to improve user experience for a number of these applications. However, the underlying IT infrastructure could not support those functional requirements. There were some performance issues with those online applications as well, especially during the peak usage season. These were the two main drivers of the project. The major deliverables of the project were to buy a middleware that would fulfill our technical requirements, install, integrate, and configure it, and re-write parts of the existing online applications to take advantage of the new middleware. That was the project, in a nutshell.

As you can imagine, procurement was one of the major components of this project. Government procurement is always a complicated and time consuming process – we need to be fair and transparent throughout the process and at the same time we have to strive for the best value for money. At the beginning of this project (I was not part of the project team at that time) an OEM, whose middleware was known to be compatible with our infrastructure, offered significant price discount for licenses with a caveat that we had to buy the solution within a certain period of time (by the fiscal year end). This needed sole-sourced contracting and our senior management decided against it because of high dollar value of the contract. So we had to go to the market with a full-fledged Request for Proposal (RFP). This whole incident costed us significant time. Anyway, RFP process completed and we had a winning bid at the end.

A financial review of the wining proposal revealed that the vendor quote for the proposed solution was significantly higher than our initial estimate. Quoted ongoing maintenance and support costs were significantly higher as well. Such differences in costs were due to the combination of following facts: the estimate was done about a year and half ago; as mentioned earlier, vendor indicated some sort of price reduction for the software licenses – estimate was based on this assumption; underlying infrastructure may have grown and thus the number of licenses required has since increased from the original proposal etc.

The significant difference between contract and planned costs gave us an opportunity to re-visit the original project business case. “Continued Business Justification” is a best practise and one of the core principles of PRINCE2. In our case, while reviewing the business case it was realized that one of the key drivers of the project, the performance issue, was no longer valid because of hardware upgrades and move to a 64-bit JVM. Also, improvement of user experience alone did not justify the cost and effort required to continue with the project. So, we decide to cancel the project. By doing so we were able to save over $2M. This is the first time I experienced cancellation of an approved project at the mid-way.

Lessons learned: As I mentioned earlier, I learned some valuable Project Management lessons from this event. Below is a list that summarizes such lessons:

  • Whenever you takeover a project in the middle, try to obtain its history and background information, as much as you can. For my case, I did not know the license price discount earlier offered by an OEM (this fact was not documented anywhere); the project cost estimate was based on this reduced cost. This estimate was only valid if we had gone for a sole source contracting. But we did not – we went out for a full fledged RFP; obviously the successful bidder did not include any discount in its bid price and that was the main reason for the cost to come significantly higher.
  • Whenever you takeover a project in the middle, always critically review existing project artefacts, especially cost estimates, schedule, and project plan. Make revisions as you see required. It is important that you read all documented assumptions, make sure if they are still valid, ask questions, and look for diverse opinions.
  • In every phase of the project confirm the continued business justification – this will give you opportunities to save your organization/client/tax payers’ effort, time and money.
  • Cancelling a project can be challenging. No matter how rational it is or even if the business case is no longer valid, some people may take it as personal. When people work on something intimately, they establish some sort of emotional attachment with it. Expect resistance from these people. This is human nature. As a project manager you have to handle this tactfully.
  • Being able to cancel a project when the underlying business case is no longer valid reflects the maturity of your organization’s project and portfolio management process.

What do you think? Do you have any comments, inputs, feedback or ideas that you would like to share with us? Please feel free to use the form below. We would love to hear from you!

Posting Guidelines: We encourage all readers to share their views on articles and blog posts published in the Red Monster Consulting (RMC) website. We hope each conversation thread within the RMC website is constructive, thought-provoking, and contributes to further enrichment of knowledge. We DO NOT require readers to sign in or register to comment. However, in order to ensure the quality of the discussion, we reserve the right to edit them for clarity, length, and relevance; comments that are abusive, overly promotional, mean-spirited, or off-topic will be deleted. All postings become the property of RMC.

2 replies
  1. William Hody
    William Hody says:

    I’ve seen many projects go ahead that should have been cancelled. Refreshing that some projects are cancelled when they are no longer viable.

    Reply
    • Rizwanul Bari
      Rizwanul Bari says:

      I agree – sometimes it is because of ego of the executives, sometimes it is the incompetency, and sometimes it is that mentality that since it is approved, we have to complete it. We should review the project business case (to see if it is still viable) at every stage of the project.

      Thanx for your comment, William.

      Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *