The Two Things About Scheduling

Recently we’ve started a series of posts applying The Two Things question to some of the topics we deal with on a daily basis at Newfangled. Make sure to check out Chris Butler’s The Two Things About Website Measurement, Chris Creech’s The Two Things About Content, and Lauren Walstrum’s The Two Things About SEO. 

I volunteered to write about scheduling, since that’s what I do. Here are my “two things.”  

1. Accuracy is more important than precision.
2. The schedule will (probably) change.

1. Accuracy is more important than precision.

The inspiration for this first “thing” about scheduling comes from the second chapter of The Art of Project Management by Scott Berkun. (That chapter, by the way, is a great introduction to managing schedules for software or web development projects.) 

“Often, people fall victim to the precision versus accuracy trap: an impressive-looking schedule with specific dates and times (precision) isn’t necessarily close to reflecting reality (accuracy). Precision is easy, but accuracy is very difficult.”

There’s a resourcing rule of thumb at Newfangled that says developers should have no more than 5 hours of work scheduled per day. Our typical work day is 7.5 hours. You might think scheduling would be as easy as looking at a week, and doing some simple math to decide how exactly to optimize a developer’s time. OK, that would be at the very tail end of design application, so he should be almost 90% finished. That’s got 37 hours budgeted, meaning he’ll still have 4 hours left to complete. So that week he should be able to also have 21 hours scheduled.

That’s all very pretty and precise, but it’s unrealistic. (And kind of creepy.) I’m scheduling human beings, not machines! We’ve still got a few years until the robot takeover, right?

The key to a good schedule is not just making the numbers fit. The key is to take everything you know—about the project, the client, the developer, the project managers, any other work going on—and figure out the best timeline based on all of that knowledge. Realism, not idealism.  

2. The schedule will (probably) change.

Because I’m in charge of scheduling, I spend a lot of my time at Newfangled attempting to predict the future. Since I don’t yet have the gift of second sight, no matter how carefully the schedule is thought out, or how realistic I try to make it, it’s never a guarantee.

As I mentioned before, there are many factors I account for when scheduling projects and upgrades. All of our long-term projects follow the same basic timeline, which is based on years of experience and historical data. An upgrade is scheduled as soon as it is approved, and its schedule depends on the complexity and the developer’s schedule in the coming weeks.

This second “thing” is truer at Newfangled for long-term projects than short-term projects. Most of our upgrades, especially those that only require a few hours of development time, are completed on time. The more complicated the upgrade or project, the more complicated scheduling becomes, because there are more moving parts. For long-term web development projects, small delays and schedule readjustments are the norm. There are numerous reasons for a long-term project schedule to slip: delays in approval of the prototype or designs; delays in design delivery; scope additions that were unaccounted for at the outset; you get the idea.

Here’s what Berkun has to say about schedule slippage: 

“No matter how precisely they are drafted or how convincing they appear, [schedules] are just a summation of lots of little estimations, each one unavoidably prone to different kinds of unforeseeable oversights and problems.”

That’s just the way it goes: stuff happens. And being able to deal with schedule changes is just as important as attempting to set up an accurate schedule in the first place.