Please login or join to subscribe to this thread
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.
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.
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.
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.
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.
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 ?
Please login or join to reply