Y = mx + b: The Ultimate Road Warrior Project Management Equation

Y = mx + b. I bet you have never thought you’d hear that equation again after you got done with high school algebra. Additionally, you probably always wondered what knowing how to draw a line would ever be useful in real life. I thought the same until I started having to plan multi-stop work road trips, and then I found out it was the perfect equation for planning trips and staying on schedule.

What I find kind of funny is when I was young people would tell me I needed this advanced math in order to work with computers. While some programming might require this, doing systems administration work requires basically an 8th grade education, a little common sense, and a willingness to learn and adapt. Literally the highest level of math that I have had to use on the job is basic algebra and this was only used when it comes to planning trips.

When planning trips you can break down each variable of y = mx + b as follows:

Y- Number of total hours to work

M- Amount of time it takes per unit of work

X- Number of units to work

B- Total travel time

Basically the equation looks like this- Total Hours Worked = Amount of time per unit * number of units + total travel time

With this equation, you can apply 8th grade math to it and figure out either how much work you can do in a 40 hour week, or how many hours you will need to work in a week (or longer) in order to complete the specified amount of work and then put a schedule together around it.

You might wonder how can you get all the variables to make this equation work. It does take a little leg work, but you can easily get these variables. To make things easy, I’ll use a single week of the Microsoft Surface deployment project and show how this would be planned. I’ll use the Beaumont, Conroe, and Bryan trip I took.

The easiest variable to get is M, or the time it takes per unit of work. This is done through a pilot phase where you get a representative group of users and then find an average among those users. In the case of the Microsoft Surface deployment, the Austin DO was chosen. The Austin DO was across town from headquarters and had enough users that represented the other users in the field.

For the pilot phase it’s meant to explore all the issues that will come up so you have to give it a lot more time. After doing the deployment at this site, it was found it took on average 3.5 hours per user. This average came from the total time it took for everyone to be deployed divided by the amount of users. All the other issues that popped up in the middle of the deployment such as being asked for help by other users (this happens all the time doing on-site IT work), slow connections, or pretty much anything else that you wouldn’t think of.

Once you get the average time it takes per work unit, the equation now looks like the following: Y = 3.5x + b.

I’m sure there’s a more mathematical way to do this, but I guess a little trial and error got me good with estimating the B variable or travel time. I’d see a cluster of cities I needed to go to and then I’d choose them. Typically, I’d have a rough number of people per site so I could easily guesstimate how many sites I could put together.

In this case, I chose Beaumont, Conroe, and Bryan because they seemed close enough and had a limited number of users. One tool I’ve found is great is the Mapquest route planner. When I found my cluster of cities, I could easily put them in the route planner. I’d include Austin with the directions so I could make it a round trip.

I’d get the directions and then check the slider boxes for “Allow us to re-order stops on your route” and “This route is a round trip.”

It would then order everything for the most efficient travel time.

I’d then hit “View Route Directions” and it would supply me with the B, or travel time, variable. In this case it’s 8.75 hours.

Now that I have the total travel time, my equation now looks like: Y = 3.5x + 8.75.

From here, you can figure out how many hours you will need to work to complete all the work or how many users you can do in a set amount of hours. I do not remember the exact hours of the trip I took, but for simplicity sake, let’s say there’s 2 users per location to make a total of 6 users.

To find out how long it would take to deploy 6 users the equation would look like: Y = 3.5(6) + 8.75. Basic math will tell you it’ll take 29.75 hours to deploy 6 users at those 3 locations when you factor in the travel time.

You could also reverse the equation and say you wanted a 40 hour week with no overtime: 40 = 3.5x + 8.75. When doing the basic algebra on this, you’ll find you could feasibly take care of 8.9 (we’ll just say 9) users from this given trip in 40 hours.

As you can see above, Y= mx + b was the basis for me getting a big picture idea to figure out if I could feasibly do a specified amount of work on the road in either a specified amount of time or I’d figure out how much time I would actually need to complete the work. If the calculations didn’t fall within my given specifications, I’d finagle a few things around by either adding or removing stops and make the math work right to make sure I could feasibly complete the work. Since most trips were multi-week, it would just be a matter of moving the work to a different week.

While I highly recommend doing a single project at a time to eliminate the complexities that occur with multiple projects, this equation can also work for multiple projects. You can add as many mx’s to the equation as necessary and you’ll get the same result for planning. The equation would look like Y = (mx) + (mx) + (how ever many more mx’s you need) + b.

Another thing to keep in mind is if you do a pilot phase properly, your average will be dead accurate. I know this because in the Beaumont, Conroe, and Bryan blog entry, I found myself being able to beat the average for part of the trip to then find myself on the slow side of the average:

“One rule of IT is never become too optimistic. I thought I’d have the whole deployment done that night and could leave a day early. There ended up being a lot of quirky things popping up, so I wouldn’t be going back a day early and would have to come into the office again. My intuition always seems to be correct when I do my initial planning. I am usually able to remain on schedule and keep my workweeks around 40 hours. This was no different and my optimism proved to be wrong, but my more realistic planning in the past proved to be right.”

As you can see, that trip was successful and stayed within a normal week. When I planned to scale the whole Texas-Mexico border and swap 19 routers at 17 different locations in 2 weeks, I was fully on schedule and not working any overtime until more unplanned work was added to my trip while I was in the middle of it. If I would have stuck with my original plan, I would have done all this work with no overtime at all!

In many ways it’s a bit crazy to think that what I thought was useless knowledge ended up being one of the most important pieces of information I learned in all of my math classes. I could literally plan out several months worth of work in a matter of a couple of hours using some basic middle school knowledge.

To see more of my adventures, click on the map! Or if you prefer to see a list of more blog entries, click here.

If you want to contact me, click here.