Today, the business community has quite a lot of authority and influence on the implementation of information solutions. Although, this influence is mainly exercised in the context of projects, it goes well beyond as well. The involvement of the business community is essential. The questions are what effects does this influence has on the final IT implementation and if the present way of working is beneficial.
Is there a relation between the influence of the business on IT projects, the present way of working and the fact that IT departments struggle to deliver and to satisfy the business ?
Let’s take a closer look at the course of events happening from the very origin of information needs to their resolution and even beyond. The picture that is drawn describe a typical evolution of the situation.
The present common approach of software development and the inefficiencies:
(click on the picture to enlarge)
1. Detection of information needs
Quite often information needs reveal themselves through symptoms and consequences. Presently, the business community is the first party to notice or to experience them.
Symptoms may first not be recognised. Some symptoms require an experienced eye to be noticed. On the other hand, consequences having an adverse effect on the business, are much easier to be noticed. Unfortunately, those consequences may be interpret as a problem. Then, the real problem may continue to remain hidden. Business people facing the consequences may individually try to solve them. Each one may look for his own solution. Then people start to complain. The issues are discussed among colleagues. Some colleagues may start to adopt a common solution. Since the problem is identified as more important, a business person with some technological skills may find it worth to try to build an ad hoc solution. Since it is not his main competence, the solution may have serious weaknesses. Sometimes it may work. Sometimes it may work only for a while. It may also create new issues. The more the business community uses such non-solutions, the more time it will take before the real problem is addressed with a well-thought solution.
As the problem is apparently solved, it will take some more time before the business community becomes conscious of the existence of the real need.
Recognising the presence of an issue is not the same as identifying the issue or as understanding the issue. One can know that something is wrong without being able to pinpoint the real problem.
2. Officially admitting the existence of information needs
As difficulties persist, the issue can be formally recognised and put as an item on the agenda. The issue is officially discussed. Meanwhile more time passes and no decision is taken yet.
The problem continues to impact the business and, over time, even to grow. Non-solutions are still in use and may even proliferate. The business community feels responsible about the issue. They want to do something about it. But they also feel not confident in how to solve the issue, in how to give it a decent solution. This is normal since conceiving information solutions is not their area of expertise. Finally, because of the urgency, a decision is taken. The business community must formulate a demand to the IT department.
Other information needs may be generated by plans. But since, the business community may focus their attention and effort to other aspects more related to business activities, information needs may be discovered only late in the execution of the plans.
3. Elaboration of the business demand
A business subject matter expert formulates the demand. Different actors from the business community must agree with its content. More time passes. This demand should express a need. Often, it doesn’t. Instead, it describes the solution that is assumed to solve the need. To do so, the business community has conceived the future solution. This can be through the construction of a mental picture of the solution.
Although it is undisputable that the subject matter expert knows the business, he/she lacks some essential competencies. The business community has developed competencies needed to perform business activities. Competencies in analysis and in designing information solutions are not needed to perform business activities. They haven’t been developed. He/she may work with a wrong mental picture of IT in mind. (see post “CIT’s Problem 2: Business Mental Picture and Reference Framework”). The business experts may be under pressure to formulate the demand. He/she doesn’t have time to reflect more deeply on the problem and its solution. Moreover, the business subject matter doesn’t know what the IT department and the project team need to know to (possibly) conceive and build the solution.
Because of the lack of decent analysis, there are still plenty of unknowns. But, the business community cannot deliver a demand that is incomplete, can they? The business subject matter expert makes choices. These choices aren’t based on expertise in information system design. They might be based on what he/she feels is the best solution or on simple preferences. If during the project, or even later, it turns out to be wrong, change requests can be formulated. The IT guys will have to adapt their software. Software can always be adapted. The commitment of the business community on their demand will be only very temporarily. The business demand is thus questionable. (Cfr: post “Do You Rely on the Demand and Requirements from the Business Community?”)
4. Submitting the business demand to the IT department
This demand is submitted to the IT department. So far, the business community did not think too much about the time needed by the IT department to build a solution. This point pops up now. The time and resources needed to build the requested solution is one of the first concerns of the IT department.
5. Planning the project
The IT department has already different projects on-going. Its people works already under pressure. The It department has to see how it fits into their planning. Maybe within M months they have enough free resources to start the project, at least, if other projects do deliver on time. Or, they may hire external people and then they can start earlier.
The IT people estimate the size of the demanded project, based on the business demand. They estimate it to X man/months, Y months of project lead time, and a cost of Z. Because of the distorted image non-IT people (and even IT people) do have of IT (see post “CIT’s Problem 2: Business Mental Picture and Reference Framework”), they can’t understand why it would take so long. If they would have to do it with their tools (eg with programmable environments and macro’s), they would do it much faster.
Much time have already passed (the word “wasted” won’t be used yet). Meanwhile they suffered from the information need. Now, their patience is up. The business community needs it urgently. The business community is the sponsor of the project. They are the client. It must be delivered as soon as possible. The pressure is maximal.
The time and budget are cut by half. They are agreed to be X/2, Y/2 and Z/2. But IT people may be rather optimistic and confident in their skills. The actual estimation may well have been 2xX, 2xY and 2xZ.
Since the project is urgent, the decision is taken to start the project and to execute it in parallel with other projects. IT people will have to work on different projects simultaneously. Multitasking is certainly not an efficient way of working.
6. Relying on the business demand
The analysts, architects and software designers work under pressure. The business community formulated a demand. They expect the IT department to build what’s in the demand and nothing else. Thus, they will get what they asked for. At least, the IT project will try to build and deliver this.
Putting the demand of the business community in question means more work and additional time. The project team has no time whatsoever and nobody expects it to do so. Consequently, if the demand is based on a wrong insight of the real need and of the situation or not very well-thought, the delivered product won’t solve the information need and/or may create new problems. Delivering the described solution is the objective imposed by the business community.
7. Project progresses. Maturing Ideas. Changes ahead.
As the project progresses, the project team must go into greater detail. Unclear aspects must be clarified. More decisions, postponed so far, must be taken and additional answers must be given. At the same time, the insight in the situation and in the needs increases. Ideas become more mature. New ideas come up. As a result, the scope and requirements may change. They change not because the environment or the objective changed, but only because the situation is more clear and the understanding improved. New features are demanded. These changes make the project’s estimations of resources, time and cost worthless. They must be reviewed. It also means a lot of rework for the project team.
A request that, for the business appears as being simple, eg allowing multiple users to work simultaneously or changing the data structure, may have a huge impact on the system. The business community can’t evaluate the impact on projects, neither in terms of changes and side effects, nor in terms of work volume.
Design decisions made on the early requirements may become invalid. And it may even happen that the architecture or the chosen technologies become unsuitable. Changing one of them means throwing nearly all the work that has been done so far away and restart from scratch. Ultimately, delays and cost may skyrocketing.
If the business community keeps on changing its mind, the project may become a never ending story. It provides work to the IT department but without delivering a result.
The business community may adopt the philosophy of trial and error, of doing what they like or what they think is needed, of following their preference without a lot of thinking beforehand, of experimenting, of exploring and of discovering. They can decide something, try it, and if it doesn’t suit they will change the decision. This approach doesn’t require any commitment. But this is definitely not an efficient or effective approach in corporate IT.
From the test phase on, the solution is available to some business people. User Acceptance Tests (UAT) are meant to see whether the solution matches the demand. But tests are for the business stakeholders also a way to verify and to experience if it is what they needed. Although the product of the project may passes the UAT, the business may become aware of some mismatches. New change requests may be formulated. Once the solution is operational, they can verify whether the solution fits into the operational environment. In fact, to some degree, they use a finished product as a prototype, as a proof of concept. This is also a very inefficient, very costly and very risky way of working. Let’s send some of our astronauts into space to see if our rocket works.
Needs and issues are detected late. A lot of time is wasted before the IT department receives the business demand. This demand is unreliable. It is only assumed that the solution described in the demand will solve the problem and not create new ones. The commitment of the business community is inexistent or, if it would exist, it would be unjustified. The IT department has to work under immense pressure and in less than optimal conditions. It lacks of resources. The IT projects need some stability and some facts they can rely on. They don't have them. The project is actually used to explore the needs, the issues, the context and the solution.
It is very unlikely that the IT department can ever deliver a decent quality It implementation.
And it is also unlikely that simply building what they described in each of their demand will ever satisfy the business community.
We need to rethink the relationship and the whole process.
Post “CIT 5.2” provides some additional insight in about the position of the IT department within the approach described above.