Lawerence D. Bell once remarked, "show me a man who cannot bother to do
little things and I'll show you a man who cannot be trusted to do big things".
During the technical design phase details are important and cannot be taken for
granted. No loose ends should exist when the system programming begins. Joel
Ross and Michael Kampi in a recent book, Corporate Management in Crisis: Why the
Mighty Fall, stated their belief that "attention to details is not nitpicking
but an essential and vital part of successful management". This is an important
message for the system builder. Paying attention to details is not an easy job,
it takes discipline as well as tact. The project team must keep a keen focus on
the details during the upcoming design process.
Up to this point everything has been pure speculation. A solid "vision"
describing what the system will do, and what the major components will look
like, is in place. A vast gap remains, however, between this "vision" and the
actual technical realities of implementation. Bridging this gap is Technical
Design. This phase focuses completely on making the system a reality. By the
completion of the phase, no detailed questions should remain about how a screen
will operate, or where information will come from on a report, or how a program
will perform required calculations, or any of great number of other detailed
issues. The completion of Technical Design means that every individual system
component has been completely thought through, documented, reviewed, and
Many a project manager has suffered the fate of placing his or her success
into the hands of the promised "experienced" programmer or the "intelligent"
code generator. The temptation is to leave the details until later in order to
gain time within the phase. But then the unexpected happens, construction
begins, and a key analyst leaves the project, or programmers are assigned who
don't understand the technology or the required functionality. Not only are
extraordinary amounts of time necessary to stay on top of the construction
effort, but the possibility of key requirements being overlooked just increased
dramatically! This situation, while it can be overcome in some cases, is all to
often the cause of a system disaster in a great many others.
Why capture the details now?
Here are seven good reasons:
- Most of the details are floating around in people's heads just waiting to be
- Once the details are on paper they can be reviewed by the other team members
and the business clients.
- A consistent approach to common situations will begin to emerge.
- New people can be brought in during construction with greater ease if the
details are documented and available.
- It is psychologically relieving to the analysts not to have to carry large
amounts of complex detailed information around in their heads.
- Problem areas, inaccuracies, incomplete analysis, and bad assumptions will
be discovered for resolution now, rather than when they could become project
- A sense of completeness is experienced by the team when all of the details
are complete, documented, organized, and accessible.
This is the Fun Part: Creativeness Counts!
Generally, during the design process, creative ideas tend to come in two
forms. The first is as a completely new and original approach to a technical or
a business problem. The second is as a variation of a familiar approach, with a
slight degree of enhancement to give the idea a fresh new "twist". In either
case, the technical designers are primarily concerned with developing creative
solutions to support complex business requirements.
In order for this effort to result in the highest quality system possible,
the sensible reuse of pre-developed modules (or "classes"), the creation of
innovative program designs, and the development of advanced algorithmetic
routines, should be encouraged throughout the design process. This "creative
thinking" stimulates the team through intellectual challenge, and it encourages
technical "breakthrough" solutions to the especially thorny situations. This
aspect of the development process tends to be one which system builders thrive
on! (Even though quite a few grumble about having to "think" so deeply and
intensely - secretly, they wouldn't have it any other way).
Sometimes, new ideas appear which are merely cloaked forms of old, trusted,
well-used approaches. It may be a routine to control a cursor position, or a
highly efficient database call, or an extremely fast algorithm, all of which may
have already been completely thought through during a prior project. The system
builder should not hesitate to reach into this "grab bag" of past designs for
proven innovative ideas. After all, as playright Gene Fowler liked to remark,
"if they haven't heard it before, its original!" This reduces the team drift
toward creativeness for the sake of creativeness, and it keeps the precious,
inventive focus on the areas which truly require unique, specialized solutions.
The Precedent Sets the Principle
Benjamin Disraeli, in a 1848 speech to the British House of Commons, once
exclaimed, "A precedent embalms a principle!" This warning should have a special
meaning to the system builder who is striving for a consistent design.
Set the program specification level of detail expectations as early in the
technical design process as possible. The designers want to know before they
begin how far they need to take their specifications. They are only willing to
take them to the level of detail which makes sense for the situation at hand.
Any further they will consider a waste of time.
Some "rules of thumb" for appropriate level of detail determination are list
High Level of Detail Situations:
- Hand coded third generation language programming
- Complex database access statements
Moderate Level of Detail Situations:
- Hand coded fourth generation language programming
- Action diagrams already provided
- Straightforward database access
Low Level of Detail Situations:
- Code generation using a screen/database/report painter
In addition, the following tips should be followed in order to encourage the
correct design depth during this phase of the project:
- Set up clear and reasonable milestone dates for each of the assigned program
- Establish the specification walk-thru approach which will be utilized by the
team throughout the technical design process, before the first specification is
- Complete a first draft of the programming standards which will be followed
during system construction, in order to make sure that the technical
specifications are initially in line with the anticipated programming approach.