| Scheduling Patches | KEVIN RESCHENBERG
03-28-2005 |
Last week I discussed
whether to apply patches (updates, fixes, bundles, service packs)
and pointed out the risks you face whether you apply them
or not. Various installations have effectively followed policies
ranging from one end of
the spectrum (always apply all patches) to the other (never apply any,
unless a specific bug is identified). You may have concluded that
it is better to apply patches. In that case, how do you schedule
the work?
I spent some time at a site that had no policy on this and needed
to come up with one. We put together a small team to discuss the
options and develop a procedure. The group agreed on a policy that
said that all patches would be applied, but not necessarily as
soon as they were released. The functional team wanted to review
patches with the users, so we would try to batch these into
scheduled projects. A "patch project" would occur when a tax
update was released; when a major bug was identified; or, in any
case, at least twice a year. The group reached a consensus on this
and all was well.
Here's what happened. Each time a patch update project was
to begin, it bumped up against another project's rollout, or vacations,
or a busy period, or payroll deadlines, or... And each time this
happened, the project was delayed. It was always the lowest priority
item on the schedule, so it was delayed over and over again.
Part of the problem was the understandable desire of the functional
team members to review the available patches first. They wanted to ensure
that each patch was desirable and that they could identify test
conditions for it. There were a few problems around this, and I've seen the
same situation played out at several other companies.
First the functional team wants detail on each patch—often more detail
than the published description includes. They turn to the technical
people, who don't have time to pick through the code in an attempt to produce
readable documents. The functional people say, "just give us the compare
reports". The developers run the compare reports, print them, take
the mountain of paper to the functional lead's desk and drop it
with a thud. One look
convinces everyone that this is not the way to go. (Or at least it should.
Some functional people do try to slog through the reports. Again, this
is not the way to go.)
I hope that you have resolved this and have a procedure that works.
One way may be simply to apply every patch as a "bundle" is
released, documenting the patch and
informing the end users only if it causes a change in their
processes. In other words, run compares to allow migration and to
discover conflicts with customization, apply the patches, and move on.
Picking and choosing patches can get you into trouble. Next week, how one
customer did get into trouble and how we resolved the problem. It was
sort of a cheat, but it did work.
|
