My first experience of delivering an enterprise level fixed bid project using agile was very successful and a really fun ride for my entire team.  This engagement taught me that by paying close attention to how the terms of the engagement are defined, and by focusing more energy on starting such initiatives on a solid foundation, the regular agile ways of working can be just as successful on fixed bids as they are on “time and material” projects.

1.     INTRODUCTION

As an employee of ThoughtWorks, I lead large (often globally distributed) teams of consultants building application software for our clients using agile, lean and XP methodologies. In the 12+ years I’ve spent at ThoughtWorks, we have always done work on a time and material contract basis.  The popular opinion within my organization has always been that a fixed bid contract goes against the fundamental agile principles of customer collaboration and responding to change.  This lack of ongoing collaboration and the inability to make reactive changes results in clients not getting the optimal software solution, and the development team not realizing the full potential of a self-organizing entity.

Since the financial crisis of 2008, several clients have started approaching us to build software on fixed bid contracts. We’ve generally been dealing with these requests on a case by case basis, and I hadn’t heard of any mission critical piece of work being undertaken under a fixed bid contract by any ThoughtWorks office globally.  As a result, there was really no knowledge base within ThoughtWorks to help with such engagements.

In the spring of 2016, one of our long-term banking clients approached us to deliver an online portal for use by customers and call center agents for their new consumer loan product, as a fixed bid engagement. I was assigned to not only define the terms of this engagement and kick it off, but also to see it all the way through from initial discovery all the way to go-live. Faced with this situation where I could either sink or swim, and with almost no knowledge base to tap into, I used all my past experience to create a new delivery model for my team. Luckily for all of us, it worked!

2.     Background

Our client is a major player in the banking space in the USA and Europe. Facing intense competition in the US credit card market, they were looking to introduce a consumer loan product to expand their footprint in the unsecured credit business.  As a digital-only product, a key success factor for this product was to have a customer portal with great self-service capabilities, supplemented by a simple and intuitive portal for call center agents.

Though ThoughtWorks had been doing work for this client since 2014, the building of the portal for both the customer and call center agents was being handled by the client’s internal development teams.  These teams had missed 4 deadlines and the rollout had been delayed by 2 years.  In early 2016, the client’s leadership team determined that unless the product was release by Oct 2016, they would never be able to win any market share from competitors. Finally, after a lot of internal wrangling, the product leadership approached us in March 2016 and asked for help to launch the product in 7 months.  Working backwards from the desired launch date and setting aside time for production readiness activities, we would have only about 5 months to have develop and handover fully integrated working software.  Given the amount of risk involved, the client’s procurement and technology leadership insisted that this work would have to be done as a fixed bid. The payment terms were very attractive, but failure would not only impact ThoughtWorks’ relationship with the client, but also our reputation in the market.

In this situation, we formed a pursuit team consisting of myself as the Delivery Lead, a Business Analyst, two Developers and the Sales Lead. While the sales lead focused on the commercial aspect, my role was to work with the business analyst and developers to review the feasibility of successfully delivering this piece of work and come up with the delivery plan.

3.     Our Story

It was my first time working on a fixed bid engagement and so was the case for all my team members. I had to fundamentally rethink some of the things I have always assumed in regular time and material engagements. While we were given a lot of freedom in the planning and execution of this project, there was also a high level of accountability and oversight given the sensitive nature of this engagement.  The key focus for me was to come up with an achievable delivery plan for the development team, while providing adequate visibility on progress to the client and ThoughtWorks leadership.

3.1     Problems

We came into this engagement faced with several problems:

• A very tight timeline and lot of scope to cover
• Disillusioned and frustrated product owners whose had lost all trust in the technical team after 2 years of delays
• Pressures from Finance and Legal teams on both sides to “fully define and document” requirements and technical design before signing the Statement of Work
• Unsupportive and distrustful internal development teams at the client side
• No ownership or urgency on the dependencies (other internal teams, third party vendors etc.) due to the multiple delays in core development
• A ton of existing documentation and stakeholders very reluctant to cover these topics again with a new team

3.2     What we did

Starting from the creation of the Statement of Work through the project kickoff, all the way through execution and delivery, we had to pay close attention to how we normally did things, and then tweak them to the unique needs of this engagement.

3.2.1 Insisted that we wouldn’t sign the contract without a formal project inception/kickoff – Given the lack of clarity and ownership on the current state of the project, we requested for a 2-week long project inception.  In the spirit of partnership, we did 1 week of this work on a non-chargeable basis, and another week paid by the client.

Benefits

• By reviewing existing project documentation and asking more specific follow up clarifications to stakeholders, we were able to impress them and gain their trust in a short time
• By reviewing the existing code, we quickly realized that it was really unusable, and provided estimates based on starting the work from scratch
• By understanding the various dependencies and their status, we were able to define deadlines and working relationships with the dependency owners
• By aligning the scattered requirements against user journeys, we are able to identify the ones that were in the critical path for the customer and agent to be able to successfully manage the consumer loan account, thereby significantly reducing the “must have” feature set

3.2.2 Captured what we knew into the Initial Story List (ISL) – Using the existing documentation as a starting point, we worked with the product owners, technical architects and user experience designers to break down the work in stories, capture the technical assumptions, the expected user experience, dependencies and risks.  With this information, we obtained developer and QA estimates.  All this put together formed our Initial Story List (ISL)

Benefits

• The ISL comprehensively captured the common understanding of the project’s deliverables while quantifying the baseline scope
• By using lo-fi wireframes and sketching end to end flows, we were able to gain consensus on some user experience areas that had been going around in circles for months
• By highlighting the most risky and volatile stories, we were able to identify and assign actions required to ensure that the project did not deviate much from the baseline
• By refining the user journeys into stories, we were able to identify re-usable components between the customer and the agent portals
• Once the stories were broken into a sufficiently granular level, it was very easy to visualize and sell the whole concept of multiple project “milestones” and “releases”

Figure 1. Using mockups and lo-fi wireframes to capture the common understanding of the user experience

Figure 2. Evolving the milestone plan during the project inception

3.2.3 Divided the project into frequent milestones based on the user journeys – During definition of the user journeys, we realized that the user journeys grouped with their relevant dependencies could be deployed all the way into Production every 4-6 weeks, for testing and feedback from the Beta testing group.

Benefits

• Payments and penalties were linked to the timely review and sign off of milestones. This kept the pressure on the development team and the product owners to jointly own success of these milestone deliverables
• By promoting code from every accepted milestone all the way to production, the various integration points with other systems, external feeds etc. could be tested and fixed much earlier in the cycle
• Given the client’s cumbersome red tape and manual processes in the path to production, the frequent milestones gave an opportunity to repeat, refine and streamline the release process before the product was actually offered to the public
• By involving all dependencies in every milestone’s deployment to production, we significantly reduced the risk of delivering stand-alone code built against mocks, that would take another project several months to fully integrate

Figure 3. The project deliverable broken down into milestones

3.2.4 Carefully planned our milestones based not only on business priorities, but also on how we could leverage benefits of parallelization of work and reusability of components.

Benefits

Parallelization enabled the team to start work on different sections at the same time early in life of the project.  From the product owners’ perspective, this gave them early visibility into the finished product, and allowed them enough time in the subsequent 3 milestones to get beta testers’ feedback and change some of their original ideas around the look and feel and navigation behavior.

Figure 4. Parallelization of work to deliver more functionality early on

Reusability ensured that we are able to build the foundational components first and reuse them efficiently to layer on additional requirements and changes.  While the first foundational components took longer to build, they reduced subsequent development efforts to a matter of days or even hours.

Figure 5. Example of building out a capability using a foundational component

3.2.5 Linked scope to the available number of points rather than specific functionality – The inception gave us a clear picture of the capabilities needed for customers and call center agents, but there was still a lack of detail on a significant number of requirements.  We therefore decided to link the scope of each milestone to a fixed number of points v/s explicit stories.

Benefits

• By not committing to ill-defined requirements, we were able to tie development effort to the maximizing business value for the client, while reduce the delivery risk to ourselves
• Product owners also received the flexibility and the lead time to spell out complete requirements closer to when they are actually being worked on

Figure 6. SOW with flexibility for change within bounds of available effort

3.2.6 Added a clause to allow exit at the end of each milestone – At the end of the inception, there was still a lack of confidence on both the client and the ThoughtWorks’ side regarding the other party’s abilities to fulfill very demanding expectations set for it. Given this, it made sense to give both parties an opportunity to exit the engagement if either party didn’t feel comfortable with the level of progress made till that point.

Benefits – By giving each party an opportunity to exit the engagement before it was completely done, we were able to:

• Assuage the business stakeholders’ fear that they have to endure another delay in the launch of their product, and know about it too late to take any corrective action
• Reduce the amount of risk that ThoughtWorks would be taking on if the client did not satisfy their commitments in assisting the delivery team with satisfying dependencies and resolving blockers

3.2.7 Incentivizing ideas to finish early – At the end of the inception, we shared the complete milestone plan with the team and asked them to provide ideas to finish the project early and without bugs.  We offered incentives in terms of team outings, a grand end of project celebration, end of milestone recognition rewards etc. to spur the team’s creativity

Benefits

• The week wise visual of the milestone plan helped everyone on the team easily understand the impact of any slippages and encourage proactive actions to ensure we stay on or ahead of schedule
• Some team members defined the list of reusable components and put in a focused effort at the start of the project to get these components ready for the whole team to leverage
• The same reusability was also adopted in the user experience elements allowing us to staff much newer resources on the team and greatly increase productivity and efficiency
• The autonomy helped foster a sense of deep ownership in team members, and led to the delivery being a very enjoyable time for all of us

3.3       Results

The above steps set up the team for great success in the execution and roll out of the customer and agent portals.  Some of the key results we saw were:

• The milestone plan exposed within the first 6 weeks, the complete lack of readiness of the production deployment teams at the client. In the end, ThoughtWorks ended up owning a lot of the deployment process so that the product could actually launch on schedule
• The early progress and responsiveness on feedback is something the Product Owners hadn’t seen from their own teams, and helped build a lot of confidence, trust and goodwill for the ThoughtWorks team
• We not only finished the planned milestone deliverables ahead of schedule, but also managed to bring in several additional nice to have features, greatly delighting the Product Owners
• The project was highly successful commercially, but at the same time, the team also enjoyed the engagement very much

Figure 7. My daughter dismantling our project wall on the last day!

Figure 8. The awesome team!

4.     What We Learned

4.1       Fixed bid contracts are best for engagements that are shorter term (3-6 months) in duration, and linked to a specific business goal

• The longer the project horizon, the harder it is to have complete clarity around the requirements that are further out in the timeline, and greater is the volatility in the project environment
• The sense of urgency, commitment and clarity around a specific business goal with explicit business value is much better articulated than a large “big-bang” piece of work

4.2       All parties involved in the fixed bid should have the same sense of urgency and same level of commitment to the goal of the project

• If only the core team is committed to the success of the project, they rarely get the same timely attention from other dependencies like external vendors, infrastructure, security and other teams on the path to Production
• Calling out explicit commitments from these groups early in the release plan ensures they play a more collaborative role or success

4.3       A well-executed project kickoff/inception can ensure a much smoother journey for the rest of the fixed bid contract

• A well-executed inception sets the right tone for the rest of the project duration, and also helps to frame the contract to be more collaborative and linked to delivery of frequency business value
• Some important outcomes of the inception should be the milestone-based release plan, accountabilities and deliverables of all parties in each milestone and the initial story list
• Define milestone deliverables based on effort and capabilities rather than granular features; this gives both sides an opportunity to be flexible during development in producing the solution of greatest business value
• The inception must also be used to completely define the details for the first month’s planned stories, so that the team can get a jumpstart on delivery

4.4     Fixed bids get exponentially more complex with globally distributed teams

• Communication is a challenge even in regular distributed teams; with fixed bids, the time and cost pressures make the inefficiencies of distance even more evident
• An electronic tool to keep the week wise milestone plan visible and synced up at both ends goes a long way in ensuring common understanding of the project status and urgencies
• Having a small onsite team (business analyst and senior developer) purely for communicating with the client and eliminating blockers helps the offshore team tremendously
• Always ensure that the team doing the work is present and driving the project kickoff and defining the terms of the engagement

4.5     Post inception, rigorously implement a cadence or flow to ensure adherence to the plan

• UX design of the entire milestone should be done prior to the start of the milestone using lo-fi sketching to ensure the team was aware of end to end scenarios being built and the progress to completion
• Story narrative writing and technical analysis should be done at least two weeks ahead to ensure developers had no open questions that would block development
• The product owner should still have the flexibility to use the available effort to implement the best solution for scenarios being built out
• Have regular showcases/demos (weekly at a minimum) to the product owner and stakeholders to ensure early feedback and signoff
• Integration against external integration points should be done on a continuous basis to ensure no surprises at the end

5.     Acknowledgements

I firstly wish to thank my shepherd Mr. Casper Lassenius for his guidance and advice, without whom this report would not have been possible.

I also wish to thank my amazing husband and my entire development team in Pune.  As a father of 10-month old triplets, I had a lot to juggle between work and home during the execution of this program of work. Their understanding and flexibility to try something totally different really helped make this a great success.

I am also very grateful for the innovativeness and sense of ownership of the project team that made these new ways of doing things work so well!