How can you succeed with fixed-price agile contracts?

Back when I worked with fixed-price contracts, the questions we were trying to answer were: Given the price is fixed, how might we maximise the value that is delivered? AND is it enough to warrant the investment? Depending on the size of the investment, this assessment itself might be its own engagement (e.g., Agile Inception)

The most important thing in a project with a fixed cost contract is to work exhaustively on defining the problem domain, generating scope agreements with a macro view of deliverables. After this, of course, establish a metric to measure the effort and transform this effort into financial value.

To succeed with fixed-price agile contracts, it is crucial to prioritize understanding the customer's needs and goals. This can be achieved through a comprehensive discovery phase, which involves asking open-ended questions, actively listening, and validating assumptions. By establishing a clear vision and value proposition for the project, as well as agreeing on key success criteria and metrics, you can effectively define the scope and prioritize features that provide the highest value to both the customer and the end-users. This customer-centric approach ensures that the project aligns with the customer's objectives, leading to a successful outcome within the fixed-price agile contract framework.

As a buyer I prefer fixed price flexible scope. We'll have fixed capabilities. Detailed scope and requirements (e.g. field level acceptance criteria) not only have never been necessary to meet the defined capabilities, but focusing on them in contract stage creates unhelpful conflict. Frankly we lose confidence in vendors when they push them into contracts. It's a strong encouragement to build internal skills so we can drop them earlier.

analysis. how to understand the customer's needs? again, analysis. If this face does not catch full requirement then, something will go wrong. remembering old school, analysis was around 50% of the success so, missing the understanding then, something will be wrong. What was that "triangle"? money, resource, and time? - also recalling to level the concepts because one side can understand something different that the other side.

The scope refers to the defined boundaries and objectives of the project. It outlines what will be included and excluded in the project deliverables. The scope should align with both the customer's needs and the capabilities of the organization providing the service. The contract, on the other hand, is a legal agreement that sets out the terms and conditions for the project. It helps to manage expectations, define responsibilities, and provide a framework for collaboration between the customer and the service provider.

Generally fixed price implies fixed time given the costs for software development are mostly labour. Definitely agree with being clear about expectations around ways of working, especially how conflict will be resolved, changes will be handled, etc. Learned the importance of this the hard way.

When it comes to product management, defining essential skills and technologies for consistent, high-quality deliveries is paramount. Two effective strategies I've used: 1) Scope-based contracts detailing necessary skills and technologies, with billing directly tied to service delivery. 2) Fixed payment per successful Sprint, fostering partner commitment. Billing hinges on sprint delivery and Product Owner or business area approval (Scrum framework). Note that we don't specify developers or personel numbers but emphasize defining service scope and contracted technologies. For specific projects, we engage vendors based on project-defined scopes.

It is crucial to avoid rigid fixed-scope contracts that hinder adaptability to changing requirements and feedback. Instead, I recommend opting for fixed-budget contracts that establish a predetermined price and time frame, while allowing for some flexibility in the scope, as long as it aligns with the value proposition and success criteria. To support Agile principles effectively, I suggest utilizing an Agile Fixed Price Contract (AFPC). This contract outlines the roles, responsibilities, processes, and deliverables of both parties in an agile manner, fostering collaboration and enabling the team to respond to evolving needs throughout the project.

- Ensure the project scope is well-defined and documented. The more clarity you have upfront, the better you can estimate costs and timelines. - Collaborate closely with the client to understand their requirements and expectations. Use techniques like user stories and acceptance criteria to define scope.

Test the assumption that fixed price = fixed scope. It might not. Fixing the price is one way to give a buyer certainty and manage risk, especially when there’s ambiguity in development. If you can be confident about what needs to be done, then include it in the contract and deliver accordingly. If you can’t, say you’re doing particularly novel work, then you have the option to mitigate some risk by ring-fencing your budget and fixing the price of the contract. “We don’t know what’s going to happen but we’re prepared to bet this much money to find out.” You can argue that agility starts and stops with contracting, as contracts define what you can and can’t do. Use them flexibly!

What's missing here is planning "releases", that is, incremental, integrated value/features which tend to be larger than what's typical for a single user story. The idea is not just to show incremental progress on a chart but to show incremental progress by delivering incremental value.

To plan and execute a project in iterations using agile methodologies, follow these steps: 1. Break down the project scope: Identify the key features and functionalities required for the project and create a backlog of user stories. 2. Prioritize user stories: Evaluate the value, urgency, and dependencies of each user story. 3. Estimate effort and complexity: Assess the effort and complexity of each user story. 4. Plan and deliver in iterations. 5. Collaborate with the customer and users: Involve the project's stakeholders. 6. Monitor and control progress, quality, and budget: Use tools like burndown charts, velocity charts. 7. Iterate and adapt: At the end of each iteration, conduct a review and retrospective with the team.

- Break the project into smaller, manageable iterations (sprints) with specific goals and deliverables. This allows for incremental development and regular client feedback. - Estimate the effort for each iteration but be prepared to adjust estimates as the project progresses.

Overall, effective communication and collaboration with the customer and stakeholders are crucial throughout the project. This involves establishing a regular and transparent communication channel to share project updates, risks, issues, and feedback. Additionally, being adaptable to the customer's needs and expectations is essential, as long as they align with the value proposition and success criteria. If any changes arise that affect the project's scope, budget, or timeline, it is necessary to negotiate and agree upon these changes with the customer. Documenting these changes in a change log or change request is also crucial for maintaining transparency and ensuring everyone is on the same page.

- Foster a collaborative atmosphere with the client. If issues arise, work together to find solutions that maintain the project's success within the fixed price.

During the final step of the project, the focus is on delivering the completed work to the customer and evaluating its success. Delivery: The work should be delivered in increments, allowing for regular releases of features that have been thoroughly tested. Evaluation: The project's performance, quality, and value need to be assessed using predefined metrics. Feedback and Lessons Learned: Gathering feedback from the customer and users is crucial for understanding their satisfaction levels and gaining insights into what worked well and what could be improved. Continuous Improvement: The feedback and lessons learned from the project should be utilized to improve processes, skills, and relationships for future projects.

- Work with the client to prioritize project features and deliverables based on their business value. Focus on what's most important for the client's success. - Use techniques like MoSCoW (Must-haves, Should-haves, Could-haves, Won't-haves) to categorize requirements.

There is something called the iron triangle which is made up of scope, cost, time. It is commonly said that you get to pick two. I’ve always found this inaccurate. There is a fourth thing, quality. Lots of folks think fixed cost contracts, even comments here, should also fix scope and time. Here’s the problem- you fix this and the thing that will give is quality. If you fix the cost you are also, in some respects fixing time because time relates closely to cost. Therefore, unless you want to deliver lower quality, your only remaining choice to to create flexibility as to scope.