Summary: Change Request (Long)

[Stacey Roberts <stacey -at- AIMETERING -dot- COM>]

On 12/10, I wrote:
<snip> I have been asked to create a change request management system
(write the procedures, create the forms, etc.) to handle changes the
customer will ask us to make to their systems, but I'm not sure of all the
possible solutions.  <snip>

Summary of Responses:
First, a brief answer:  of the possibilities you suggest, I'd stick with
the paper-based. Include spaces for the name/phone of the requestor, the
name and space for signature of the person who can authorize the change,
the date of the change request, a complete description of the change,
the estimated cost of the change, the time by which the change should be
implemented, the priority level of the change (as compared to other
requests and system maintenance/upgrading tasks), and the person/group
assigned to implement the change.  I can give you more detailed
information if you need it...but...

That said, let me issue a warning:  BE VERY CAREFUL WITH THIS STUFF!!!!!

Change requests and their approval/denial, implementation schedule,
cost, etc. can become VERY VERY politically charged.  Be sure that you
have a copy of the contract between your company and the client's and
read it carefully before writing any procedures at all.  Make sure that
your company has carefully considered how it will charge for making
changes and who has the final authority to decide whether or not a
change request will be honored.  You also need to be sure that the
change request system doesn't get confused with any bug-reporting
systems or procedures.  I've had a bit of experience with some of this
stuff, and hopefully I'm getting all worked up over nothing -- but be
cautious.  I've seen the writers of CM docs get hung out to dry because
they wrote the procedures without knowledge of contractual issues -- and
cost the company money, time, or both.
= = = = = = = = = = = = = = = = = = = = = = =
You might want to try an EDI implementation that lets your clients
technical support enter their requests into a forms-enabled database-linked
intranet page. Then, all you have to do is have a like client configured to
get through the client's firewall and to the client's database.

It really seems like a technical support database or knowledge-base would
take care of the problem.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Where I used to work, we had change request software that we developed
for our in-house software development.  It had a user screen that
had a database for the info that was entered.

You entered the category of software, the transaction code or program
that needed change, priority, description of the change, the system
analyst, programmer, tech writer, configuration manager, and requestor.
As each person did their job, they signed off on it and entered the
date.

As the job progressed through the cycle, the status changed from New,
Work in Process, To Production, Moved, and Closed.  You could sort
the jobs by status, user ID, programmer, transaction code, category,
etc.  When it got to moved status, I knew it was time for the tech
writer to work on it.  When I was finished, I changed the status to
closed.

You could also enter more detailed specifications and cross-reference
to the help desk software log numbers.  There was also the function
that let you search for all the changes that had ever been made to the
program.  All you did was enter the program number, programmer, or
transaction code.

It was a type of work group software.  It was useful for letting
everyone on the team know what was being worked on.  It prevented
programmers from starting to work on something someone else had
already started.  It kept a history of what had been done.
The users had read-only access to the log so they knew the status of
their request.

When working in an environment where there are no scheduled release
dates (every day is a release day), it was very useful.

Our users still had to call the help desk to make a request because
not every call required a program change.  We didn't let them fill
out change requests.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
You and I are in the same crummy boat.  <snip>

Anyway here is some stuff I found on that world wide web thing:
http://cobra.csc.calploy.edu/~dbut...a_scheduler/no_pref/CMP/intro.html
and
http://www2.umassd.edu/CoursePages.../LectureMat/config/configmang.html.

Here is how I want to handle the problem:
1.  Customer fills out the change request form on paper or on a Form
(either in Word or Access).  If the user fills out a paper form, then
the implementer of the change, if that is known, can help fill out the
on-line form.

2.  Change request form is routed for approval.

3a.  If not approved fill out some sort of request denial form
justification thing and distribute to whoever.

3b.  If approved a high level person, project leader or whatever, issues
an Engineering Change Order(that very impressive form name I plan on
stealing from the folks at Cal-Poly above)

4.  Someone fills out the Implementation Completed Form(or maybe
Engineering Implementation Completion and Audit Form...anyway, something
real scary sounding) and is signed by the appropriate people.

5.  Customer fills out the Change Request Change Form...ad infinitum....

I have a form started and it is going poorly.  I'm doing the form in
Word and adding fields so that a person could enter changes on the
screen or on paper.  But I'm thinking about using Access and a small
database for fields like "Requester" "Implemented by", etc.   Some of
the questions I've been asking myself include:  Who requests changes?,
who approves changes?  how can I inform other areas of the business that
my changes are going to affect them?
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Not to sound like a sales guy, but my company has developed such a
system - it's currently in internal use, going to market soon.  It's a
Web application, so it runs on any WWW browser.  It IS software, as
opposed to a paper system - but it's about as simple as you can humanly
get.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Thanks to everyone for their advice.  The big meeting is today...

Stacey Roberts
e-mail:  stacey -at- aimetering -dot- com