Aside

Consulting Contracts and the Behaviours They Encourage

In a  recent post I spoke at a high level (and at length, it seems) about the things developers need to know about different consulting company contracts they might encounter in the workplace. After reading the article, fellow Perthie and all round awesome guy Mike Minutillo pointed out that there’s some good information in that there about what different contracts cause people to do, but it’s hidden in a big sea of text.

To that end, here’s a list of the key things that each contract incentivizes the different parties to do. If you want a more in depth explanation of each contract type then check out the aforementioned post. It should be noted that these are not things that you’re guaranteed to get; it’s just that typically these contracts encourage people to act in a certain way in an attempt to “win the contract”. It’s by no means complete, but it should be a good start.

Consulting firm is more likely to… Client is more likely to…
Fixed Price – Fixed Scope
  • Scrutinise all work for potential scope creep
  • Work as quickly and cheaply as possible
  • Ignore long term maintainability in favour of short term implementation, resulting in reduced quality
  • Swap in cheaper resources to reduce the budget burn rate
  • Make heavy use of the change request process to capture even the slightest variation to the contract
  • Aim to finish well under budget, as they get the same amount of money regardless
  • Require that clients define requirements up front
  • Create vague requirement documents that are open to interpretation
  • Approach individual developers in an attempt to convince them to implement scope “under the radar”
  • Argue that features are in scope by expanding the meaning of agreed requirements
  • Try to avoid drawing down on agreed contingency as it is the only variable funding in the project
  • Rush the requirements gathering process in order to have enough information to sign a contract
Fixed Price – Variable Scope
  • Swap in cheaper resources to reduce the budget burn rate
  • Give extremely conservative estimates to the client to reduce pressure on the development team
  • Argue that features are not required
  • Push for project completion as soon as possible. They still get paid for all the hours even if the hours are not needed.
  • For for re-estimation, change requests and draw down on contingency for any scope change
  • Demand a deep level of analysis up front in order to determine the budget
  • Demand estimates at an early stage of the project to determine timeframe and appropriate burn rate
  • Stick to early estimates as the project progresses, even if requirements have shifted
  • Watch development team closely to ensure that value for money is being had
  • Be even more reluctant to draw down on any contingency
  • Try to get the consulting firm to do as much work as possible during the time period
  • Argue with the consulting firm over estimates
  • Blow scope out of the water simply to get “better value for money”, potentially leading to waste and unneeded features
  • Request that developers cut corners and reduce quality to fit more functionality in, especially if there is a warranty clause in the contract that will force the consulting company to fix any defects for no cost at a later date
Time and Materials – Capped
  • Swap in cheaper resources to reduce the budget burn rate
  • Push to make the work track closely to the estimates, often at the expense of functionality or quality
  • Restrict client’s access to developers in an attempt to limit scope creep
  • Demand a deep level of analysis up front in order to determine the budget
  • Demand estimates at an early stage of the project to determine timeframe and appropriate burn rate
  • Stick to early estimates as the project progresses, even if requirements have shifted.
  • Watch development team closely to ensure that value for money is being had
  • Argue among themselves over what scope to implement during the project, given that there is a cap on the amount of time that can be engaged.
  • Try to get developers to make promises around feature delivery that can then be used as ammunition if the project does not go to plan
Time and Materials – Uncapped
  • Attempt an agile delivery
  • Attempt to artificially elongate the project, usually by making claims around quality, process or procedure
  • Use the most expensive resources available to perform the work
  • Be able to actually develop with an appropriate level of quality
  • Watch development team closely to ensure that value for money is being had
  • Feel comfortable defining detailed requirements as the project progresses
  • Change their minds on scope, potentially producing waste but usually resulting in a better outcome
  • Get the software that they want/need

About Garry

I'm a Solution Architect living in Perth, Western Australia. I work primarily with Microsoft technologies, but I have an open mind and like to branch out into other areas in my spare time. I'm also a Microsoft Virtual Technology Solutions Professional (VTSP) in the Integration space and like to stay active in the local development community.

,

No comments yet.

Leave a Reply