Implementing a requirement is always implementing a change. Thus change management (CM) and change requests (CR) become important in this article. Even the different approaches of upcoming changes in product, processes and organization are determined by some CR’s and therefore are mentioned here.
Invoking Change Management when Implemeting Requirements
Whenever we implement anything in the world we change the world. This may be a good change or a bad one, but we cannot implement
anything without changing the big picture. Keeping this idea in mind, we should ask some questions before starting any implementation. Notice here the questions are all closely related to change management . Have a closer look into that by reading the Q-Coursebook by Bob Legrand , or any other literature recommended. Thus we realize that each request for any kind of implementing anything is always a change request. The Bugfix, as well as the new feature, the performance improvement as well as the new hardware are all change requests. Lets have a look at the things that change and which iterations we should think about when planning to implement anything.
What Do We Change
Imagine you get a requirement to add a form to the CRM system your company uses for 4 years. First you say, “Hey, that’s no big deal, a form, 5 or 6 new items in a table in the database, and a new entry in the help system.” But be careful! You implement changes in the following systems:
- the CRM system itself
- the data hold by the CRM system
- all programs that deliver or get data from the CRM system could be affected
- the testing frameworks, testssenarios, test scripts etc.
- system design sheets
- help system and documentation
When having a look across the systems borders:
- process descriptions of all processes directly and indirectly connected to this part of the system
- the processes of data input and output that directly connect to the system
- the cost model of the company changes (very little, thus nobody cares about, but many small changes sum up to be big money in the next balance.
- help desk needs to be informed
- the new version has to be tested and possibly corrected, newly versioned and distributed
What to Look At
Thus we see a principle. When a requirement is requested, we need to have a look at it to estimate the changes teamed up with the single requirement:
Have a look at the technical side of the product. Where are the changes to be applied to implement the actual feature from the technical point of view? Does it affect the architecture of the system? Does it require new hardware? What will happen with the data base model? How are data touched that are already in the system?
Have a look at the process side of the product. Here we get questions about the handling of the new feature. How to use it? Does everybody know how the feature works when he or she is involved in using this new feature? Are changes in the defined processes required when the feature is applied completely? Does the new feature really come up with a process improvement?
Have a look at the organizational side of the product. Here we get into business matters far away from technical thoughts. How much does this feature cost? What do we write in our COBIT report? How about SOX compliance? Does it affect Corporate Governance? How to get the organizational framework to build that feature and what else is required to enable us implementing that feature? Who pays, what does he pay for, and is it profitable for him?
As we have seen in this poor approach many facts can have an influence on the implementation decision that should be done carefully, thus preventing us from many problems occurring later on e.g. when having a revision and suddenly being confronted with questions about the return on investment the implemented feature gave the company or we try to find out the reason for a change request and don’t find one because there is none or it is a purely political decision. If so – make a note into the project documentation! Many other subjects rely on risk management and therefore they are given to the risk management process that returns a decision meaning build or don’t build.
This post is part of the series: Implementing Functional Requirements in IT
Implementing functional requirements in IT is very wide spread in its details. This series shows some of the Decisions we have to find, some ideas we have to deal with to avoid mistakes, underestimation of costs and to ensure good quality, low costs and perfect timing.
