Can anybody share your experiences in change request management related to group awareness or group interaction?

ssmfone's picture
ssmfone asked on May 4, 2011 - 9:48pm | Replies (1).

Do you know any technical/white papers that discussed about the issues.

Really appreciate if you could share your valuable experience on that matter.

1 Answer

Joe Farah's picture
Joe Farah replied on May 17, 2011 - 11:29am.

I've had various portions of articles covering this in the CM Journal (CM: THE NEXT GENERATION column). You may want to review them. But here's the basics in a nutshell.

For group interaction, you need a central repository of change requests. This is ideally in the same repository as your software. Otherwise, the interaction will be more limited. If users have to switch from one tool to another - well, it just doesn't happen that frequently.

That's why an integrated ALM/CM solution helps here (see CM+ for example).

The change request should be used to spawn a feature activity or a problem report for the engineering team. This spawning should be the result of the approval process for a change request. This is the responsibility of the Product Manager, typically through the Change Request Review Board (CRRB) or some similar real or virtual meeting.

The engineering team should not have to deal with duplicates - of which there will be many if the change requests are raised by multiple customers.

Feature activities or problem reports should basically appear on development manager in-boxes for assignment to their staff.

Change packages/Updates should have to reference a problem report or activity in order to proceed with check outs. This helps to ensure that only the proper changes are implemented, and gives a documented trace for the peer reviewers during the delta review. Ideally, the trace can be viewed on the same dashboard as the software delta report.

When the change package/update is checked in, the problem report or feature activity should be updated automatically to reflect the status change. This in turn should automatically cause the change request status to be upgraded.

Generally speaking, developers don't want to look at all the change requests coming in because a lot of them are duplicates, errors in user operation/interpretation, documentation issues, etc. The person raising the change request typically only knows one aspect of the request.

For example, the request might be: the screen background should be blue. But the engineering team should raise a feature activity that says: the color of the screen background should be easily configurable at run-time, and saved in each user's run-time profile. The developer can easily deal with the latter. The former would cause all sorts of questions and issues.

For this reason, one Best Practice of Change Requests must be a separation between Customer Change Requests and ECRs (Engineering Change Requests). In particular, the customer often doesn't know if something is a problem or a request.

The customer does not need to see the engineering discussions that go on - for example, entries against a problem report that say "reopened. The update did not fix the problem because...". Keep the dirty laundry in-house. The fix-verify-fix cycle is in-house activity. The Change Request should end up looking like:

---- date/time/user information --------
The screen background should be blue
---- date/time/user information --------
Request accepted. Feature direction is:
The application will allow the end user to easily modify the screen background color and this will be saved in the user's profile.
---- date/time/user info----------------
Request Implemented and Verified
----- date/time/user info --------------
Request implementation first available in build xyz.

The change request mechanism should be highly automated. Customers should receive regular reports on the status of their requests.

Details on how a request is being responded to should be forwarded to the request orginator prior to implementation, to ensure the origniator's request is being fulfilled. In addition, the originator should have the final input on whether or not the request has been fulfilled (ie. the originator should close off the request).

A Request Backlog dashboard would serve well for the Product Manager and the Product Team to increase group awareness.

As well, the Product Backlog and Problem Backlog available and used by the engineering team should have an easy to navigate dashboard with single button access to the original Customer Request.

Don't try to separate Customer Requests and Customer Problems - the customer does not generally know enough to distinguish the two... Let the customer select a "type" which might indicate problem or feature, but it's not until the product team sees the request that final determination is made.

Hope this is somewhat helpful.
Joe

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.