What are the downsides of Fixed Price with Fixed Capacity projects and how to overcome them?
Prolay ChaudhuryPractice Lead & Lead Solution Architect| Chaudhury, Inc.Bangalore, Karnataka, India
In the classic scenario of Fixed price with the Fixed Capacity Agile project (i.e. The initial requirements/user stories may change, and the development team is responsible for incorporating the changes in the user stories, but the project is going to over on a particular date. If some user stories/requirements are missing from the end product, the implementation partner is not going to be responsible for it)
In the above-said scenario what are the risks of the implementation partner and how do they mitigate those risks?
The following are the issues of the implementation partner -
1. The User Stories/ Requirements are ambiguous, and stakeholders are providing contradictory explanations of the same.
2. The client may not accept the release and ask for further changes that are going to hamper the project schedule.
3. Due to frequent changes during UAT the stability of the product may jeopardize and further delay the next release.
4. Due to the delay in client acceptance for a particular release, the project profitability is decreasing.
How do we mitigate all these issues to make the project profitable? Saving Changes...
Sort By:
Daryl McCrackenDirector of E-commerce| Cornerstone Building BrandsHouston, Tx, United States
Several years ago we were chartered to develop a workflow system to streamline and automate the quality assessment process for data our business generates for our customers.
The organization had already pre-determined we would be using an existing 3rd party software development firm and operating under a fixed time, fixed cost contract. This had proven helpful in limiting scope creep.
As you rightly point out, the risk in doing this is lack of client acceptance of the end system. Prior to engaging with this firm we launched an internal effort - a mini project if you will - to ensure we had clearly defined the requirements and scope of the project. We used 3 methods to ensure success.
1. Identify all stakeholders, not just the ones who were sponsoring the project but all the way down to the actual end users who would be using the system to do their job on a day-to-day basis.
2. Secondly, we conducted both a group requirements gathering session and iterative one-on-one interviews with the stakeholders. What we found was that the group session gathered lots of ideas, many were conflicting an some impossible to achieve. By working one on one, stakeholders felt we were really listening and interested in their thoughts and ideas. As we continued these we would revisit each stakeholder to update them on the process and ask more questions.
While this was time consuming, it resulted in a clearer set of requirement that the stakeholders accepted as their own.
Our third step was to divide these requirements into those that we could deliver in the specified timeframe. We also avoided any requirements that had a high degree of uncertainty or risk. We were able to propose an iterative approach with the core functions to be delivered in this first project (phase 1) and the remaining features to be implemented after launch and a ''shakedown'' phase with real users making use of the system in real world conditions.
Given that the organization typically needed 12 months or longer to implement projects, we communicated that this effort would be completed in months rather than years due to the condensed scope.
The end result was a successful project and system which gave us the support to implement not just one additional set of enhancements, but 5 new releases over the next 4 years. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
If you are given a fixed amount of money, you should only be able to produce a fixed amount of work. Any change in scope has to be a give and take. If the customer wants to add or change a feature, the additional work it requires should be offset by an equal reduction of work somewhere else.
You mention agile methodology. If you are in fact doing so, then you should have all the necessary stakeholders working along the project team to clear up requirements, test and make decisions along the way. At the end of the iteration, there should be no debate that the release is what the client worked towards.
If someone is trying to make changes, you go back to the give and take. Add something but remove something else. Saving Changes...
Daryl McCrackenDirector of E-commerce| Cornerstone Building BrandsHouston, Tx, United States
Stephane. I could not agree more. Actually its a lot like life and relationships. There must always be a give and take (and change is the one constant). Saving Changes...
Prolay ChaudhuryPractice Lead & Lead Solution Architect| Chaudhury, Inc.Bangalore, Karnataka, India
Thank you, Daryl for sharing your valuable experience. You did the ground work very correctly by rigorous interviews with stakeholders and end users before starting the project and eliminated ambiguous requirements to avoid the scope creep.
In our case, we also did the face to face followed by Webex requirement gathering workshops and sessions. But the main issue was the baseline project duration estimation which was done by the client during the bid process. And we were unable to change that from the profitability perspective (Ask the client to pay extra money) but to finish the project the schedule got automatically extended.
Thank you, Stephane for your valuable feedback. But we could not negotiate much apart from few change requests which got approved by the Project Steering Group. Saving Changes...
MAEN QADDOURAHProject Director| AJ SAUDIJeddah, Saudi Arabia
Agree with Daryl Saving Changes...
Yulia YeAn expert in mobile and web development| CleveroadDnipropetrovsk, Ukraine
Fixed contract definition It is a model where a client pays a predetermined amount of money, which he has discussed and agreed to pay for a particular scope of work to a vendor. You can understand what is Fixed Price project if you read between the lines. A client and a vendor set not only the fixed sum but also a date (deadline), which cannot be changed even if a vendor faces lots of issues, bugs and technical crashes. (according Cleveroad) So, all risks are handled by the vendor. You might have thought that its a fantastic way to run your business, you pay and don't worry about anything. However, it's not quite that easy. This model also implies that a client wont change the scope of work. In reality, of course, changes can be added to the scope, however, they will be discussed in another contract, with another deadline and billing.
Saving Changes...
Deepesh RammoorthyICT Project Manager ( PMP®AgilePM®Certified ScrumMaster® (CSM®))| Australian Red Cross Blood ServiceTarneit, Vic, Australia
PMBOK says a fixed price contract will provide the most value to the buyer when the scope is clear. If the ground work was done on clarifying the scope and the scope was base lined prior to signing the fixed price contract with the implementation partner or agreeing with the cost and resources, any change to the baseline scope will affect the triple constraints and therefore would need formal approval from the Change Control Board.
If the Contingency reserve can fulfill the schedule or cost blowouts, the Project manager can use it . However the PM needs to maintain a very strict eye over the scope creep. Always deliver to what is in an agreed, signed off scope. Saving Changes...
Deepesh RammoorthyICT Project Manager ( PMP®AgilePM®Certified ScrumMaster® (CSM®))| Australian Red Cross Blood ServiceTarneit, Vic, Australia
I believe this project has a Business Analyst? they should be responsible for making sure that the user stories are unambiguous in the product backlog.
Are the developers aware of all the user stories to be developed in a particular sprint? Does the team lead know in detail the deliverable for the sprint?
Could you highlight the unclear scope as an issue to your sponsor and request that the scope be clarified and signed off prior to continuing work on the project? Saving Changes...
