Handling Different Requirements - Maintenance, Service, Development, and Bug Fixing

Handling Different Requirements - Maintenance, Service, Development, and Bug Fixing
Page content

Maintenance Service Development: Bug Fixing

When there is a requirement that demands pure maintenance, this is normally done by using ITIL processes. Almost any service related task

is described there. Make sure to balance the whole ITIL wheel to ensure a balance of service delivery and service support! When doing one task out of the ITIL wheel or cycle, you do two things:

  • you decrease resources
  • increase the outcome to the customer no matter if he is in your company your IT department is in or you are in a service providing agency

Each process output depends on the usage of resources. What does this mean for project managers? Well, a project manager may ask how to organize the implementation process. In this case, he needs to know the resources he has, and he must know the income that comes back (money, other services, other resources).

If you can ensure that equilibrium of input and output, possibly with a benefit for all stakeholders, your maintanance requirement will be fine. But, ITIL is not always available to do it. Remember, that there are other ways to get the same results. A good process ensures good products in development as well as in maintenance. Some ideas are reviews, best practice collections, continuous trainings of the staff, continuous process improvements and observation of the requirements coming in over the time. The actual request is always a sign for other possible requests. Keep in mind to, always ask when implementing the actual maintenance task, “if there could be any other part, any other problem depending on the one you actually solve, you should pay attention to?”

The difference of standard service delivery tasks such as help desk and standard financial management on one hand, and pure maintained tasks like repairing a piece of hardware or planned exchange of hard discs in the server blades is small. You can always use the thoughts described in the first 3 parts of this series to find out what is really needed (oftentimes completely different things than what was actually requested). Then examine if it is really necessary now, and in the demanded quality, time and budget. If profitability and risk are in an acceptable range, find a SLA and start the planning and design for implementation of the service or maintenance task. The only important difference is that services are delivered in the hope that they are never required (in the ideal case - some more academic point of view) but the maintenance tasks are mostly planned actions to ensure the product is working at its best. You cannot avoid them, only reduce or otherwise optimize.

Developement

The development of new products or parts of a product that goes beyond maintenance or service is more complex. Requirements of this kind can be done using a combination of project management modes, and technological approaches like we get to know from the project butterfly. However, the development work cannot be described in this article. Remember the thoughts from the first parts of this series, and then find a way that fits your needs. At Edditrex Ltd we mostly use the 360 Degree Software Design (I wrote a book about it in German last year, an English version will follow next August). This is pure software design on a high level, that is definitely extremely efficient, but unfortunately not easy for everybody.

Other ways are the good old waterfall defined by Royce in the 70th or the modern SCRUM method. On the project management side we use PRINCE for development. Reading books by Tom deMarco is always a great idea for everybody involved in projects of any kind.

Bug Fixing

This is something special. Bugs are distilled out of findings (see Q-Course by Bob Legrand), and can be classified in different categories that would be worth it’s own article. First, we always find a priority for this Bug. This is important to prioritize all bugs in the never ending bug report. Define the amount time the bug has to be fixed in - yesterday is the demand, but difficult sometimes. Then, find out the time you really need (and don’t forget personnel, material that are hopefully available in time referring to ITIL again). The principle to do this is simply a short version of COCOMO or an Excel sheet with some estimations. Lucky, is the project manager who has enough review material to use for this estimation. But all that is fishing in the clouds. Unfortunately there is one way best known as the “Captain Kirk Way”: “Scotty, we have a problem”, “Yes, I am still working on it”, “Scotty, how long will it take to repair it”, “Captain, it will take at least 3 weeks”, “Scotty, I need it in three days”, “Yes Captain, I will try to get it in 1 day, but I cannot promise it”. And what happens on the Enterprise? It’s fixed in less than 5 minutes. Up to Scotty’s last sentence we know the game, only the 5 minutes - solutions are unknown.

The worst thing you can suffer from is a Heisenberg Bug. Werner Karl Heisenberg, a German Physicist, is well known for his Uncertainty Principle that says, that you know either the position or the energy of a quantum particle. I must confess that his contributions to the Molecular exchange force, S - Matrix or Quantum Field Theory are much more fascinating. However, he wrote down the Uncertainty Principle that is relevant for our Heisenberg Bugs. This category of bugs behaves like quantum particles. You know where it was or what it did, but never both in the same time. Even if you know both, you don’t know if it will happen again at the same position in the same form. Chasing for Heisenberg Bugs is an art. You must decide wisely how to do this! It’s not easy because these bugs are not able to be reproduced, they can be of no matter on the customers machine and they can be the end of your project.

Reproducible findings - and therefore reproducible bugs can be found and corrected in a fairly predictable way. Fix them first, always. Sometimes the Heisenberg Bugs disappear when other bugs, or whatever kind of findings you deal with, are fixed. The better the reproducibility of a finding, the earlier it should be fixed. Such requirements are simply implemented. But never underestimate the Bugs with bad or strange reproduction behavior.

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.

  1. Implementing Functional Requirements in IT: Part 1
  2. Different Requirements Demand Different Implementations
  3. Why Managing Change is Critical to Implementation
  4. Three Examples of Implementing Functional Requirements in IT