Software Engineering Institute Carnegie Mellon

ASP Main Page
About ASP
Areas of Work
News
CMMI Acquisition Module
CMMI-ACQ Model
Acquisition Patterns of Failure
Publications and Presentations by Topic
Presentations
Publications by Type and Date
Related Materials
Adventures of Ricky and Stick
Success Stories
Pilot Studies
Useful Sources & Links
Training
Conference on Acquisition of Software-Intensive Systems
Contact Us

Ricky & Stick - A Big Software Change Means a Business Process Change

Ricky & Stick main page

It's usual that the introduction of a new software system means that the users will be doing something different from their familiar tasks. As often as not, the business processes have been reengineered and improved, and the end result is that things will change for the better (or, at least, so everyone hopes). But every now and then, someone decides to introduce a software system that doesn't really change any business processes. All it does is force the users to learn some very annoying software steps that don't improve anything: the users are doing exactly what they used to d -- but now it's harder.

When Ricky decided to improvise a new set of checkers, he paid no heed to what that implied. He and Stick had played checkers a million times, and were still playing the same game this time around; same rules, same strategy, same everything. But now they were fighting their own tools; they couldn't even tell which were their own men, and they ended up fighting with each other. The same thing can happen with software: a simple task executed with pencil and paper can become agony when it needs three screens, forty-three keystrokes, and a trip to the printer.

There are, on occasion, good reasons to introduce new software while keeping some process unchanged. It might be a huge increase in transaction turnaround time, or a vital need for consistency with other operations, or something of that kind. But whatever the reason, it has to be enough to offset the inevitable unhappiness of the end users. More to the point, any conceptual separation between a process and the software that implements it is suspect.

So the moral is: If new software comes into play, it's probably bogus to think that all it's doing is supporting the same old process.

Said in reverse, if you truly must introduce some new piece of software, ask yourself: Have I considered what process reengineering is needed? Have I brought it about? If you haven't, it's worth taking a hard look to find out why.


For More Information

Send comments or questions to asp-requests@sei.cmu.edu


return to top
Ricky & Stick main page
Acquisition Support main page