Shaking IT Up: Meet That Date!

by Kevin Vandever

How many times have you been given an IT-related task and been told, "This has to be done by so-and-so date?" (Fill in "so-and-so" with your own unrealistic date). Wait! Don't answer that question. The easier question is: How many times have you been given an IT-related task that did not already have a date attached to it?

It seems as if the creation of due dates and project deadlines are given about as much thought as the color of the IT department's cubicles, yet the foundation of the IT department is built upon how successful its people are at meeting those dates. In my experience, I have run across two basic schools of thought regarding deadlines. The first is the school that thinks if one sets a random date, another will work toward that date and, sometimes magically, finish the project on or before that date. The second school says that a date should be determined after project scope, available resources, and other variables are understood and discussed. I know, you've probably never heard of the second school, but it exists.

I defined these two schools at a pretty high level, and there are probably other schools or variations of the two I mentioned, but most of the shops in which I've worked, follow one of the two schools of thought. Taking that as a given for the purpose of this article, I will now tell you that in my experience, most shops attend the first school. Some blatantly admit it and others think they are following the thought of the second school when they aren't even close. Because the majority attends the first school, one might think that it is the preferred way to determine dates and project deadlines. It is certainly the easier of the two schools, and probably throws the better parties, but the fact is that not only is it the least effective of the two schools, it is the most dangerous.

Let us dig a little deeper into the two schools. The first school states that a date is made based on issues outside of IT, but sometimes from inside of IT by using a special rule that I'll discuss in a moment. These dates may come about because of external pressure of a customer or some other hard date that cannot be altered, but most of the time the dates are based purely on random thoughts and when the customer would like to have his or her enhancement. Of course, there are problems with this type of date estimation on many fronts, but the primary problem is that neither the user nor the IT representative has any idea of the effort required at the time the date is determined. This becomes a problem for not only the current project, but for subsequent projects as well. Before long, the snowball has turned into an avalanche and none of the IT projects are finished on time. Once that happens, things are rushed to meet the unrealistic dates, which leads to errors, which leads to a lack of confidence from the business as well as more bug fixes, which leads to more bugs, which leads to chaos. Get the picture?

As I mentioned above, sometimes the IT department comes up with the dates without outside influence and school one has an interesting rule of thumb for determining its dates. It is called the Friday or end of the month rule. That rule states that any date estimated should wind up on a Friday or the last working day of the month. This makes it very clean and takes away the necessity to start up a new project in the middle of the week, unless the end of the month comes in the middle of the week, in which case it's okay. The user community likes it because they can get their enhancement and go home happy for the weekend or start the month off on a clean slate. If a date slips for some unknown reason, simply move the date a week to the next Friday, or if it's a large project, to the last working day of the next month. This a very straight forward and simple rule to follow and one will do well in this school if he or she learns it.

The second school of thought is much more difficult and requires one to do much more homework. In this school, IT is responsible for determining the dates. However, unlike the Friday rule, dates in this school are estimated by taking the abilities and the workload of the IT organization into consideration. History is also used to help determine how long it takes certain people to perform certain tasks as well as to help plan for the unplanned. By measuring estimated dates versus actual completion dates and understanding what caused the gaps, the odds that future dates will be estimated correctly is greatly increased.

In this school's approach, each step of the software development life cycle is carefully taken into consideration and estimated separately, as are the delays between getting from one step to the other. This granular approach allows for a more realistic date because if there is a problem at any one step, it is easier to catch and therefore more likely to be rectified with additional resources or if the date has to be adjusted, it can be done so earlier in the project and with concrete evidence as to why. This is much better than waiting until the end to let the user know the date is going to slip and without any real explanation as to why.

One problem with this school is that it is not always popular with the customer. When the distribution manager wants something by the end of the month (see the Friday rule from the first school), it is sometimes difficult to explain to that person that his or her date is unrealistic and in order to make it, short cuts might have to be taken and quality will be sacrificed. This is often where the decision to attend the first school comes into play. The analyst wants to please the customer so instead of providing the best practices from school two, he or she will agree with school one's philosophy and estimate accordingly. This may seem like the right thing to do upfront, but later on, when the IT department keeps missing the date, or worse yet, the date is met but the software is full of bugs, that same distribution manager is not pleased and his or her confidence level in IT for future projects is shot. The best thing to do is give the tough answer up front. Then meet that date using school two's philosophy. After a few of these victories, not only will the customer's confidence in IT soar because the date has been met and the product is of high quality, but the customers will no longer dictate dates to you.

So, which school is your shop attending? Are your dates dictated to you, or do they all wind up on Fridays? Or do you take control of determining the date by doing your homework and understanding the necessary components while also adding room for the unexpected? Do you party first and miss or fail the final exam, go on probation, and eventually get kicked out of school, or do you do your homework, study appropriately, and ace the final exam? The choice is yours. If a company really cares about its IT department meeting its deadlines and providing a quality product the first time, it will do everything possible to steer clear of school one . . . except for the parties, which of course happen as soon as all of the work is done.

Click here to contact Kevin Vandever by e-mail.