Focus Area: Project Management for Systems Development

Author: Russ Finney

Year: 2003

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 finalized.

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:

1. Most of the details are floating around in people's heads just waiting to be written down.
2. Once the details are on paper they can be reviewed by the other team members and the business clients.
3. A consistent approach to common situations will begin to emerge.
4. New people can be brought in during construction with greater ease if the details are documented and available.
5. It is psychologically relieving to the analysts not to have to carry large amounts of complex detailed information around in their heads.
6. Problem areas, inaccuracies, incomplete analysis, and bad assumptions will be discovered for resolution now, rather than when they could become project sinkers.
7. 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 below:

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 specification tasks.
• Establish the specification walk-thru approach which will be utilized by the team throughout the technical design process, before the first specification is even written.
• 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.