EE 606 – Technical Project Management – BLOG POSTING From Shyam P.Prabhakar

November 10, 2010

Why does Projects fail even when we have PM strategies in place?

The project which I want to mention here is a LOB initiated project, which I am naming it as PROJECT X, because of security reasons, was a 1 year 3 months project and it was approved by the Capital Expenditure team. The project’s objective goals were to identify each officer’s portfolio and make decisions on his/her incentives pay. The accumulative performance for each employee over goals/budget was calculated by the quarter. This is a quarterly review process to evaluate employees working in a banking world. The incentive pay for the employees is one of the most complex and sensitivity in the Banking world. Any unclear reported incentive could cause quite a few confusions between the Corporate LOB team and the officers on the field.

The primary reason for choosing this topic is to find the reason why PROJECT X failed. The cost identified for Project X was estimated over 2 million dollars and was assigned to vendor driven PM team and a Development team. After the project demise the aftermath cause the company approx 2 million dollars and also eliminated some FTE positions.

As investigating project in details, I was able to find the main problem which caused the failure. Though I came across different variety of reasons which could have caused the project fail, the main and foremost problem was the waterfall approach the PM team adopted. I have met with business stake holders for this project and couple of developers (which is in my team now for the same project re-initiated) to know what caused the demise. As per the business stake holders, there was only one initial review occurred for verifying the Business Requirement Document and from there for over 9 months there was no communications between the PM team and the Business. LOB called for a project review meeting after 9 months to review the project status. And they found out that the project was incorrectly design. The translation of BRD to the technical specification itself was wrong. This really created Havoc between the LOB, PM and development team. As usual the blaming sessions started among the LOB, PM and the development team. After further review thru the BRD, it was clearly stated in the requirements by business partners of what they want. In the initial project evaluation, the Business and the PM team have agreed on the BRD but somewhere it lost the business requirements translation. The translation was lost because after the project was kicked there were changes in the PM team, like adding new team members, and the contents from the BRD were not transferred properly to the new replacements. This caused the communication problem between the PM team and the Development team. The development team along with the PM team created the Technical Spec which reflected the BRD but not understanding what business really need. So the end design was a flaw. Business stake holders decided to dismiss the current PM team and development team because of not seeing any progress or deliverables. They decided to put a new team in the process to complete Project X on its last remainder six months period.

At this time, we had a new PM team and the new development team from the different vendors to get the work done in the remaining 6 months. Business partners tried to extend the project more than 6 months but the management did not agree to the proposal. The PM’s along with the Development team started to do the re-design and rework to deliver the project in the remaining 6 months. Unfortunately, there wasn’t enough time to turn the project around from scratch. The team even tried to patch the wrongly designed model. In my opinion, it was a mistake to incorporate the old business requirements and failed to comply with new business requirements.

My main findings for the project’s failures are described below. This is with respect to the Main team (PM and development) which took the initial development of the project in the first 9 months.

  1. Waterfall approach for the project. No verification check points with the Business Stake Holders for approval at each stage of the project.
  2. Design of the data model was done with no proper understanding of the BRD and never got approved from the Business.
  3. Constantly changing Consultants, both PM’s and Developers. This resulted in no proper transfer of knowledge between the PM and developers when they are moved out of the project and replaced by new ones during the project.

Assignment_Bryan_11092010.doc

One Response to “EE 606 – Technical Project Management – BLOG POSTING From Shyam P.Prabhakar”

  1. It sounds that communication was the main problem in this project, so I would say the blame was mainly on the PMs since the task of making sure the requirements are clearly defined and communicated falls on them! 9 months without having some kind of meeting to check the status of the project and making sure it is on target is absurd!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: