Despite some lawyers' insistence to the contrary, few of the challenges that lawyers encounter are unique to the law business. Revett Eldred spent his career in the software business, managing large development projects. He's retired now, but posted the following advice in response to a question on Quora: "Why are software development task estimations regularly off by a factor of 2-3?"
Lawyers' clients ask the same question about litigation and transaction estimates. Project estimates, whether for software development, or litigation or transactions, are subject to certain rules.
This wisdom is equally applicable to sales, i.e., spending more time defining the problem will save you lots of time dealing with the consequences of your sales mistakes later.
Revett graciously granted me permission to publish his remarks here.
I started developing computer systems in 1965. Back then, it was a general rule that a problem that could be fixed for $1 during the specification phase would cost $10 to fix if not found until system design, and would cost $100 to fix if not found until implementation.
In other words, it pays to spend way more time analyzing the issue and specifying the functionality of the system than most people do. Fixing those problems is what takes extra time and blows the schedule. Even with totally different programming fundamentals and languages today, and with the widespread reuse of code, that rule still applies.
When I owned a software development company (back in the '80s and '90s) we used earned value to measure progress.
- Any measurable task had to have a deliverable associated with it.
- No task could take less than half a day nor more than five days.
In other words, if a "task" were estimated at three weeks, say, then it had to be split into smaller tasks, each with its own measurable deliverable, before a proper estimate would be believed.
Then, when the task was being implemented, it could never be a certain percentage complete; it was either done or not done--in other words, the deliverable was either delivered or not, the value of the deliverable either earned or not. I am constantly amazed that this method is still so rarely used. If nothing else, it avoids my first rule of traditional project measurement, which is that 90% of projects are 90% complete 90% of the time.
Attempting to produce accurate estimates of implementation before specification and design have been completed is just wishful thinking, or at best just a bunch of guesstimates. (Managers who won't accept reality are problem #1 in the system development business.)
Two things you learn the hard way when you build a successful application development business:
- Never commit to a fixed schedule for the whole project. Commit to a fixed schedule (and price) for the specification phase, and when that is complete commit to a fixed schedule/price for the design phase, and when that is complete commit to a fixed schedule/price for the implementation phase.
- Build into your contract the world's most comprehensive change control rules and procedures, and apply them rigorously.
The usefulness of these principles for litigation or transaction pricing should be obvious. However, there's a correlated sales application, too.
Don't attempt to sell the entire case or transaction.
Instead, first sell the specification phase. This protects your prospect and you, and gives you a chance to work together on a low-risk aspect first. (It also saves you from financing the planning.) If in doing so you discover that you're not a good fit for any of a number of possible reasons, you can walk away and shake hands because the client's money hasn't been wasted. He got what he paid for: he has a good case specification that he can use to select other counsel for the rest of the project.
Remember, no sale is complete until the last dollar is collected. Without a rigorous, disciplined specification phase, matter pricing is laughably unreliable, and you're asking for big collection problems.
RainmakerVT offers an online course that teaches you a proven, collaborative approach to pricing that results in the client and you both informing the estimate and sharing the risk of its accuracy. Right now, you can get it as part of a monthly subscription.
If you've ever purchased or participated in any kind of business development training, you know that much of the training you're asked to devote time to feels like "just in case." You can't see any immediate application for it, so you put it in the "get around to it when I have extra time" column. (We both know when you'll have extra time.)
RainmakerVT can help you develop the rainmaking skills you need to succeed amid real competition. This is not your grandfather's training. There's no program to follow, no big commitments, no nagging.
This is just-in-time training. That means you buy only the course you need right now to prepare for what you'll face in the next week or so.