Without a methodical foundation for the planned operation of a new system, the CRP will tend to wander aimlessly and will be subject to manipulation by vendors or others with a different agenda. If requirements are defined already -- great. However, my experience is that most companies claiming to have this complete have done a superficial or incorrect job. Don't dive into the software before this important homework is done first!

It’s imperative to know where you’re going and where you’re coming from when embarking on the perilous journey of major system change. The as-is and to-be systems definition approach can only be shortcutted so much before running into trouble. While we don’t think that an existing system, if it’s to be replaced, should be exhaustively and elaborately documented, it is necessary to understand how it operates and what issues and problems exist. Following that, a more detailed and comprehensive first cut “to-be” definition should be created. It may be successively refined as the program moves forward.

Experience has shown that most initial system documentation efforts do not reflect the actual richness, complexity, ambiguity and diversity of the real system operation. People usually assume that the current system is logical and rational, but it isn’t always so. First pass analyses often appear “single threaded”, in that they show what would happen if everything went right. In real life, there are many, many exceptions, requiring complex branching and alternative activities. To make matters worse, not everyone handles things the same in all cases. In fact, there is usually a good deal of ambiguity and even blind alleys in most de facto systems. MRB, customer returns and outside processing are good examples of this in most companies.

Conventional development and documentation tools are often not used in a way that deals with the above effectively. To better deal with these problems we have used the “living flow chart” method with a fairly high degree of success for some time. Instead of documenting systems in boring, complex diagrams that get hidden away in books, try this:

Employ systems users/project team members, not systems professionals, to construct the charts. Use the systems people as facilitators. Why?

• Instills user ownership.
• Users know better "where the bodies are buried."

Project management and systems people are often real nervous about doing this because users often come up with a poor analysis, unrealistic requirements, or worse yet, attempt to automate the status quo.

How to avoid these pitfalls

• First, provide education in modern systems approaches and provide a thorough grounding in the applications to be studied. Set up well qualified and well balanced teams. Expose people to methods used by more successful companies, but allow for differences, making sure that they don't claim that "it won't work here because we're aerospace" or some similar nonsense. Next, carefully explain how you want the documentation done.