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 patcraig@alum.mit.edu .
|