Worst-Case Hours and Risky Projects

Today I want to take a break from my usual coding challenges and talk about project management. As a freelancer, I’m frequently asked to provide quotes and estimates of many kinds. My clients and I both seem to like one in particular.

It comes from working hourly. Some freelancers don’t like to work hourly, but I do. I am not writing this to debate hourly v. fixed, or even to try to explain why I like hourly. I’m really here to discuss something my clients and I both like about my specific brand of hoursly estimates.

It comes from 2 simple ideas: lots of detail, and expected to worst-case hours. Here’s a bit about how it works:

  1. I make 2 estimates: expected hours and worst-case hours. If the hours come in less than expected, the client saves some money and I can move on to another project, making another client happy with their improved project. My clients are not expected to be responsible for hours beyond my worst-case estimate, and I typically end up very close to the expected hours.
  2. I break down line items hopefully down to single-digit hour estimates. Definitely no more than 30 hours for one line-item. Each line-item gets the 2 estimates, expected and worst-case.
  3. I highlight the line-items where the worst-case hours are at least double the expected hours — these are items which may be beyond the scope of the project, beyond my expertise, or otherwise inappropriate to include in the bid. My clients like to see that–it helps guide decisions about how to proceed and about whether we need to consult with another expert for a portion of the project.
  4. In the summary, I divide the difference between the 2 total hours estimates by the expected. If the result is over 0.5 (thaat’s 50%) then I consider the project to be at high risk for challenging development problems and advise the client that we should refine the project scope by reviewing the items from #3 together.

This may be overkill for smaller projects, and some will find it rather daunting for large projects. I find that in the end this level of detail and flexibility is always worth it for projects over 30 hours. I recently used this procedure on a job with total expected hours of 114 and total worst-case hours of 174. This meant it was a high-risk project (about 59% more worst-case hour than expected hours), but there were two line items in particular that cranked up the difference, and by removing them the job was changed to 103 expected hours and 152 worst-case hours. That brought the difference down to about 48% which is still a little high but definitely more moderate-risk than high-risk.

By identifying those two items specifically, we also pinpointed a lack of experience I had with a certain aspect of the system, and we have two primary options to consider when we get to that part of the project. We could consult with someone who does have the experience, or we could save those items for a sufficiently later date than the others such that I will have more experience with the system and be better prepared by the time I actually work on those items.

Here’s a sample outline for that scenario:

  • Major Division of Work PartA (TOTAL 18-28 HOURS)
    • Item a-1 description 8-12 HOURS
      • Item a-1 extra detail
      • Item a-1 notes and stuff
    • Item a-2 description 3-5 HOURS
    • Item a-3 description 5-8 HOURS
    • Item a-4 description 2-3 HOURS
  • Major Division of Work PartB (TOTAL 15-37 HOURS)
    • Item b-1 description 2-3 HOURS
    • Item b-2 description 1-2 HOURS
    • Item b-3 description 1-3 HOURS
    • Item b-4 description 6-15 HOURS***
      • notes about b-4’s difficulty and possible issues
      • and how that leads into issues with b-5
    • Item b-5 description 5-14 HOURS***
  • Major Division of Work PartC (TOTAL 81-116 HOURS)

    • Part C Setup Description 2-3 HOURS
    • PartC-1
      • Sublevel item–yep sometimes you have to 10-15 HOURS
      • Another Sublevel item 2-3 HOURS
      • Another Sublevel item with details 16-22 HOURS
        • notes about this item
        • details about the implementation options
      • Ok last one in this C-1 area 3-5 HOURS
    • Part C-2
      • First sublevel of C-2 item 16-22 HOURS
        • list
        • of
        • item
        • resources
      • Second sublevel of C-2 item 12-16 HOURS
      • list
      • of
      • implementation
      • locations
    • Part C-3
      • Sublevel item 4-6 HOURS
      • Sublevel item 6-10 HOURS
      • Sublevel item 10-14 HOURS

Ah there you have it. This structure (as well as the overview and summary sections of the proposal document) took about 4 hours to construct for this project, and I expect any project over 100 hours to take a few hours to write the estimate. I work that expectation into my hourly rate, and thus do not worry about the off-the-clock time it takes before the deal is sealed.

On the other hand, I feel that I have a pretty good feel for the potential red flags that mean it would not be worthwhile to put in that time. One of the hardest things about freelancing is actually choosing projects/clients that fit my skills and preferences. But that’s another topic for another day!

0 Comments on “Worst-Case Hours and Risky Projects

Leave a Reply