Archive for Contracts

Scrum and Agile in a Fixed Price Project Environment

Posted in Agile, Business Value, Contracts with tags , , , , , , on January 16, 2009 by vikramadhiman

A lot of people have been writing that they like what they read and hear about Agile and Scrum. They then give presentations to their senior management about Agile and they seem to like what they read and hear too. However, the biggest stumbling block is fixed-cost environment. This is primarily true for almost all services companies [and these outnumber new product development companies by a margin – my guess]. An amount of funding is bid for at the start of a project. The problem is how to come to a number for these bids.

Here are a couple of approaches to tackle this [which work for me]:

Approach One : Try using Scrum as a management tool without changing your current bidding structure. Once the team has experience with Scrum, then you should have some metrics collected. The team(s) should have an idea about their velocity and more people involved at bidding stage [think of planning for a fixed-cost project as any other Scrum planning session], the team should be able to give a good estimate for the first 2-3 sprints, even for the full
project if that is what’s required. More importantly, they will ask the Product Owner/ Manager/ Client very pertinent and relevant question about priority and testing to evaluate the story. The fixed costs are based on the knowledge you have at time of planning, so you can post these on the contract too. As time goes by, and your sprints commence, the requirements will change and so will your estimates. You can negotiate them using the existing negotiation framework. However, at the end of your budget [fixed price], the product should have these functions implemented that she wanted the most.

Approach Two : Try bidding low, not in price but what are you able to give to the customer as well as be aggressive on the date when you can launch the product. Most customers and product owners/ managers would give their right leg for the same. Try it on a low risk project/ low risk client [one where you have an option of trying]. If you are bidding low, chances of getting the bid right are higher [again that’s just my guess]

You may also like to read Myths about Agile Software Development and Scrum, Agile Collaboration Schemas, Agile Contracts, Contracts in Agile, Business View, Learning and Evolution and Agile Estimating.


Discouraging Waterfall contracts

Posted in Agile, Contracts with tags , , on August 27, 2007 by vikramadhiman

I know thats a rather sadistic title for a post but I could not help write the same. For the purpose of this post, I consider Waterfall as “fixed scope” project more than a reasonable length [4 person man months and over should quality I guess]. Here are some things you can try [some have worked like magic for me]:

  1. As bad as it sounds, add even more ceremony to your waterfall contracts. Add initial requirement list sign off, each requirement gathering iteration sign off, method of estimation sign off and what not. Try to get sign off on exact process, SLA, bug count, delivery dates, feedback latency and all the abstruse things any one can think of. If that does not help, announce that after subjecting the poor client to 1 month of requirement gathering and contract revision, you plan to spend another 3 months discussing the project itself. The above time zones [1 month, 3 months] are relative for say a 6 month project. If that also would not work, try adding clauses that favour development unit more than the client – “All UAT must be done within 2 weeks of getting the build and the like.” Add costs for any allowance the client requests. You will either loose the business or get an opportunity to push fixed cost/ fixed time but variable scope projects. If you can just send an email newsletter singing paeons of Agile just at right moment to get the clients in right mood to talk.
  2. Disguise Agile Completely. Here is one approach:
    • We understand initial requirement define a fuzzy viewpoint on the horizon. Hence, we allow our customers to add requirements at any stage and delete/ edit/ replace items from the requirement list as long as it is of the same size, size determined by us.
    • We would provide you working software every iteration [basically 2 weeks/ 2 months] free of cost/ at additional charge of XX USD per iteration.
    • You can cancel the project at any stage for a free of XX USD in case your business interests are met earlier due to working on prioritized business requirements
    • We welcome client feedback and this would be managed as per attached Annexure [Annexure is more glorious description of SCRUM/ Agile].
  3. If the above slightly cheeky ideas don’t work for you, you can simply do case studies of projects done using Agile [also do customer satisfaction studies] and show how going Agile is good for business [faster time to market, lower cost of ownership, flexibility to respond to business changes] etc.

Agile Contracts – Approach One

Posted in Collaboration, Contracts with tags , on August 13, 2007 by vikramadhiman

A lot of people responded back on the SCRUM Development Group to the discussion on Penalities and SCRUM. After having discussed this topic over the last two months, I personally feel [and thats with that big “I” again], the discussion on Penalities and Agile/ SCRUM is probably a subset of the overall domain which can be called “Agile Contracts“, which you can construct in different ways. Here is one approach which we have tried to follow. As the projects are currently on, its a bit too early to get to the efficacy of the approach. However, there are some early trends which are provided without bias below.

I call this approach “Traditional Approach“. This is in keeping with the letter as well as spirit of Agile. It assumes:

  • Evolving requirements
  • No upfront estimation [in hours] – ok I made this one up, its not really an Agile value, but well we like it
  • Transparency and effective reporting
  • Client Collaboration

The Contract is noticable because there is hardly anything there. Its a bit like the old “Times and Materials Contract” with focus on:

  • Project Reporting – backlogs, burndown charts
  • Communication Means
  • Service Levels
  • Types of services covered [designs/ HTML/ dot.Net coding/ QC]

The contract continues for a year at a fixed hourly rate. After a year, you can negotiate a higher hourly rate especially if you score consistently on service levels.

The problem really is that despite its simplicity, it is difficult to sell this to the clients, especially new clients. It can however work in the following situations:

  • Existing client, fed up with fixed price approach but generally happy with service
  • Existing time and materials client
  • Prototypes/ proof of concept projects
  • You can use your internal knowledge management system to demonstrate expertise in particular area

We have had great success with this contract [this was not the only thing but contributed significantly to relieving pressure on team and clint] with a client of ours [the client whom I explained SCRUM and posted transcript here]. The team has consistently exceeded client expectations. One of the reasons they attribute this to is “willingness to not haggle on what is covered and what not in contract” and just think of one sprint/ release at a time. The customer is very happy and we have not heard about the project for a while now and that means it is going really well. The approach has a great advantage for all parties. If you can find any disadvantage [other than difficulty in selling the approach], please do leave a comment.

Penalities and SCRUM/ Agile

Posted in Agile, Contracts with tags , , on August 6, 2007 by vikramadhiman

We have converted quite a lot of our projects and teams to Agile which is great. The teams are happier and delivering value to customers. However, one area where we have a problem is with new customers.

New customers appreciate and value the flexibility Agile offers but would like to stick to a deadline [October 15 or December 15]. We always advise and agree them that this is a central part of Agile – aiming for delivering maximum functionality by given deadline. However, what is a problem is that they take the release date as being a bit too literal. They would even like a penalty for not completing the project by given date. And these are pretty knowledgeable clients who are pretty reasonable otherwise. We try and reason that with ability to prioritize, shelve and add features that Agile offers, this kind of clause is not possible. However, it does not cut much ice with them.

We have tried to convince management to add a bonus clause [if we meet target we would bill at higher rate and client will finance holiday for whole team]. Surprisingly the clients agree to this and the ball is back in our court. Further, the teams internally do not want to go in projects even with lure of bonus and no amount of convincing helps them. They say they can commit to the deadline only if all UML and prototype diagramming has been completed and signed off. This gives us ideas and scares of waterfall ghosts.

As always, its an interesting problem to have and something we need to plan out on how we would approach.