Archive for the Contracts Category

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.


Agile Collaboration Schemas

Posted in Contracts with tags on March 19, 2008 by vikramadhiman

Traditionally, Indian IT Services Industry has a tradition of negotiating contracts and these contracts define the nature of association between the organization outsourcing work and the organization taking on work.  However, traditional mechanism of contracts is undergoing a change as at one end the IT Industry has entered the third wave of services characterized by core technical skills, strong project management skills, creativity and innovation and on the other hand competition is increasing. The sellers market is slowly being replaced with buyers market. In addition, whether the organizations are doing “Agile” or not, Agile is also influencing how contracts are structured. Agile contracts are perhaps the most important facet in a service organization looking to go Agile. If the organization can’t have a contractual structure in place, more than likely Agile implementation would fail. However, it takes a bit of learning and unlearning to understand how to write contracts. One of the first things to do could be to call it by a different name. I like to call them “collaboration schemas”. Here are broad differences between contracts and collaboration schemas:

  • Like Agile, collaboration schemas define the broad contours and framework of engagement
  • Like Agile, each collaboration schema instance is unique and different
  • Like Agile, collaboration schemas are to come up using collaboration, feedback and trust
  • Like Agile, collaboration schemas emphasize transparency and minimize capitalizing at others expense
  • The outcomes of the collaboration schema is Keiretsu – closely knit organizational engagement

A major factor to consider moving forward in Agile is trust. Trust is one of those values which you can only earn through your actions. Trust is formed right from the first interaction and continues to be either strengthened, holds on or declines with each further interaction.  These principles help a trust worthy image for the company:

  • Open negotiation of profit margins
  • Transparency on actual costs for development
  • Ability to walk the extra mile and think what’s the best for the customer

Another of the salient features of contracts is the “fixed price”. Everyone dreads “fixed price” in service industry. The customer knows that she would be looking at huge change control budget even after a “fixed price”. The vendor knows that they would more than likely a loosing proposition and yet they would take it up. And on top of this, another common myth< is that you can’t do “fixed price with “Agile“. That’s not entirely true. There are various fixed price options available [and more can be constructed]. Some of these options include target cost collaboration schemas, 1/3rd – 2/3rd collaboration schemas, evolutionary collaboration schemas, fixed price/ fixed date collaboration schemas, maximum cost/ last date collaboration schemas, declining rate collaboration schemas and intellectual property collaboration schemas. Some other options within the framework include less scope collaboration schemas, two stage collaboration schemas, initial requirement freeze phase and fixed quota hours.  

Agile is finding wide spread acceptance and in future there would be more examples and schemas to provide reference for teams looking to try Agile within service environment. However, the above should be a good guidance and relatively risk free bases to start from for most teams. The idea is to understand that the above are just a starting point and the real beauty of Agile should be brought to collaboration schemas as well – visibility, inspection and adaptation.

PS 2000 Contracts for Software Development

Posted in Collaboration, Contracts with tags , on January 14, 2008 by vikramadhiman

The Norwegian Computer Society now offers a complete set of standard contracts for software development and maintenance and management. The standard contracts are now being used in many of the largest public IT projects in Norway. The main feature of the contract for software development is that:

  • It provides mechanisms for establishing a common understanding between customer and the developer and
  • A flexible iterative model for development suited for an environment of uncertainties and risks

The standard contract for iterative development [v2] has these main elements:

  • Increasing efficiency of the procurement and tender processes
  • Based on documented “Best practice”
  • Tools for managing uncertainty
  • Stage by stage, iterative development model securing ability to benefit from increasing understanding of the requirements and challenges
  • Close co-operation between supplier and customer
  • Incentives and sanctions in combination with target pricing
  • Procedures for conflict resolution with an expert as a mediator

The contract consists of three parts:

  1. The Customer and Supplier are defined in the Part I, Contract Document, which also sets forth the order of priority between Part I, Part II and the annexes in Part III.
  2. The General Provisions are stated in Part II. The objective of Part II is to govern the rights and obligations of the parties in relation to the development of the software, including any adaptations, services and associated hardware as specified in separate annexes (Part III) to the Contract.
  3. Part III consists of all the specific annexes.

The difference between a normal contract and this contract is that it outlines terms of engagement clearly. Instead of providing an overall project cost, the team estimates one iteration at a time and each iteration is almost a new project.  Hence, the contract basically takes the incremental approach to estimation as well. Apart from this, the team also outlines the responsibilities, roles and rights of the supplier and vendor for the success of the project, primarily that customer would be responsible for marketing insights and the developer for the technical insights. An expert is pre-selected as an arbitrator in case of dispute. Just the fact that you follow an iterative model for estimation, you improve the efficiency of standard contractual cycle by:

  • It takes assumptions, forecast and psychic part of estimation out
  • Allows for Agile development to emerge automatically
  • Closer cooperation and collaboration needed by default
  • Incentives and sanctions along with target pricing can provide a nice framework for iterative development

I am trying to get my hands on one such contract and lets see if we can analyze this further.

Penalities and Agile/ SCRUM – Part II

Posted in Agile, Contracts, SCRUM on September 8, 2007 by vikramadhiman

In the follow up articles to the original article on Penalities and Agile/ SCRUM, I discuss some clauses that can be added to contracts to make it reasonable for both the sides.

  • The first thing you would want to do is commit to as less as possible – possibly even just a sprint or a release. Hence, if you do incur a penalty, it is not for much. So draft something like “This deadline would be applicable for only Release 1 and deadline for Release 2 would be provided after Release 1.”
  • Approval of all artifacts [including wireframes/ UI and any sprint backlog but not any UML diagrams or architecture] must be done by these dates from the client. To facilitate rapid approval a limit would be kept on the number of revisions for each wireframe and UI. The clients like to add another clause here “If wireframe or UI is rejected, it should not be counted as revision.” This is reasonable as long as the rejections happens in first draft. Any change from xth revision [what so ever you keep] or so – record kept, might be billable at end of project as additional item but not at the end of sprint. Similarly, for any change in approval UI/ Wireframe/ Flow/ Requirement of already delivered/ developed functionality – record kept, might be billable at end of project but not at the end of sprint
  • Offer for co-location: It might be useful to bring on this offer [a central Agile principle] to ask the client to depute someone to sit with the team 8 hours a day, 5 days a week and see if we are doing well enough. This is especially useful for large projects with quick deadline.
  • You can try committing to the deadline as late as possible. This is useful but rarely practical. However, all contracts are negotiation points and you can bring it to at least Sprint 3 or 4 if not second last sprint. You will have better idea of where the project is going in this case.
  • A cap on story points – we will deliver working software by December end as long as total story points for stories remain plus minus 5 percent of 400 story points.

In case anyone has any more ideas, please fire them. We are all ears.

Agile vs. Waterfall – Convincing Clients

Posted in Agile, Contracts with tags , , on September 1, 2007 by vikramadhiman

Dave Barrett, Lawyers’ Professional Indemnity Company provided this delicious recipe on how to convince clients for Agile.

“We can set a deadline if you like. In that case, we’ll spend the first month of the project working up a scope document and bouncing it back and forth between our two companies making revisions and additions until we hate each other. After that we’ll treat the SOW as gospel and fight like hell against any changes. Any additions to the scope will push the deadline back weeks at a time. Since you’re almost certain to add to the scope, this means that you’re doomed to miss the deadline even before you start. You won’t actually see any results until a day or two before the(revised) deadline, at which point you’ll almost certainly be disappointed because certain features won’t work the way you envisioned, or won’t be included because you never told us about them or didn’t know that you’d need them. We’ll then work up a new SOW for phase two of the project and rinse and repeat.”

“On the other hand, we can have short meeting tomorrow, identify the couple of features that seem to be the most important right now. Then we’ll get the Team going on it and show you what it looks like in a couple of weeks.Then you can pick the most important things that need to be done next and we’ll work on them right away. It may or may not be possible to get the system finished by your deadline, but the Team will always be focused on what you’ve determined are the most important aspects of the software all the way through the project. Our experience is that you’ll have working software faster with this process, you’ll waste less time and money building features that you don’t need, the features that you do get will work just the way you want them to and you’ll still like us at the end of the project.”

What do you think the customer will choose?

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 Two

Posted in Collaboration, Contracts, SCRUM on August 20, 2007 by vikramadhiman

We discussed a Traditional Approach to Agile Contracts in the previous post. In this post, we discuss a slightly more Pragmatic Approach, that keeps with the spirit and letter of Agile but you can expect slightly more bickering here. However, its still better than the traditional fixed price approach. So, here is what we have been trying.

  • Estimate like any fixed price project
  • Make a project backlog – as detailed and as accurately as you can at a time
  • Estimate in real time units each item in backlog [no relative units like story points]
  • Allow customers to change stories that team has not started working on from future sprints with same weight stories [weightage estimated by the team]
  • Provide working software at the end of every release
  • Ability to cancel future sprints at a given pre-project cancellation fee

The only real problem that this kind of approach brings is that after the first few sprints, keeping track of what can be taken out and inserted needs a bit more analysis and discussion than a traditional Agile team would like. Another side disadvantage can be to not implement proper SCRUM/ Agile rules [as you are doing fixed price]. Hence, you need to add a fixed time dimension for this which unless estimated carefully can be a double edged sword. The advantage of this approach is that you can readily sell this to the clients and sort of marry Agile with fixed price approach very well. We have started this approach with two recent projects and would like to see how this goes.