Aggressive Schedules - Few thoughts...

During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.

After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following.

• Project ended up delayed by more than 100%
• Project got cancelled
• Project got de-scoped
• Project has a high cost of maintenance. 

Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we actually realize. 

First let me list down the obvious damages.

• Employee burnt out.
• Increased attrition rates (where the attrition rate of the people in the project is much higher compared to the company average).
• Decreasing productivity (a project planned for 10 months takes 20 months – so you do your calculation).
• Unhappy customers/stake holders.

But if we look at such projects in a more objective manner, with a intent to fully understand the decisions taken and lessons learnt, I am sure we will be in for lot of surprises. We will understand that AS projects also exhibit the following symptoms and produce undesired side effects, symptoms and side effects that are only visible to the discerning.

I have listed down each one of them (there may be more and i leave it to people to point out).

Let me start with the Symptoms

• Naked emperor syndrome (aka not seeing the reality). The first AS project that I worked was an re-engineering project. When it was pointed out that a Gartner report mentioned that re-engineering project of this size needed double the time (allocated now), the director in charge of the division gave the response that we will some how make it. No, he didn’t go into the details. But we finished the project way beyond the estimated time. Another manifestation of this syndrome is acting surprised when the schedule is not met.
• Not understanding a schedule: Blind belief that the schedule is achievable, without looking into the details. A good schedule is one that delivers the results on the said date. The definition is actually as simple as that. AS Projects keep schedules and miss it regularly.
• Mixing planning and goal setting (Related to the previous point):  The aim of schedules is to do detailed planning. Not goal setting.  When we set a goal, we need to understand that there is a probability that the goal can be missed. Accepting a goal as a schedule or a schedule as a goal means that people mis understand the fundamental point of a schedule. To re iterate my point again, ‘a good schedule is anything that delivers the results on the said date’. If the schedule doesn’t it is bad schedule.
• Irrational expectations or Expecting a marathon to be run at the pace of a 100 metre race: Different phases of the project need to be run at different speeds. But AS projects expect the workers to maintain the same speed from start to finish and this expectation is very detrimental to the health of the project.
• Bad Politics and Politicking: Aristotle mentioned politics as a noble profession. But this politics I talk about is related to group-ism, with a few hijacking the project goals for their welfare. AS projects are typically hell to work in, because of the constant politics that is there and the fear of back biting.
• Fear: I once asked my manager why we are working hard as per the schedule, as everyone at the ground level knows/talks in low voices that the schedule wasn’t achievable. The response was very simple and straight forward. He said, “If we work like this, tomorrow when we fail, no one will blame us for not trying hard enough”. Feelings of this kind are very usual in AS projects.
• Labeling people: Calling people who ask questions about the schedule as ‘in-efficient’ and ensuring that they are marked out and some times forced out of the system. If they are marked out, then these will be made scape goats when the project fails to meet the schedule.
• Not being prepared for Failure: In any typical AS project, the schedules actually set goals. Going by the definition, given above, this means that there is a high probability that the schedule will slip or can’t be met. But since the typical AS project believes that the schedule can be met as planned, there is hardly any fall back plan when there is a failure. And 99.99 % of the time, there is a failure to meet the schedule and then all hell breaks loose. Everyone acts surprised as to why in the world the schedule wasn’t met. Aggressive Schedules today may be required by the shorter time to market or quick turn around time. But when people get into such schedules, everyone should understand that there is a higher probability of failure compared to success and expectations should be set accordingly.
• Lack of accountability: Invariably the implementation team is made responsible for failure, when there is a schedule slippage on the part of people who ask for aggressive schedules. Making the implementation team responsible for the failure to achieve the schedule, when the schedule was forced on them is what usually happens. Instead people, who actually ask for such AS, should also be held responsible.

Projects with aggressive schedules leave behind many undesired Side Effects. I call them collateral damage.

•  Wasted Effort: Lot of effort is wasted in AS projects. By definition, a project has finite time and budget and hence limited effort allocated. If the effort allocated is consumed without producing the desired outcome, the project has wasted its effort. In one of the AS projects that I worked in, after having scheduled aggressively, people also thought that the project can be finished in time by getting more people earlier (than needed) into the project. During Analysis phase and Design phase, we had the complete team (where as analysis and design need to be done by not more than a handful of people). Because we wanted their time to be effectively utilised, we asked them to learn the specific technology used by the project. And to teach them, we actually made use of the people from the Analysis and design team. The plan was to use the output of this team as a prototype. But because the schedule was aggressive, we actually ended up building the application on the prototype work (a work that should have been thrown away). This resulted in lot of re-work in the project. So when I look back at the effort spent, I see that the effort of the whole team in doing the prototype + the effort spent in re-doing the work, were both wasted.
• High Cost of maintenance: AS Projects, when and by the time they deliver, end up taking lots of decisions that are detrimental to the overall health of the Product of the Project. To use Steve McConnell’s words, these run very high technical debts in the process. So even if the product is delivered, their cost of maintenance and hence the total cost of ownership are very high.

Don’t get me wrong. I fully understand the need to be optimistic with expected timelines, in today’s 'shortened Time to Market' world. I am not against schedules that stretch people or against schedules that make people more creative, ingenious and learn something totally new in the execution process.

I am only not for any project that starts at a break neck speed, only to crash before reaching its destination.  And projects with aggressive schedules typically follow this course.