The approach discussed in CIT’s Problem 5.1 puts the IT department into a specific position and situation. These are discussed here.
The IT department has no control over the process.
From a certain point in time, information is available (eg as plan, objective, mismatch between objective and operational results, complains, operational data, ..) or symptoms or consequences (tendencies, behaviour, problems) can be noticed. The issue can be detected. From this point in time until the submission of the demand, the business community can act. The detect the issue early and act promptly or they can stretch this period. The IT department is completely absent in this phase.
What determines the order or timing of the demands? Unknown issues can’t be solved. The issue must be detected. It is, in essence, this detection that is the trigger. But the detection happens by coincidence. The timing and the order of detection of need is completely anarchic. This order and timing can be adjusted by the moment some critical decisions are taken and by the priorities the business assigns to the issues. The metaphor of constructing a house can be used here. This future house owner asks to build first the roof because it is raining. Then when he needs to cook, he feels hungry and needs to cook. He needs a kitchen. So he asks to build a kitchen. And so on. Houses aren’t build like that, neither are information solutions.
Piecemeal built enterprise IT solution
The demands can be triggered by information needs, by operational issues or by ideas of improvements. These demands are not planned. By responding to these demands, in fact the enterprise IT solution is built by solving one need or problem after another. It is conceived and build piecemeal. It leads to a patchwork of individual and local solutions (may create the need for EAI-solutions). Once built, the local solution is integrated into the whole. Or, if it isn’t possible, it is connected to other existing parts. It is a post-design integration, instead of an integration by design. It is like constructing a building room after room without having any idea of how many rooms and floors will be needed, of how the building has to look like when it will be finished or even of the intended size and purpose of the building. After a while, when many room are built, one can infer what the final solution will look like. The solution grew from the start by adding components and continuous transformation. It has never been engineered as a whole system. Then, it might be a good idea to engineer it to increase its qualities.
The IT department runs after the facts
The whole approach reactive since its philosophy based on a response to a demand.
The existence of an issue or need emanating from the operational level is (mostly) required to solve it. The issue must exist to be detected and before taking actions. This is late. The issue exists already and hinders the business. They can’t or are seldom anticipated. This creates a pressure and makes the solution systematically to come late.
The situation is different for needs generated by a changing environment of the business (outside the company) or by the strategy and other plans of the business. The business community may be direct its attention to what they are in charge of, to those aspects they know and to the activities they will have to perform to execute the strategy. Information needs are not really of their responsibility. They may not pay attention at the future information needs. They have no clue of the impact and time needed to solve them. Moreover, the change must first be clarified and solved at the business level before being able to define the exact information need. (This idea is not completely true.)
A demand is submitted for a need that will materialises within 5 months. But developing a solution in decent conditions takes 9 months. The demand has been submitted too late. The demand should be submitted early enough to give to the IT project that amount of time estimated by IT experts needed to execute the project.
In both cases, the IT department responds to the demands from the business community. The degree of reaction versus planned work depends from organisation to organisation.
The IT department is fully dependent of the business community
Projects are based on the business demands. The project team tries to deliver what has been asked by the business. This approach creates an important dependency in time and content. It makes the IT department dependent from the business community for an important part of its activities. The business value, the quality and the impact on the business of the solution produced by the It department are directly dependent of the quality of the demand and other information delivered by the business community.
Also beyond the demand, the business community provides the main input to the project team.
The business community may filter information and demand.
They may want to start with a simple and small solution or they may consider to consider only the main case. Once this is build, they may decide to let the solution grow by adding new requirements or features to the original demand.
What can be filtered:· Features and requirements of lower priority
· Aspects that are not clear yet to them
· Parts that are more complex
· Requirements that appears only as an extension of already formulated requirements
· Lesser frequent cases and exceptions
· Alternative paths
A few examples:
- We may start with requiring a raw text report. Later, requirements can be added to have pictures, configurable data on the report, configurable page layout and paging features.
- The requirements may state to have a single-user system. Once this proved to work, the client may ask to make it multi-user or an access from anywhere through the web can be requested.
The business subject matter expert may belief some information is not important and keep these details for later. This filtered information may in the end be very important for the design of the solution or for the choice of technologies.
The danger of filtering is that it is done without consideration for the consequences on the way information systems are or should be built, on the impact on the conception of the solution.
The IT department is last link of the chain
The whole conception of an information solution is a process. But, and particularly with the present approach, it can be considered as a chain. The first link consists of the issue itself. This can be the publication of new legal requirement, symptoms and consequences of an operational issue, the idea of an improvement, and so on. This information must be noticed and considered by the business community. The business community is the next link. Then information is transferred to the IT department. They are the last link. In this arrangement, the It department, as being the last link, always lags behind. This is not favourable to “solve” the business-IT alignment challenge.
The IT department is the slowest chain
The business domain is (usually) a world at the level of the human. On the other hand, the IT people often work at a very detailed and abstract level. Since computers can’t interpret and decide by themselves, a huge part of the work is very formalised. It should be complete and logically consistent. A change at the business level can be expressed by changing a single word, adapting the formulation of a phrase or paragraph or adding one. If an IT solution must be adapted to such a “minor” change, this may mean work from a few minutes to ultimately months or even years.
Conceiving information systems is a labour intensive work. But it can’t be done well when changes arrive at pace they can’t keep up with.
Many smaller changes may keep the business healthy. As they imply a lot of work to adapt the IT systems and as these adaptation are preformed under pressure, the changes are implemented with as single goal, to have things functioning as expected. The many changes implemented with this objective as norm, weakens the system. Over time, it makes a mess of the IT implementation.
There are techniques to allow a greater flexibility. Some (not any) changes can then be implemented more swiftly. Nevertheless, the IT department is a very slow component in the company.
This means that it may be easier, or at least it requires lesser resource to implement a change on the business side than to implement the change in IT. Too many changes imposed on IT will increase the pressure in this department.
The present approach creates a lot of obstacles for the IT department to deliver.