Here is an interesting situation we have been put in. We developed a proposal that includes deliverables, work packages and their estimates, risks etc. Also we planned some contingency for risky situations , like API integration may take more time than needed, application may not work on some specific hardware and this will require additional time for fixes, etc.
However customer insists on handling all the risks by their side. This sounds very good for FP project and let us share responsibility about the risks. On the other hand it allows customer to keep the project budget at the minimum level. If we accept the order on these terms, what is the best way to manage these risks?
-
1This question appears to be about pricing, rather than about risk management as it applies to the project management profession. Even if it's on-topic, it is currently written as an opinion poll, and is therefore not suited to the Q&A format.– Todd A. Jacobs ♦Commented Jan 4, 2014 at 16:05
-
Handling risks at their side depends on how capable they are and you should analyze and decide whether to accept this proposal. This is a very big risk unless you have a proper plan to handle scope creeps and handling unexpected risks.– NinethSenseCommented Jan 8, 2014 at 12:20
Add a comment
|
3 Answers
That sounds like a disaster. I think that set up would be a set up for a bunch of finger pointing and blame down the line. If they want to have influence over the costs, do T&M or cost plus. In fact, that's pretty much what this is or will be except without the finger pointing and lawsuits.
answered Jan 2, 2014 at 20:36
-
That is what I'm thinking about as well. Is there any approach how vendor could save themselves ? for example any strict approach about change requests ? or maybe FP but instead of one project couple of smaller ones ?– RuslanCommented Jan 2, 2014 at 21:33
-
3Change request process should ALWAYS be strict, no matter the type of contract. In my opinion, just avoid this set up and simply go with a T&M or CP. That's what they're asking for, really. To be in some control of the costs. Commented Jan 3, 2014 at 2:25
I don't think this is a disaster. We have done various projects on such conditions and it can work. Essential things are:
- Ensure that you are partners in the project (which is generally a good idea when it is a real project) and not competitors.
- Ensure you have explicitly defined what risks are moved over to the customer side as out-of-scope.
- Ensure you have some kind of time restriction: even when you deliver, the customer might not be able to go live due to occurrence of the out-of-scope. Allow the customer a reasonable amount of time to fix it and after that have the project automatically finish even when acceptance criteria are not fully met.
Good luck!
-
1Under the normal construct of a FFP, there are conflicts about what is in scope, activity versus product, what was intended by the SOW language, on and on. In my world, that is standard op procedures. Adding this "promise by the customer to handle the unknowns," I cannot imagine anything but more conflict. Perhaps you have different experiences but I would not touch this. Commented Jan 3, 2014 at 14:05
-
1Yes, it can give reason for conflict. Therefore, want the mood is hostile, better not go into business or without strict agreement, but when working together in some form of partnership this approach allows the air to be taken out of a project. Commented Jan 3, 2014 at 16:14
If the client wants to take all the risks, he must manage them, too. If he is not skilled in risk management for software projects, that would be a problem for you because you can't do it yourself as in a normal project and the success of the project depends on it.
