Everything is completed by performing a series of tasks. To plan, estimate, forecast, etc. we most often predict the tasks we’ll perform to get the desired outcome, then sequence them, assign resources, and guess at a duration for each. In this model – we’re predicting the future and how we’ll get there. And for anyone who’s done it—or read about it—that’s a terrific way to fail. Why we almost always achieve the desired outcome, how we get there (and how long it takes) is vastly different from what we had planned. Again, this is because we can’t know unknowns (timing), time doesn’t scale, and we can’t control time (it’s an absolute).
The other problem with planning this way is that anyone not deeply entrenched in the industry performing the work has little-to-no valuable input. If you show a home owner the project plan for building a house—they likely wouldn’t know why pouring the foundation was dependent on plumbing, which was dependent on excavation. The project plan lists industry specific tasks in a detailed fashion with no mention of the desired outcome—which the homeowner (likely) will not have valuable feedback on.
We do this because without a task level list—we can’t guess at duration. And since our businesses run on time—we don’t know what to charge, how long it will take, what it’s worth, etc. This aside is a follow-up to my beef with time—my proposed solution.
[Hint, I’ll be referencing terminology from the prior post, so if you haven’t read it, you likely need to if you want to make sense of what follows.]
As a reminder, the point is that at the end of the day—what matters is what was completed—not how much time it took. Further, that which has the most value is that which is most difficult. Effort isn’t valuable—but progress and complexity both are. And unlike time, progress and complexity are valuable to the employer and the customer. A customer isn’t willing to spend more because your employee took more or less time—but they are willing to pay for completion (progress) and utility (complexity). For the sake of simplicity as we continue—let’s call this headway going forward.
My “solution” (read: suggestion) for how we move away from time and towards headway is as follows: (1) list the desired outcomes with “success criteria” for each, (2) rank each for headway, (3) prepare the project plan, (4) execute—monitor and control, (5) lessons learned and benchmarking.
Lastly, a disclaimer—I have not implemented this anywhere (yet). This is purely theoretical and intended to continue a larger (and more important) conversation.
Agree on the Desired Outcome (both deliverable and compensation) – Steps 1-3
Rather than guess at the tasks needed to get to an outcome—list the outcome. List it in plain, everyday language that anyone can interpret. Then give this to the project owner. Is this what they thought they were paying for? Iterations ensue, but once corrected have them rank each outcome for strategic value. In this example we’ll use A for low, B for normal and C for high.
Bring that list back to the team and have them rank each outcome for complexity (of implementation) using the same scale: A for low, B for normal, and C for high.
Now examine the list. See any items with a value of A and a complexity of C? Think the client really wants to pay for that? Can it be done another way? What about a value of C and a complexity of A… why should you charge so little? The client just told you it’s worth a lot to them. Remember, they’re willing to pay for value—not for time.
Yes, we’re adding some time to the front-end here (or not, depending on how you go about this now)—but, think of the time saved on the back end. No more misconceptions or wrong assumptions about the deliverables. It’s all right there in plain, simple language that everyone understands—with quantifiable criteria for each denoting whether it’s successful. (Read: no more rework.)
In summary, communicate the intentions of the project and the resulting headway for each deliverable.
When complete assign a magnitude to each. What’s important is that this is not a duration—it’s a magnitude and intentionally much “rougher” than a duration (not in resulting compliance, but in planning).
The assigned magnitudes include “hours, days, weeks, or months.” Not two days, not 57 hours, not three weeks—simply hours, days, weeks or months. Don’t over complicate things—your complex version of this now is sorely inaccurate anyway. Why waste any more effort when in reality, you don’t know?
Any outcome assigned “months” needs to be broken down further. Chances are the resulting outcome is too broad anyway to really communicate with the project owner what they’re paying for. In other words, if any are assigned “months” for a duration—I’d say the first step was done poorly. Take that outcome back to the drawing board and try again…
When every outcome is assigned a magnitude of hours, days, or weeks—we’ll plop them in a spreadsheet (find a template here) to assign a cost and timeline to the project.
Using web development as my industry of reference—I’ve used six hours to equate to one day’s worth of effort. Magnitudes each come with a baseline (below, again using web as my industry of reference) which is affected by the modifiers of strategic value and complexity (more on that to follow).
- Hours – 2 hours is 50% (staged), allowing 2 hours for feedback and QA
- Days – 9 hours is 50%, at 6 hours per day that equals 3 working days
- Weeks – 45 hours is 50%, at 6 hours per day that equals 15 days or 3 weeks
Once in the spreadsheet, the magnitudes are multiplied by the modifiers of strategic value and complexity. The result is that unless an outcome is ranked as both a normal value and normal complexity—you’ll never end up with the baseline durations listed above. The idea being that additional time needed for the unknowns is created and those items that have a high value to the client (regardless their complexity) become more profitable to perform. The attached spreadsheet illustrates this well and allows you to see the “nuts and bolts” of the idea. For those who aren’t MS Excel wizards or just don’t care that much—a screenshot is below to illustrate the point.
The point of all of this is that you end up with a true scope (not a list of tasks), a budget that represents what the project is worth (in compensation—regardless the duration required), and a timeline that is reasonable (for we always default to Parkinson’s Law).
Metrics & Benchmarking – Step 5 (Yes, we skipped Step 4)
Revenue in this model now directly represents headway and employees are easily compensated based upon headway (instead of hours, market value, and the like). The more headway you make in a year, the more you are compensated. Read another way—the more complexity and value a company can create—the more money you’re worth to the client and/or market. From a talent attraction and retention perspective for employers—you’re now profiting from a focused view on employee autonomy, purpose, and mastery . And you’re delivering a more profitable and sustainable product and service for it.
For a company to increase headway, it must focus on its hedgehog and reinvest in its people. The more effective your company, the more headway you can make in a year. Headway as a metric forces the company to be a better entity and not instead implement bullshit that doesn’t actually change anything except the metrics themselves.