Information Technology Reference
In-Depth Information
communication, development, project management, testing, material
acquisition, accounting, and others. All these processes are planned expen-
ditures of energy to restore the system to equilibrium. If projects are failing
in one's own organization, look at the processes at work — one may not
have enough of them to begin with or not have the right ones for one's
requirements.
Developing Good Processes
Most software companies do something well that makes them survive and
thrive as a business. It can be safely assumed that underlying this success
are good business and technical processes. These processes often are not
captured and encapsulated formally. In fact, such smooth functioning may
lead one to believe that one “does not need a process.” However, one
should look at it differently. If things are working well, there must be
some good process, perhaps unidentified. Management must extract such
processes and think of them as a valuable intellectual property, no less
important than the technical processes used for manufacturing.
The converse of such an approach is also important. Some companies
pick a process that might not have really worked too well in the past,
and formalize it, just because they are familiar with it. Before concretizing
(or automating) an existing method of working, one should review it for
its soundness and applicability. One of the reasons why many software
implementation projects fail is because existing manual processes are
automated without such analysis. There is no value in simply investing
in a bad process to make it go faster — it will still be a bad process. As
Drucker (1986) says, “There is nothing more useless than to do efficiently
that which shouldn't be done at all.”
Understanding the Process Environment
There are a number of factors that one should consider when designing
or selecting a process to use (Figure 8.1). These include:
The maturity level of the client organization
. Some organizations
may not be ready to use certain processes because they require a
degree of understanding and sophistication that the organization
has not developed. For example, release processes defined for
corporates such as Microsoft or SAP may not be suitable for start-
ups.
. A process that is in place but
is ignored by all sends the wrong message and undermines the
The enforceability of the processes
