Successful projects, part 1: Paying for Attention

Ask any contractor the most economical way to get a job done, and the answer will be "Time and materials." The reason? You are taking on all the project risk.

Risk is, after all, the big question when it comes to any project -- what are the risks to the project? In software development, projects run over the initial budget all the time -- and that's generally because the scope of the project was unknown, poorly defined, or changed.

Guess what? That describes practically every web project ever done. Most clients are unaware of what is involved in bringing even a simple site to completion, and when you add e-commerce, event management, group functionality, and more, what's involved in getting that done becomes a complete black box to most clients.

Poor definition is an even bigger risk, because you don't know what you don't know. When a customer reveals a crucial requirement at the 11th hour, it throws even the best-planned projects off the rails. Having a well-defined project takes great attention to detail -- and a substantial amount of time spent planning, analyzing, and evaluating exactly what everybody is saying they need and how those pieces need to fit together.

Changing requirements, on the other hand, are a simple fact of business (as well as life...). If changes to requirements are caught early, it can keep the costs in check, but after a system is developed, there is always a cost associated with change. The trick is to anticipate changes, plan for them, do things to make accommodating change manageable, and be willing to spend because the value gained by making the change exceeds the cost.

With a time and materials approach, the client ultimately bears the risk of the unknown -- if it turns out that some bit of functionality involves more work than expected, the client gets charged for it.

We mitigate this with a "fixed budget" approach -- identifying what the client's budget is, what their priorities are, and be sure to get their priorities done first before we run out of budget. When we're out of budget, we either stop or get more budget to do the next chunk of work.

How interests collide: rewarded for shoddy work?

I think this is the biggest reason people are afraid of time and materials: they don't trust that the vendor isn't going to screw around and leave problems they will charge to fix later. The vendor gets rewarded for bad work with more work.

In nearly 2 decades in this industry, I have never seen anyone intentionally do crappy work to get more from the customer. I have seen a lot of incompetence, a lot of inexperience, and a lot of over-engineering, but never intent to swindle a customer.

The fact is, this is an issue of trust, and the competence of the developer you're working with. Developers are proud of the work they do, and they don't want to deliver a crappy product. Often there is not enough budget to deliver a better result -- it's generally very easy to get something functional, but very hard and time consuming to make it user-friendly, especially if you're working with existing code and trying to make it work in a different way (what happens all the time with Drupal).

This model actually fits the real world very well -- changes to scope can happen relatively easily with just an expansion of budget (and possibly some additional planning to figure out the best approach). You can change your priorities and stay agile, nimble to meet the next most important thing even as your business changes. And knowing this provides vendors with incentive to be fair and honest -- if we consistently do the best job we can, we get rewarded with ongoing work. And if we focus on work that makes our clients successful, they will have more budget available to spend with us.

Experience counts for a lot. We were recently brought in on a project where a prior developer had spent 330 hours over 3 months trying to build out a template-driven Drupal site, and basically had nothing usable to work with. We scrapped all of it, had the client adding content within a couple days, and got the entire project done in less than 250 hours and under a month, with several rounds of polishing and refinements after client feedback. If we had tried to follow the original developer's start, we might still be working on it and dropped far more time into getting a much worse result.

How to get the best results with Time and Materials

Here's our recipe for getting the best results:

1. Find a reputable vendor with experience that closely matches the kind of project you want to do.
2. Spend some time with the vendor in planning to identify the areas with lots of unknowns, and thinking through every angle of the problem.
3. Prioritize the work, and make sure you're working on the most valuable functionality first, so if you run out of budget you have enough functionality to drive results, be successful.
4. Understand that most of the budget will be consumed very quickly at the end of the project, as a result of things uncovered during testing. Testing always reveals rough edges you will want to smooth out, and this always leads to more work and more budget -- if your budget is tight you might have to accept this if you haven't left enough buffer at the end.
5. You will want more when the initial project is over. Expect and plan for additional development and budget after the project is launched.