This is a reader guest post by Seth Schubert. Seth is the lead .NET Software Engineer for Appareo Systems and a Fargo .NET User Group presenter.
After attending some sessions about Scrum at Game Developers Conference by Mike Cohn of Mountain Goat Software, I was really impressed by the down-to-earth approach – the basic principles of Scrum actually fall under social engineering (which is often poorly addressed by a surprisingly large number of development shops).
Now [post-conference] I have many successful projects that fall under the category of product development; however, the tough sell has been in the consulting business. It is very difficult to arrange a contractual agreement that accommodates change. At the end of the day, your client’s accounting department is going to want to know how much the project will cost, and when they can expect to receive working software.
A few weeks back , “The Broken Iron Triangle is Broken” revisited Martin Fowler’s age-old iron triangle. Assuming that for consulting, reality is closer to the iron line, a client will tend to perceive a fixed bid contract as less risky. By controlling the scope and budget in a project, the client’s stake in the project are seemingly protected. The risk of project failure by defining scope to early is not altogether intuitive or obvious. Even when presented with this information, a new client may still may be unwilling to enter into an open ended contract. In most cases, neither the client nor the development team will start from a position where they are able to completely articulate the problem to solve, hence neither party is in a position to fix the cost, scope, or effort of a project. This is precisely the point where a contractual agreement is often made.
I’ve found that the initial relationship between a development firm and a client is usually where the friction over this type of contract occurs. Once a level of trust is obtained, that is, once the client can be reasonably assured that your development team will adequately solve their problem for a reasonable cost, many clients will relax the fixed bid contracts for development work. So how do you start the relationship? How should you go about building that level of trust? Entering into an agreement that puts the client’s project at risk (even if the agreement was their idea) does not seem like a good way to build a trusting relationship.
While researching possible solutions, I came across white paper authored by Bruce Eckfeldt and Rex Madden, titled Selling Agile : Target Cost Contracts. The paper describes experiences of applying target-cost contracts in real-world scenarios. To paraphrase the ideas in the paper, the goal is to setup a contract whereby both parties have “skin in the game”. The intention is to start the relationship off closer to that of business partners versus a client-vendor relationship.
The first model covered in the paper was actually a target-scope model. Under this agreement, the price for the project was fixed, but the features themselves were negotiable according to rules agreed to in the contract. The features were broken down, and time was tracked on each feature. Whenever the development team took longer than anticipated, the client removed scope. Conversely, when the development team finished a feature early, scope was added. In order to add incentive, effort added or removed was discounted by 50%. For example, if the development team finished 2 days early, only 1 day of extra scope was added. On the other hand, if the team finished 2 days late, the client only removed 1 day of scope. The contract actually specified the rules by which scope was added or removed.
The second model covered is the target-cost model. Under this system, two contracts are used. The Master Service Agreement (MSA) is used to for non-project specific details such as defining confidential information, non-disclosure agreements, non-compete agreements and so forth. The letter of agreement (LOA) is used to specify project details. The LOA was actually used to start working on the project while the MSA was negotiated.
Under this model, scope is broken down into effort and multiplied by an agreed upon rate, plus a fixed percentage of profit. For example, if the agreed upon rate is $1000 a day, and the project is estimated to take 50 days, a total with 20% profit would be $50,000 + $10,000 profit for a total of $60,000.
To address additional scope, changes are broken down into three categories: fixes, clarifications, and enhancements. Fixes are defined as incorrect implementations of a feature. Clarifications are changes resulting from customer feedback on the implementation of a feature, while enhancements are new features added to the system altogether. To summarize the concept, the idea is that fixes and clarifications are billed at the standard rate, while enhancements are treated as scope increase and are billed at the standard agreed rate plus the percentage of profit on the new project total. Time tracking becomes essential under this system – it is important to know how much time was spent per story as this directly impacts a fixed budget. As the project is developed, this system forces each side to consider the time and budget impact of a scope change.
Both systems provided a down-to-earth approach for variable-scope contract with a client while maintaining a nearly fixed cost. Each system succeeds at setting up both parties with “skin-in-the-game” by giving each party in the contract an incentive to succeed. In each case, the goal is to make client more like a business partner, and foster a trusting relationship. Any client in that situation is less likely to feel held hostage by an open-ended contract.
Note: Some great questions were posted by Greg Young about the legal aspects of contracts with regards to an agile methodology.
Expert Spring MVC and Web Flow