Why you are better off using a developer than a lawyer when purchasing software

The use of traditional contracts when purchasing software carry a flawed assumption – thinking the contract is the right mean to regulate risk.

The insight is key risks are : skill of the provider, the maturity of the client (yes you!) and ability to communicate honestly during the project. Few of these are effectively regulated using traditional contracts focusing on features, time and money.

Which are the key risks when purchasing software?

  • Lack of provider skill
  • Lack of customer maturity
  • Lack of ability to utilize late learning
  • A one time shot to get any IT updates in my environment
  • I win, you loose approach – no shared economic incentive
  • Lack of communication, during execution

Lack of provider skill:

Any skilled provider should be able to deliver running software on a monthly basis. Not being able to do so, means high risk. It is not a matter of size of the project or the provider, lacking the ability means the provider haven’t paid attention to evolve their abilities while growing. One way to validate a provider is to to give him one month to deliver, run it in your environment and look at the code. Yes, you also need to look under the hood. The code and quality of design tells about the craftsmanship that went in to building the product.

What about standard software ? Standard software normally comes in modules. This can be incorporated one by one, slicing down the risk and the size of the integrations and user process changes.

Lack of customer maturity:

Can the customer deliver a set of priorities timely? Are stories prepared before development starts? Software is a collaborative game where the slowest component in the chain sets the pace. If the clients IT department can’t roll in quality software any quicker than once every 6 months.. well.. then you are the slowest link in the chain. The maturity of the client is equally important as provider skill. Few contracts actually regulate the liabilities of the customer. Well written agile contracts do, generally they contain a section with a working agreement which both parties needs to sign.

No possibility to use late learning

This is basic agile stuff, ability to turn feedback late during the project into a better product. Again, customer maturity to adopt change can set the pace here. Client needs to be able to update work processes and add training for the software to be useful. This is often an underestimated undertaking.

A one time shot to get what I want

Fixed priced contracts create incentives for users to pull in everything they want in one go. It’s like there’s only one train leaving the station, so you’d better put all you want on the train. This turns small product ideas into growing avalanches that start having a life on their own. Before you know it they become unstoppable. The solution is to allow many occasions where scope can be added or changed. The better way to deal with this is

  • Clarify effect goals in the contract and how to follow them up
  • Don’t put full scope as part of the contract. A rule of thump says add two iterations of defined content, then allow client and provider together to add the scope for the upcoming iterations.

This requires client to prioritize continuously but gives him the option to use late learning.

No shared economic incentive

Contract won on cost competition creates poor incentives for the provider to deliver a quality product. The provider likely will likely sell many projects to overcome this fact with staff shifting between projects causing loss of focus and heavy delays. The best option is to buy on skill, over cost. It is also valuable to create a shared incentive like “Money for nothing and change for free” where customer get’s the remaining 70% of the budget and the provider 30% if the project finishes early. A way to mitigate changes in provider staffing is to ask provider to provide CV’s for all participants, and not allow participants to change staff without clients written approval.

Lack of communication during execution

All software projects means making tradeoffs and decisions. If we do not share problems, we can’t take decisions to mitigate them. Openness and transparency is key to deal with problems that will occur. If provider och customer hides their issues, then we are set to go down the loosing path. The trouble with fixed price, fixed scope contracts is they incentives the customer (sometimes the provider) to defer hard decisions under the excuse the contract will compensate for this later.

As you notice, few of the above risks are addressed by the use of lawyers. A better process is:

  •  Ask providers to delivering a pilot – if you have two providers competing, give both 1 month to deliver a pilot on running software, give the winning provider the rest of the contract and the loosing payment for that month
  • Run it in your environment – Remove uncertainty around environment fit early
  • Have a skilled developer to look under the hood (at the code and design). Share the insights with the provider.
  • As a provider, ask client for their training plan for participants in the project. Don’t assume they know agile practices (or software). Work in tight connection with real user groups (not necessarily the same as writing the contract). Ask for clarification of client roles (who will do what) and if client have granted participants real time to work on the project. If they do it “on the side” – this is a warning signal they are taking the adaptation of work processes and training too lightly.

Then move on to a contract.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.