Contracts and Expectations in Small IT Projects – Part 1

Introduction – Fixed Price vs. Time and Materials

It is an axiom that businesses small and large consider IT projects high risk. Many have instituted policies requiring fixed price contracts, in order to minimize their risks. These same companies often do not realize that this policy creates a situation where engagements with their vendors become losing situations for each.

I contend that many customers and vendors share basic misunderstanding of the concepts of contracts, expecting the best of both fixed price and time and materials contracts. This first blog in a series will talk to some of the reasons why.

Almost every executive has a story of a project which started small and became a sucking black hole of time, resources and money. I have lost count of the number of these stories I have heard personally, on topics ranging from custom application development, to off-the-shelf implementation to web site delivery. While the stories differ in specific detail, the core elements remain the same:

• We thought it was a simple project
• The contractor/IT team/salesman told us it was straightforward
• We did not think that we changed the scope during the project
• We felt taken advantage of both during and after the project, if it ever finished
• We did what we were told
• The person responsible for the project had his/her career negatively impacted

The multiplier effect held true for these stories. For every first person epic I heard, there were tens of second and third person anecdotes. The grapevine is very fast, if not always accurate. How many times have you, the reader, heard the words, “Did you hear about … ?”

Not surprisingly, while companies still understand the need to have these projects done, they have and continue to push their vendors toward fixed price contracts. The ideas are basic and often reflect their own corporate processes. These include:

• Risk aversion and reallocation
• Payment for deliverables rather than effort
• Cost reduction

For some projects, this can be an effective policy. Where customization and configuration is minimal, it can be effective to contract purely on the basis of deliverables. A sample in the IT world might include:

• Computer setup
• Network cabling
• Server setup

The above, with a small number of parameters, are repeatable tasks. Once an image has been created and tested, computer setup effort can be predicted within a relatively accurate range. The same applies to cabling a building or setting up a server. Many companies provide fixed price estimates for these tasks, with constrained scope definitions in their contracts. Usually, these prices include a level of contingency to address the inevitable unexpected issues.

At its core, I propose that companies reason that if a vendor is proposing a solution, they should know exactly what it takes to deliver it. They should be able to estimate it in detail and if their estimate is incorrect, it is their own fault. The experienced and expert vendor should eat the extra risk, not the unwitting client.

Let’s look back at some of the core experiences.

Client	Vendor / Consultant
We thought it was a simple project	We told them, in person and in writing, that there was complexity to this project. They just could not seem to understand. Why hire a consultant when you don’t want to pay for consulting?
The contractor/IT team/salesman told us it was straightforward	We gave them a range of samples of our projects from similar industries. They latched onto the smallest effort and cost, though their project was more complex and larger.
We did not think that we changed the scope during the project	Every time we talked, the client wanted some additional customization, configuration, additional training or support. By the time we were able to understand what they actually wanted, rather than what they had said they wanted, the project estimate had grown. But they could not understand that what they wanted was not the same as what had been agreed to in the contract.
We felt taken advantage of both during and after the project, if it ever finished	We felt taken advantage of during and after the project. They kept asking for more and saying that it was a part of their original expectations. But we were so deep in we could not afford to pull out.
We did what we were told	They tried but even the most basic client deliverables required our assistance. The needed iterative discovery and delivery but did not want to pay for it.
The person responsible for the project had his/her career negatively impacted	The client was not happy and refused to provide us a reference. In fact, when they talked about the project, they implied that we did not provide what we said and that our service was lacking. The account rep is on thin ice. The PM and the team received smaller bonuses.
It is even more vital to require fixed price and to determine processes which make it harder for the vendor to change the project price after the start	How do we deal with them next time? They keep wanting more and making it harder for us to deliver. There does not seem to be any incentive for the customer to manage their own expectations or requests.
It seems unfair that we had to pay for change orders where the vendor did not always use all the estimated time.	Amazing. When the effort exceeds the estimate, they want us to cover all the cost. But when it is less, they want to pay less. Don’t these people understand a fixed price contract?

Another axiom in the project world is that successful small projects require the same processes as successful large projects. Implementing an application or web site requires detailed understanding of business and technical requirements. It is rare when a customer is happy with a completely generic solution which does not account for their specific needs.

It is common for customers who think their projects are small to expect that the vendor will enter the project with an innate understanding of the requirements. After all, they have done similar project before. They often convey their requirements at a very high level or do not truly understand their requirements.

Often, the customer does not actually understand what they want until they have had the chance to see a prototype or beta version. They see the site or the application and suddenly understand that what they really wanted was … something more. And here starts the almost inevitable discussion of requirements and scope. The customer looks at the vendor and says something to the effect of “You should have known what we meant. If you want to get paid, you have to make sure that the deliverable meets our current expectations.” So starts, with a certain inevitability, the arguments over scope, cost, change orders, timelines, expectations, contract terms, payments, escalation and reputation.

Vendors can feel trapped by the customer’s contract requirements. They are forced to include increasing amounts of consulting in the sales process in order to be in a position to engage with the customer. But this effort grows harder to recoup, as most customers are loath to pay for time incurred before the contract is engaged. To recoup their efforts they are required include copious amounts of extra cost which the client will then begin to whittle down. Like all vendors, they fear the other guy coming in to undercut their offer. They go low, expecting to make it back in change orders. And the cycle begins again.

On top of other difficulties, there is a lack of understanding by many clients of the difference between a fixed price contract and T&M with a fixed cap. This will be addressed in future parts. Suffice it to say that there are few worse ways to engage with a client.

There is no complete solution to the issues inherent in projects, fixed price or T&M. However, future installments will discuss:

• Expectations management
• Effective contract writing
• Proactive documentation and reporting
• Contingency estimation
• Vendor differentiation strategies.

Any insights or anecdotes you might want to provide can be included as comments to this entry, via the contact page or by e-mail to info@professionalservices.net.