🚀 go-pugleaf

In article <1992Apr14.175628.6961@lotus.com>, pedersen@lotus.com (Michael Pedersen) writes:
> I am preparing to implement a Change Management system in a VAX Cluster
> environment where none has previously existed. However, I am receiving
> conflicting input: some people say that the end user, i. e. the
> applications programmer, should be involved in the process of implementing
> Change Management; others say that I am primarily dealing with changes
> to software and that applications programmers have nothing to do with
> the way I implement Change Management.
> 
> I would appreciate any input on the best way to proceed. Is it one way
> or the other? Or somewhere in between? Please send mail with your thoughts
> and/or opinions.
> 
> Michael Pedersen, Manager ISS Production Control
> Lotus Development Corp.           (617) 693-1473
> 55 Cambridge Parkway              DECUS Member
> Cambridge, MA  02142              pedersen@lotus.com

We implement change management on our large Vax cluster (7000 users) as
follows:

- Our environment is such that we're basically a service bureau.  All
application development is done by our customer base.

- Simple changes are approved several days in advance of the change.  A notice
is then sent out to all interested parties (mostly internal) announcing the
work that is happening.  Simple changes include software reconfigurations,
upgrades to software, hardware installs, etc that are expected to have no
significant impact on the end user.  Normal developers are not included on this
list; the customer service center is.

- Significant events are preceeded by Vax Information Bulletins (VIB). 
Depending on the type of change, the lead time for a VIB changes.  Major
upgrades (eg, VMS upgrade) have up to 30 days lead time.  The VIB distribution
list includes the technical contacts for our customers and some management as
well as the simple change distribution list.  New product installations usually
have an associated VIB.  VIBs include details (or pointers to) additional
information such conversion guides, impact assessment, testing requirements,
etc.

- Changes that may affect areas outside of the Vax environment go to our
corporate Change Control group for coordination amongst multiple departments or
divisions.  This includes stuff such as building power outages, network
outages, etc.

This type of change management works fairly well for us.  We rely on the
support groups to identify whether or not customers will be impacted.  Usually
we guess right; if not, we hear about it first thing Monday morning :-).  It's
not as formal as our IBM offerings.  This is partly due to the size of the
customer base (7000 vs >35000) and partly due to the complexity and number of
changes we make.

Hope this helps,

-- 
Ed Wilts, BC Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8
EWilts@MR.Gov.BC.CA   |   Ed.Wilts@BCSystems.Gov.BC.CA   |   (604) 389-3430