Different Requirements Demand Different Implementations

In the first part we have seen that there is a need to ensure good quality in the requirements engineering even when dealing with internal

requests in an IT department. Now we should pay some attention to the implementation itself.

Different kinds of requirements demand for different kinds of implementations

The requirements an IT department has to fulfill depend on many different parameters. It seems to be a good idea to reduce this complex problem down to only two dimensions:

1. size of the company and its IT department
2. kind of the requirement that has to be implemented

Some more dimensions should be addressed in a serious consulting project. Because depending on the conditions we have to go very different ways.

A small company normally has an IT department that deals with:

• administration of the network
• web based problems like maintaining the web site
• managing the inclusion of external partners, co workers, suppliers and possibly the customers

In addition they have to deal with the engineering environments and services that often lack in good process definitions like ITIL or PCI DSS. Application development is normally outsourced because of the costs of employees, and the required developer environments.

Thus the normal request for the implementation of any requirement in a small company has to be examined with respect to the capacity of the IT department, and its skills as well as the process definition they have to fulfill.

In a large company things may be different. If they have enough power to employ enough staff to have a developer pool, they may do a lot of maintenance and development of new software. In this case the IT department is the backbone of the infrastructure of the company. But even such environments have to examine the profitability of their own development. Sometimes there are SLA’s which ensures that the company outsources all development work as well as maintenance. Sometimes these tasks are a distributed to the IT team in the company, and the service or developer team at the outsourcing partner. Thus, the question for implementing a requirement is answered by having a closer look into the SLA’s of the system we want to modify.

On the organizational basis we have to do the make – or – buy decision. Do we solve the problem another department asks for by our own staff or do we manage outsourcing as a better way. In PRINCE- lead projects (like in other methods, too) we use two parameters to find a good decision: profitability and risk- where risk analysis is a special approach that still is not easy. We have to manage:

• project risks
• product risks
• internal risks
• external risks
• and many more

Different questions ask for different answers. Thus a request for implementing a new hardware on the desk is managed differently from a requirement like “add a form to our CRM system”. In the first case we have a classic of a service task for the infrastructure team. In the second case we deal with expensive product change management .

Change management is one of the most difficult approaches a project manager has to deal with. The main reason for this circumstance is the complexity of modern products that always provides interactions, transitional effects and strange behavior whenever we change only a small part of a large system. Thus one of the first steps before starting technological approaches as described in the first part of this article, we need to make sure, that we can estimate the risk of changing anything.

Implementation of requirements always changes many layers of almost anything. This will be the subject of the next part of this article.