Requirements and companies are different
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:
- size of the company and its IT department
- 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.
Implementation processes in Small and Large Companies
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
Implementation Processes for Different Problems
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.
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.