Risk Management

I don't want the cheese, I just want to get out of the trap.

Spanish proverb

Risk is multidimensional, involving business, technical, and people risks that must be managed within the context of the development project's architecture, analysis, design, and implementation phases. (See Figure 15-1.) These risks affect the whole project life cycle. In this section, we'll focus on the technical risks that the introduction of Visual Basic 6 brings.

Figure 15-1 Risk management is central to successful system development

Traditionally, project managers have three major objectives: deliver on time, stick to budget, and create a system that fits its intended purpose. To manage the risks inherent in Visual Basic 6 distributed development, project managers must be aware of business needs, be technically competent and customer focused, and be great team leaders. This kind of development—with its integration of differing, fast-changing components and technologies—has such a high level of risk that some might say only the foolhardy would attempt it! Given such extreme risks, a risk-management strategy is fundamental to successful delivery.

A key factor in heading off problems is moving the technical risks to the beginning of a large project and handling them there. Often, major risks are not addressed until the system test or live running—settings in which the costs of rework or failure are substantially higher. Dealing with the risks early provides a forum for discussing how the project will work and allows broader issues to be addressed. Think of this early technical review as a form of insurance.

Some crucial issues need to be addressed in managing risk: the technical infrastructure, the business environment, and change management.

Technical Infrastructure

Historically, in the mainframe world, we have seen relatively slow evolution of the technical infrastructure and long project-delivery times. This slower pace allowed developers to implement a technical strategy that used a proven technical infrastructure for major system components. The same sort of infrastructure must be established to develop robust systems in Visual Basic 6. Visual Basic 6 Enterprise Edition provides the opportunity for a powerful and flexible development environment, but only if this flexibility is designed into the project. It will be a hefty investment to get it right, and a very expensive mistake to get it wrong.

The technical infrastructure includes the hardware, the network, the operating systems, and the tools. All the elements of the infrastructure interact and are constantly changing. This interaction and change is one of the biggest risks. You must work out a method for developing successful systems in this environment.

Visual Basic has recently gone through three releases (4, 5, and 6), all with order-of-magnitude changes in complexity that require very different approaches to development. We've seen Microsoft Windows 95/98, Microsoft Windows NT, and the Internet change the operating environment. Distributed objects and open host operating systems are a reality. Hardware continues to become faster and less expensive. Utility packages such as word processors and spreadsheets have become development tools. The legacy environment, together with these and other tools, forms an ever-changing development infrastructure.

You must be sure of the robustness and performance of the infrastructure under the stresses of live running. If the infrastructure is not proven, then prove it! And keep on proving it!

Business Environment

The business world that our systems support is generally becoming more volatile and is demanding new systems of greater complexity in shorter time frames. We need to develop systems in the context of a corporate business systems architecture that allows rapidly developed systems to integrate and form a basis for future change and development. Systems such as this will help us manage the problems that occur when rapid development approaches are applied to large projects.

Change Management

The more innocuous the modification appears to be, the further its influence will extend and the more plans will have to be redrawn.

Second Law of Revision

You need to anticipate technical and business changes. Databases grow and need restructuring, and underlying system software changes. You should build applications with an architecture that can accommodate change.

Small, simple applications that deliver benefits quickly are preferable to monolithic applications, but the combination of small and very large applications should also provide the same benefit. You need to anticipate the growth of applications—organic growth is natural in successful applications, and you should allow for it.