How do you use Kanban in a Fixed Duration/ Fixed Cost Project?

This is a common dilemma for teams wanting to use Kanban for ‘fixed price, fixed cost” projects.  On the one hand, you have a business demand to commit up-front to a timeline and scope (and cost) to deliver a product; on the other hand, you have a promising tool – Kanban – that completely does away with any concept of time (or scope) bucketing but yet promises higher value and better quality to the customer.

I believe the answer lies in both parties in the project – the customer and the vendor (business and IT or external IT vendor) agreeing to the common problem in fixed time, fixed scope projects – that in most if not all cases, by the time the project is deemed to be complete, neither the originally fixed scope nor the originally fixed time requirement is met.  In most cases, perhaps 70-80% of the overall stated requirements might be met, 10-15% (or higher) may be discarded (changed due to insufficient conceptualization up-front or due to changing business, high cost of the last 5-10% “nice-to-have” requirements, etc.) and the time (and cost) to deliver might overrun by 30-75% or even more.

The scope invariably changes and expands – and the challenge of managing that change, given the original ‘commitment’ made, can be significant, even in organizations and teams with a reasonably well-defined change management process. There is also significant pressure on the customer (business) to “freeze and sign-off” on the requirements – and not change it once frozen.  The vendor (IT) has the challenge of having to make time/ cost commitments up-front – when they have the least amount of information/ knowledge/ understanding of the requirements.

How Kanban could help?

Kanban truly has the potential to help a team successfully overcome these challenges. In a project environment, where both sides agree to use Kanban, the following method can be used to adopt Kanban –

1. A broad, high-level scope and a set of business requirements can be identified at the outset.
2. A regular process can be established to identify the highest priority requirements on a regular basis. The top 5-10 requirements (based on team size) get pushed to the Kanban board for detailed use-cases or user stories development, followed by design, dev, validate columns on the board.
3. As the team works through and delivers these requirements, additional ones get identified and taken up.
4. Depending on the definition of an MVP or MMF, a (production or demo/ staging server) release schedule can be established – say, a release every 5 features or 10 features.
5. When all the requirements have been delivered, the project would be deemed to be completed.
6. Additionally, there may be one or more parallel Swim Lanes on the Kanban board to handle long-lead or ongoing work – such as architecture, performance, stress-testing, etc. – and there might be some dependencies defined between work in these lanes and the main Dev lane.

Shared Commitments and Agreement to Improve

Both sides can start with the following initial commitments:

1. Both sides agree to the high level scope and timeline (based on past experience, best case estimates, etc. – any method agreeable to both sides) with full knowledge that the scope and the timeline might change (as they would even if the project were of the fixed scope/ fixed duration type) and that they are prepared to handle it.
2. The delivery team will work on the most important requirements as defined (and redefined) by the business.
3. The delivery team will be largely able to deliver most of the actual (really needed by business) requirements of the business.
4. Any substantial creep in scope/ duration will be mutually and collaboratively managed.

In return, both sides get the following significant benefits of doing the project in the most transparent, collaborative and productive environment:

• The customer does not need to define and freeze all the requirements up-front. After starting at a high-level scope (of say Themes/ Epics), they can really focus on the most critical ones first and define them in detail.
• At any point in time (up to the last responsible moment), business can redefine the priority of requirements – and make changes to the requirements. Only, once the requirements are on the board and being developed, they should ideally not be changed. Even then, if they need to be changed, they simply move back to the backlog and something else gets taken up, giving business maximum flexibility and the ability to respond to business changes.
• The delivery team (IT or vendor) does not have to give a scope AND time commitment up front. They can instead spend the extra time to focus on understanding the business requirements better, and delivering to those requirements.
• Every release provides the customer an opportunity to make changes, if needed; as well as to better prioritize and define the rest of the requirements. As it happens most often, as users get the software they asked for, they better understand what they truly need – and would like to make those changes. A fixed price/ duration project makes it hard for them to do so. Kanban almost mandates that they work this way!
• Both sides get the satisfaction of delivering a “high-fidelity”, high-value product successfully!

Kanban – Start with Trust or Help Establish Trust

I have seen some very mature and transparent relationships between customer and delivery teams, and ofcourse I have seen many that were neither.  The success of Kanban really starts with both sides coming to the table in an open, transparent, collaborative and win-win approach with a high level of accountability on both sides, all of which generate trust. However, I also believe Kanban has the potential to help “troubled relationships” gain all of that if only both sides agree to pursue improvement in all aspects of the relationship and of course, in their software/ product delivery process!

Here are also some other useful links that you might like to read to better understand how Kanban can be used in fixed date/ fixed scope projects:

• A blog post by David Joyce based on an earlier talk given by David Anderson: (http://leanandkanban.wordpress.com/2009/05/13/fixed-date-fixed-scope-project-enter-kanban/)
• A presentation by our own Sudipta Lahiri dealing with budget and capacity planning for fixed-price projects using Kanban (http://prezi.com/jujwh0ega-pe/adapting-kanban-to-fixed-price-projects/)
• Do you agree with the ideas in this article? Do let me know. If you agree with/ like this article, don’t forget to share it!