Success!
The system is in the hands of the client and it is processing real
business information. Time for a project team celebration! Pats on the back all
around for everyone. High minded speeches from team leaders, project sponsors,
and various excited client participants. No more late nights, weekends, or early
mornings. The effort was long and seemingly endless but it was all worth it. The
sense of achievement experienced from the solution of a complex business problem
by the installation of a new system is indescribable. A number of years and a
large number of people may have been involved. The time has come to celebrate
the team's victory!
But is it always this way? Another team is exhausted. The death march is
finally over. They will never have to see each other again. Boxes and logon IDs
can't be turned in quickly enough. All references to real names are removed from
programs. "Don't call me when this thing blows up", is muttered now and then. No
team gathering is held, just a slow disbanding as each team member disappears
onto other projects or activities. The clients seem disenchanted. An air of
uncertainty and impending difficulty surrounds the system and those associated
with it...
Or, the worst fate. A surprise meeting! The team has been progressing, but
somewhat without direction. The budget is slipping, the client is unsure what is
happening, and questions are raised about competence. No one team member can be
identified who has a "vision" of the system or the system building process. The
inevitable happens, the project is cancelled. The money spent to date was
absolutely, totally wasted!
Why do some teams seem to make to the end successfully, other teams just make
it to the end, and others never get the chance? Why are some teams on a
continual "high" throughout the project while the members of a team right across
the hall seem to drag into work every morning? Why is it that some clients
describe a team with words like:
- they understand my business
- they are right on target
- we are all a part of the same team
- we were glad to be a part of this process?
Yet another team may be described with:
- we not sure what they are doing
- they don't understand how our business really works
- we are very worried about how this mess is really going to turn out.
Does some secret formula exist to insure success, or is it just a matter of
luck?
Recent observations which have been made by non-technical business people are
striking in their implications. One comes from Robert Townsend, the author of
Further up the Organization, in which he states that "most of the
computer technicians that you're likely to meet or hire are complicators,
not simplifiers. They're trying to make it look tough, not easy. They're
building a mystic, a priesthood, their own mumbo-jumbo ritual to keep you from
knowing what they - and you - are doing". This is disturbing commentary. It
gives a clear voice to the concerns that many clients express when the computer
professional's back is turned:
- Will I get the results I need?
- Will my business problem be comprehended?
- Will I understand both the solution as well as the process used to arrive at
the solution?
- How will I be included in the process?
- How much control will I have?
- Will I really have anything at the end to show for the risk I am
taking?
An even more disturbing observation comes from one of the acknowledged
"thought leaders" in the systems field - Ed Yourdon. In his book, Managing the
Structured Techniques, he writes:
"Something happened to the personality and mentality of the data processing
profession as a whole as we moved to the ultra-sophisticated on-line, real-time,
fourth-generation and fifth-generation machines of the 1980's and 1990's. The
profession began to attract people who, regardless of their race, creed, color,
or university degrees, are clerks. They think like clerks, talk like
clerks, and they approach computer programming and systems analysis with all the
enthusiasm of a sleepy civil service clerk who knows that he's just one year
away from retirement.Having met some twenty-five thousand analysts, designers,
and programmers throughout the world, I found a surprising number of them have
never read any computer articles or even opened a copy of
Datamation or Computerworld; have never heard of ACM, DPMA, IEEE,
ASM, or any other professional organizations; can't spell Dijkstra's name and
probably have never heard of him; aren't aware of the structured techniques and
wouldn't be interested if somebody showed them."
What makes this even more distressing, is that fact that business executives
are now turning to the IS professionals on an ever increasing rate in order to
provide them with systems which give the business a strategic as well as
a competitive advantage. The major problem here is that computer
programming clerks who are enamored with the technology and who could
care less about the business itself, will not make this happen. A new
breed of computer professional is required who has a balance of people skills,
technical skills, and business skills.
Some Required Thinking Shifts:
- Stop automating existing ways of doing business without assisting in
improving the business processes first.
- Stop thinking in terms of departmental processing.
- Start thinking in terms of cross-organizational systems and business
clients.
- Start adjusting to the fact that business processes are changing at an ever
increasing rate, and the development team must be prepared to keep up - even as
a system is being designed and constructed.
- Start embracing new forms of technology which show significant cost savings
potential.
- Start recognizing that if the business client's demands can't be met by you,
countless other service providers exist who will be willing to meet those needs.
In today's information based society, the system building professional
is faced with even greater challenges than ever before. Exploding technological
innovation, relentless complexity increases, faster paced business changes, and
increasingly sophisticated business clients are placing greater demands on the
talents on the business system professional. In addition, a true spirit of trust
and teamwork must exist and perpetuate between the business clients and the
business systems professionals. This is the first real quest. The next is even
more critical. In the end, a business system must be delivered. A system
provides no benefit to anyone unless it is in an accepted technical environment
and actually being utilized by the business.
That is the creed of this white paper. All of the analysis and design, or the
blood, sweat, and tears, won't amount to anything if a working system does not
exist in the end as a result of the effort.
