Must the Date Move?
by Pat Craig 

From the Winter 1994 issue of the Complexity Management Chronicles 

Deciding whether a software deliverable date must, or can move involves many factors. If the deadline is fast approaching, then management has four major options when they cannot guarantee a quality version of the software project by the deliverable date:

They can install the software on time and accept the consequences. 

They can scale the project functionality down. 

They can increase the budget; add more members to the project or plan for a post-implementation SWAT team. 

They can deal with time constraints, i.e. move the deadline or have staff work around the clock.

Both the risk of releasing bug ridden software and contractual obligations influence the option chosen. Our clients solved this dilemma in the following ways. 

One client announces dates for new software deliverables months in advance. Moving the date would embarrass the firm. To meet one deadline, they released software with hundreds of bugs. 

At an MIS department housed in South Boston, one of the system managers has persuaded her users to move dates. She presents the users with the risks involved if the date holds firm. She looks at risk from three perspectives:

financial/liability risk, 
service level risk, 
department credibility risk. 

Then she provides her users with three different alternatives, one of which she prefers and pushes for. At the same company, another systems manager has met his dates by scaling back projects and delivering only the most critical parts of the project on time. 

When contractual obligations to meet the deadline exist, SWAT teams can control the damage after the deadline by working long hours patching bugs. We have seen this work with two clients, a Somerville client and a Boston based client. This technique can substitute for moving the date if contractual obligations exist and clients cannot easily take their business elsewhere. 

While working with a client south of Boston, we saw how the selling season dominates system development efforts. At one point a system implementation decision needed to be made near Christmas. Since the risk was not exorbitantly high, the software was installed, then patched. 

At a client based on 128, a past bug prompted large compensatory damages to customers, so deliverable dates usually move. When programmers do not make their deadlines, QA does not compensate for their slippage by shrinking testing efforts. 

A Charlestown based MIS group met their deadlines for a new accounts payable system by having two teams work around the clock on system development. One team worked 10-12 hour days, the other team worked 10-12 hour nights. They communicated with each other by notes or phone calls. 

If your deadline has a long term horizon, you might consider changing your development process to emulate one of our western Massachusetts based clients. One of their programming teams, who had a very close relationship with their users, developed new systems in small segments, quickly tested, and immediately integrated the new code into the older systems. If the users found flaws with the new system, the team corrected them immediately. The issue of whether dates had to move never arose because the team constantly installed small parts of the system. 

In conclusion, we trust the above examples will provide you with some creative alternatives when your next deadline looms! 

©Complexity Management 1994 
Somerville, Massachusetts. In Metropolitan Boston.

Complexity Management Chronicles, a newsletter for software quality assurance professionals, is published in print form four times a year. Send your name and snail-mail address to the e-mail address below if you would like to be on the mailing list - at no cost to USA mailing addresses. 


Return to Complexity Management Home
Contact Pat Craig at .