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 <prev
Yes, pretty much. Remember we're not expecting to get paid for everything we do, but we need to know what extra we've done to put a good case together for those payment negotiations. Also, it's really important to record the change otherwise the customer may forget they asked for it, and then if later this change has a big impact on another part of the project, they would expect to get that resolved for free (since they would claim it's our fault for making this 'unrequested' change).
...
1 reply by Rami Kaibni
Jan 10, 2016 6:42 PM
Rami Kaibni
...
I definitely agree with you and specifically for large projects. We should be vigilant in recording every additional thing, get clients approval before we proceed in order for the VO to take place with immediate effect and become part of the budget as well.
Jan 10, 2016 6:40 PM
Replying to m gray
...
Yes, pretty much. Remember we're not expecting to get paid for everything we do, but we need to know what extra we've done to put a good case together for those payment negotiations. Also, it's really important to record the change otherwise the customer may forget they asked for it, and then if later this change has a big impact on another part of the project, they would expect to get that resolved for free (since they would claim it's our fault for making this 'unrequested' change).
I definitely agree with you and specifically for large projects. We should be vigilant in recording every additional thing, get clients approval before we proceed in order for the VO to take place with immediate effect and become part of the budget as well.
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 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
...
1 reply by Kiran Kumar
Jan 11, 2016 1:53 PM
Kiran Kumar
...
Sergio, thankyou for clearly distinguishing between Agile and waterfall. This is also something I have been trying to clarify to few within the organization. I looked through the linkedin link, but would you have some specific paper or links that I can use as a base reference.
Sergio, Thank you for the information. Your comment helps me a lot to understand the topic better.
I fully understand you. No matter we belong to diferent cultures (here in Argentina I have a lot of japanese friends because it is a hugh community) and we belong to diferent countries we can find that some things related to project management (and others) are common to all of us. I was in your situation lot of times. So, I think I understood your point. For me, each project/program manager when is assigned to a new initiative will face the same situation I saw multiple times in one of my favourite series: "Mission: Impossible" : "your mission if you choose to accept" and here we go trying to deal with that.
Jan 10, 2016 6:52 PM
Replying to 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
Sergio, thankyou for clearly distinguishing between Agile and waterfall. This is also something I have been trying to clarify to few within the organization. I looked through the linkedin link, but would you have some specific paper or links that I can use as a base reference.
@Kiran: about project life cycles the topic was matter of exhaustive investingation in the field of software engineering. Then it was applied to other fields. You can find original papers about life cycles into the internet if you search IEEE, Computer Society or SEI CMU. Try to get the original papers (for example Mr Royce paper on waterfall) but most important try to really understand it and see how to apply it to any type of your initiatives (innovation, another buzz word - hehehehehhe). Regarding agile, search for Rick DoveĀ“s book "Response Ability", Toyota papers inside Toyota site and the MIT, and if you work in software please read and must important understand the manifeesto for agile software development.
Now here's a question you might consider - what happens in an Agile environment (to the change control process) where the deliverables may change though out the life of the project to maximise the customers business advantage? How do you develop a budget for a project that will be delivered using Agile?
In agile software development environments change control process is the same thatn in other type of environments. The deliverables could change but the decision is on customer side about all related to change. About the budget there are diferent ways to create one most of then depending on the life cycle you will use (like cycle is not the same thatn approach).
Page: 1 2 <prev  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"That rainbow song's no good. Take it out."

- MGM Executive Memo after first showing of The Wizard of Oz