My post, They Say We Landed a Man on The Moon, resulted in a number of private conversations about schedules. Enough private chats; let’s light the fire and really get this discussion going. This is part 1 of a two-part discussion on schedules, scheduling, and adhering to schedules.
Let me start by saying that schedules are as important as requirements. Proper planning dictates the project must have a schedule and everyone on the team must understand his or her contribution to keeping the project on that schedule. In addition, the schedule should be a commitment on the part of the developers and that cannot happen unless the components and milestones in the schedule have been specified by mutual agreement between developers and management. A schedule cannot be dictated to the developers if one desires their commitment to stay on that schedule.
It is common sense why the team must adhere to the schedule. However, common sense is sometimes not as common as we would like so we should specifically state some of the reasons:
· Working on a project means the team is getting paid. Working longer than expected means more money must be spent than initially budgeted. Companies have finite money, so more money on one project means something else suffers.
· Working on a project longer than expected also means the team members are NOT working on the next project.
· Taking longer to finish a project means a delay in the additional revenue the late project was intended to produce. The company gets hit with a double-whammy. It spends more and makes less. Obviously this cannot continue indefinitely or the company will be forced into bankruptcy.
· Other groups within the company may be depending on the engineers to stay on their timeline to make any number of related events possible. For example, an advertising campaign won’t make much sense if there is not yet a product; being late for the Christmas selling season may seriously damage projected revenue; and missing a planetary alignment pretty much kills the mission.
· Managers look bad when their project is late
· Developers look bad when their project is late
· The available time provides a context in which to make engineering tradeoffs
· The available time frames the acceptability of certain project risks
Given all these very good reasons, how can there ever be a justification for a schedule slip? Well, sometimes the insidious universe just won’t cooperate and problems take unexpectedly and unpredictably long to solve. In other cases the original timetable was just not reasonable. On occasion the schedule was arbitrary and externally imposed and never really intended to be realistic. In other cases there was a good faith effort to make an achievable schedule but the effort was badly underestimated. My 30 years of engineering experience says two things are absolutely critical to creating a pragmatic schedule to which the team has some chance of adhering:
· Previous experience with the project technology and architecture
· A calibration of the productivity and work quality of the team members
There are always surprises when the team lacks experience in the technology or system architecture. In this scenario, schedule estimates amount to no more than educated guesses and these guesses can be wildly inaccurate. Likewise, the difference in the volume of robust and reliable output of software, hardware, and firmware engineers seems to vary by nearly two orders of magnitude. Unfortunately, most engineering of new products is explicitly about new technology, new ways of doing things, and often with new teammates. Despite the importance of staying on the established timetable, we have a real-world environment where development of the newest and most advanced technology is seemingly destined to fall behind schedule.
* * *
Consider a project that is starting to fall behind schedule. Here is where bozos and clowns make their grand entrance. Schedule deadlines, realistic or not, provide an excuse for the inept to make ridiculous and damaging demands. True leadership manages to a schedule but through experience and knowledge understands the tipping point. Real leaders understand when a slip is justified and when extreme efforts to stay on the established timeline simply inflict further damage on the project.
It is important to frame this problem in the corporate context. Superiors must have an extraordinary amount of faith in a manager to tolerate schedule slips. The situation can exist where many in corporate executive management lack personal expertise in the technology being developed and correspondingly lack interest in problems along the way. For a number of executives, they only want to know their money is being well spent and the only way they can tell is to check off the milestones. Understanding the nature of a problem is not in their job description and most would not have the necessary time to invest in understanding even if they had the interest. When milestones are missed the easiest option is to increase the pressure. This means there can be a conflict between what is right for the project and what is right for the manager’s career.
Executive management can easily view a manager slipping the schedule as weak and simply not driving the team hard enough. Hence, in the normal corporate structure, we have an inherent defect. This defect forces upwardly mobile individuals to ignore or hide problems instead of confronting and solving them. In this environment, management weasels continually divert resources and attention from the righteous goal of a quality product so they can provide glowing status reports to senior management. Many times executive management never actually use products made in this atmosphere and are completely unaware of the buggy garbage being shipped. Instead of being chastised for shipping junk, the weasel manager is congratulated for delivering his project on schedule. Other managers observe this and we have created a corporate feedback loop that encourages unwarranted herculean and damaging efforts to stay on unrealistic schedules – often at the expense of product quality and supportability.
Many managers buckle under this perceived pressure and start skipping steps and taking progressively riskier shortcuts. It is incontrovertible that forcefully holding the line against schedule slips causes damage to quality and often results in actually lengthening the schedule as payment on risky shortcuts comes due. I have seen this too many times in too many organizations. I’ve seen complete disasters that resulted from managers doing insane things to stay on an impossible schedule.
Yup.