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.
8. Prototyping?
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.
To conclude
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.
No comments:
Post a Comment