SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Avoid This Time Scheduling Mistake

I was recently asked by a project manager to lay out when DBAs would accomplish certain tasks for a particular project. The primary DBAs would be me and a co-worker. We're under a tight schedule with respect to the project, so I fell into a trap that I should have avoided. If you've been around projects for any length of time, you know about this trap as well and hopefully this post will serve as a reminder. If you're not familiar with this particular trap, you can leave this post saying, "Now I know. And knowing is half the battle."

"Pad is Bad"

As a former PM (4 years thanks to the USAF) I know the phrase, "Pad is bad." This is where you intentionally inflate time estimates on your project. There are various reasons, but none of them are good. The short of it is that you're being deceitful. In the South, simple folks like me and Andy Leonard (website | twitter) would just say," You're lying." Time estimates should never be inflated.

Planning for Contingency

While "pad is bad," planning for contingency is smart. Life happens. People get sick. Cars break down. Water pipes burst. You get the idea. So as a PM I was always good about including buffer days that I would mark as "Catch up days." These were clearly identified for what they were. When the schedule broke down, and inevitably it would the first time a parent had to get their kid out of school/daycare because he/she was sick, these days allowed us to compensate. You don't need a lot of these unless you have a long running project. However, not having them could put you in a cruch. Whenever someone called me on these "catch up days," I had a ready defense: "So tell me what happens to the critical path if John gets sick and can't work?" That simple question should help folks realize you have to plan for contingency.

I Failed to Plan

When I put together the plan, I failed to plan for a contingency. There weren't any catch up days. We'd make the tasks just in time. And then... I got sick. I caught the flu bug.

What to Do?

Thankfully, I was able to work with a laptop from my home so I couldn't get any co-workers sick. Unfortunately, I had to work when I really needed to be resting. Why? Because I had forgotten to plan. I hate feeling the pain of repeated mistakes. This is one that I won't forget again so easily for some time to come.

What Should You Do?

When you are discussing the project/work plan with your PM, or if you are the PM putting such together, remember to plan for contingency. If you're the technical person providing input and you're challenged, ask simple questions that reveal the need for contingency planning.


  • What would it do to your critical path if we hit a serious production issue and it was an all hands on situation for a couple of days?
  • What if I came down with food poisoning and had an overnight stay in the hospital? How would that affect your timeline?


Things like that work. Don't overdo it. You're not trying to scare anyone. You're just trying to make a point that there is the potential for an issue and it's best to have some flexibility in the schedule to accomodate. If that doesn't work, then you've done your best. And if that contingency does happen, try not to say, "I told you so."


K. Brian Kelley - Databases, Infrastructure, and Security

IT Security, MySQL, Perl, SQL Server, and Windows technologies.


Posted by Dustin_Mueller on 8 February 2013

Good post! And instead of saying "I told you so", you could simply say "yeah, we planned for that."

Leave a Comment

Please register or log in to leave a comment.