Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Change Management, Estimating, Risk Management, Scope Management
Lesson learned from troubled projects
I've been working as a project manager in small and large projects for many years.

I have run into a lot of troubled projects. Sometimes, I play firefighter.
I have come to think that the troubled projects have common characteristics.

Most of large mission-critical systems are still adopting the development style of "waterfall". There, I can find various causes of failure as follows.
Weakness of the scope of control, estimation errors, aggressive orders from sales people, uncertain customer demand, overconfidence to the technical strength, red tapes of internal organization, and so on.

I'd like to know the experience of the cases and share any tips or lessons learned.
Sort By:
Page: 1 2 next>
Here comes. First, the lack of understanding about some critical terms like product scope, project scope, life cycle, method and how each one is defined from the other. Second, the lack of understanding what project sucess criteria is and how it must be defined and meassure. That is because you find projects that have been considered fail and that is not correct because the project sucess criteria are not correctly defined. Thrid, the lack of process to select the project life cycle. Select the project life cycle is an attribute of the project team. But people do not understand that to select it an enterprise analysis activity (using the business analysis jargon) must be done. Fourth, each project is a business project, not an IT project or a software project, etc, etc so all decisions rest on business people. Change management process is a must in this case. All change are welcome but the decision about to proceed and to assume the impacts are a matter of the business people. All the items you have mentioned happends because the items I have written here.
I have ran into many issues in projects which obviously became lessons learned: (I am talking from Construction Point of View)

- As you mentioned, the common one was poor estimation.
- Value engineering options to be considered.
- Logistics Issues
- Poor monitoring and controlling
- Over Allocation of Resources
Sergio, Rami, thank you for your response.
I found it very useful.

As for estimates, I feel something unique about an Japanese IT contract.
Japanese companies prefer to fix pricing up front for the entire project.
It might be useful for business to know the impact of their budget.
But in reality, it's not necesarily easy to fix the user requirement in the early stages of the project.
...
1 reply by Rami Kaibni
Jan 10, 2016 3:45 PM
Rami Kaibni
...
Hi Kenji,

You are welcome. Doing a fixed price contract with move the risk to the seller, this might be the main reason why they do that but I agree with you, it is not easy to finalize the requirements from the beginning but it all also depends on what type of fixed contract they use is it:

Firm Fixed Price
Fixed Price Incentive Fee
Fixed Price with Economic Price Adjustment

Also Contingency and Management reserves might play a small roles here to account for underestimates from buyer side.
I would classify such projects into three categories: troubled projects, sick projects and failed projects. Troubled projects are those who have run into problems but can be fixed by controlling various factors mentioned by Rami and Sergio. In short troubled projects can be fixed by following good project management practices. Sick projects are more intricate in nature, they have so far not failed but they are destined for failure and fixing them would entail complete re-planning after thorough analysis and re-evaluation. These projects may be rescued with highly intelligent and creative trouble-shooting but may also hit the rock bottom by becoming failed projects. Failed projects are those projects which have not fulfilled the success criteria and have finally been declared as unsuccessful. They cannot be fixed but if the benefits expected from project needs still to be realized, we will have to come up with a business case for a completely new project. It is point of no return, but strategy may find a way to deal with them.
The same thing about fixed pricing is in the other side of the world (depending if you go to the right or to the left, hehehhe): Latin America. Companies tried to fix the price but not fixing the requirements. That is because they try to fix the price. Selling a project is an art, no matter you are trying to sell the project to an external client or an internal client. Change management process must be agreed and both sides responsabilities must be agreed in advance. That could help in fixed price projects. It is a matter of culture and market demands. When I interacted with japanese companies I found that becouse a culture regarding quality they understand that we are business partners and if we fail then they fail. But you are there so my experience is not enough to help you.
Jan 09, 2016 9:07 PM
Replying to Ken Yoda
...
Sergio, Rami, thank you for your response.
I found it very useful.

As for estimates, I feel something unique about an Japanese IT contract.
Japanese companies prefer to fix pricing up front for the entire project.
It might be useful for business to know the impact of their budget.
But in reality, it's not necesarily easy to fix the user requirement in the early stages of the project.
Hi Kenji,

You are welcome. Doing a fixed price contract with move the risk to the seller, this might be the main reason why they do that but I agree with you, it is not easy to finalize the requirements from the beginning but it all also depends on what type of fixed contract they use is it:

Firm Fixed Price
Fixed Price Incentive Fee
Fixed Price with Economic Price Adjustment

Also Contingency and Management reserves might play a small roles here to account for underestimates from buyer side.
...
1 reply by m gray
Jan 10, 2016 6:24 PM
m gray
...
Hi Rami
the discussion has moved into fixed price contracts, so I thought I'd add my experience of these.
I have never encountered a fixed price project that is anything other than firm fixed price. The other types are maybe found in industries I haven't worked in. What we do then, depending on some degree to the estimated profit the fixed price is expected to yield, is charge the customer extra for these changes (the PM decides what to charge for, balancing good customer relations with commercial reality). Generally, if the project was priced very low to win (very low contingency), then every change is charged for, if not, then only the more significant changes are charged. Since invariably the customer doesn't want to pay for any of these extra costs, this generally leads to a senior management meeting to discuss. As the PM, our view is that we had to do the changes to keep the customer happy and we expect to get paid them, but if we only get half then that's better than nothing, so long as we make a decent profit and the customer is happy - we'd like repeat business.
Suhail, thank you for your article. I also know lots of "Sick projects" seemingly safe but actually dangerous.
Sergio, "Selling a project is an art". I totally agree with you. Sometimes I feel like taking hybrid approach of waterfall and agile, if it might be called "anti pattern". But I don't know how.
Rami, You've hit the nail on the head, and that is what I'm trying to do right now.
...
2 replies by Rami Kaibni and Sergio Luis Conte
Jan 10, 2016 6:02 PM
Rami Kaibni
...
Kenji, Great - I am glad I was able to assist.
Jan 10, 2016 6:52 PM
Sergio Luis Conte
...
Kenji San, you have touch a burning point. Take a look to this: https://www.linkedin.com/grp/post/37631-6087392516750008323
if you want. I spend lot of time writting in debates and performing conferences around the world in order to help people to understand what agile really is. Waterfall is a life cycle. Agile is an approach. Both things can not be compared. And you can apply agile principles using waterfall life cycle (you can take a look to SAP SE life cycles beyond I am applying that from more than 20 years). Agile is not software or IT and it is not a method or methodology. Agile principles born in Ford Motors Company (1917) and Toyota Motors (1934). Obviously, at this time that was not the name. The name born in 1990 in USA DoD NSF/Agility Forum. But you can find the same problems you stated no matter the life cycle you will use. But in case of using agile software development the worst is people do not understand what agile really is. They say (talking about software development)things like "agile is no planning", "agile is deliver faster", "agile is not documentation", "thanks agile we can change everything no matter time we do that" and others. All of this is not true. And because people thinks that they start using agile development methods and they fail
Jan 10, 2016 6:00 PM
Replying to Ken Yoda
...
Suhail, thank you for your article. I also know lots of "Sick projects" seemingly safe but actually dangerous.
Sergio, "Selling a project is an art". I totally agree with you. Sometimes I feel like taking hybrid approach of waterfall and agile, if it might be called "anti pattern". But I don't know how.
Rami, You've hit the nail on the head, and that is what I'm trying to do right now.
Kenji, Great - I am glad I was able to assist.
Jan 10, 2016 3:45 PM
Replying to Rami Kaibni
...
Hi Kenji,

You are welcome. Doing a fixed price contract with move the risk to the seller, this might be the main reason why they do that but I agree with you, it is not easy to finalize the requirements from the beginning but it all also depends on what type of fixed contract they use is it:

Firm Fixed Price
Fixed Price Incentive Fee
Fixed Price with Economic Price Adjustment

Also Contingency and Management reserves might play a small roles here to account for underestimates from buyer side.
Hi Rami
the discussion has moved into fixed price contracts, so I thought I'd add my experience of these.
I have never encountered a fixed price project that is anything other than firm fixed price. The other types are maybe found in industries I haven't worked in. What we do then, depending on some degree to the estimated profit the fixed price is expected to yield, is charge the customer extra for these changes (the PM decides what to charge for, balancing good customer relations with commercial reality). Generally, if the project was priced very low to win (very low contingency), then every change is charged for, if not, then only the more significant changes are charged. Since invariably the customer doesn't want to pay for any of these extra costs, this generally leads to a senior management meeting to discuss. As the PM, our view is that we had to do the changes to keep the customer happy and we expect to get paid them, but if we only get half then that's better than nothing, so long as we make a decent profit and the customer is happy - we'd like repeat business.
...
1 reply by Rami Kaibni
Jan 10, 2016 6:27 PM
Rami Kaibni
...
Michael, Great Input. I as well rarely encountered contracts other the FFP when it is a Fixed Price Contract.

I just want to make sure I got that right. You meant by "every change is charged for", as a seller, you submit a variation order for every change required and get paid for it. Is my understanding correct ?
Jan 10, 2016 6:24 PM
Replying to m gray
...
Hi Rami
the discussion has moved into fixed price contracts, so I thought I'd add my experience of these.
I have never encountered a fixed price project that is anything other than firm fixed price. The other types are maybe found in industries I haven't worked in. What we do then, depending on some degree to the estimated profit the fixed price is expected to yield, is charge the customer extra for these changes (the PM decides what to charge for, balancing good customer relations with commercial reality). Generally, if the project was priced very low to win (very low contingency), then every change is charged for, if not, then only the more significant changes are charged. Since invariably the customer doesn't want to pay for any of these extra costs, this generally leads to a senior management meeting to discuss. As the PM, our view is that we had to do the changes to keep the customer happy and we expect to get paid them, but if we only get half then that's better than nothing, so long as we make a decent profit and the customer is happy - we'd like repeat business.
Michael, Great Input. I as well rarely encountered contracts other the FFP when it is a Fixed Price Contract.

I just want to make sure I got that right. You meant by "every change is charged for", as a seller, you submit a variation order for every change required and get paid for it. Is my understanding correct ?
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"More than any time in history mankind faces a crossroads. One path leads to despair and utter hopelessness, the other to total extinction. Let us pray that we have the wisdom to choose correctly."

- Woody Allen