The Early Stages

It is essential that a project get off to the right start. In this section, we detail some of the methods and approaches we use at TMS to make sure this happens.

Vertical Partitioning Means 80 Percent Complete Is 80 Percent Delivered

Who begins too much accomplishes little.

German proverb

Analysis should support the design, implementation, and management processes. If you're using an incremental approach, you should be able to partition the analysis vertically to investigate part of the problem in detail and to defer looking at other areas until later. You should also be able to design and implement each partition without analyzing the other areas in detail. The business architecture will provide the context for any partition. This approach will help you judge the suitability of an application for incremental development and the potential stability of a specific partition.

Partitioning allows you to consider different parts of the problem in isolation. Vertical partitioning allows you to proceed with designing and building the application incrementally with the confidence that rework will be minimal. It also allows the business needs to drive design, build, and roll out. Once the technical foundation is in place, an incremental implementation that meets business priorities can happen. Using an object-oriented approach from analysis to coding allows this incremental implementation to occur.

The careful specification and use of business-oriented ActiveX servers will provide a vertically partitioned design. Late binding and generally decoupling increments will reduce the need for recompilation and rework. From this point of view, out-of-process servers are better than in-process ones. Maintainability should normally rank above performance, a priority you need to make clear early on. (One of the biggest criticisms about a system is often its performance because it's an aspect that is all too visible, whereas maintainability can easily be overlooked since it won't become an issue until after the initial delivery of the system is complete.) Vertical partitioning allows parallel streams of design and build to take place. This partitioning provides rapid development at low risk without increasing costs.

Cut the Politics and Get Serious

The culture acts against quality—"pass the buck" or "shoot the messenger" managers are playing politics, for example, holding back the bad news, hoping other projects will fail first….

Project review

The early stages of a project often bring into focus internal and external politics that can cause project failure. You need to cut through the politics to get the job done right. Challenge inertia and self-interest. If you want to maintain your integrity, this is better than playing politics. But it's just as unsafe. Cutting through politics requires a project manager with guts—preferably one who is financially secure!

Most projects will have some requirements that are relatively simple and don't require great user involvement to achieve. These are ideal deliverables for the early stages of a project. The team is able to demonstrate what it can achieve. The challenge is then to get the right level of user commitment to ensure the same productivity when a high level of user involvement is needed.

To achieve technical objectives, you might have to bypass IT procedures and common practice. You can often circumvent the system like this when you do it on a limited scale. To deliver major projects, however, such practices and procedures might need to be changed.

Dare to Choose Staff Who Have the Right Stuff

Everyone has talent. What is rare is the courage to follow the talent to the dark place where it leads.

Erica Jong

Those who really care about quality and want to do a good job are often considered mavericks by the organization they work for. They don't fit in, they don't play the political game, and they don't strive to move into the management hierarchy.

Staff members who argue their points, don't accept decisions at face value, and insist on doing things the right way can be difficult to manage. They can be thorns in a manager's side. They might insist on being paid more than their manager. They do build better systems, though; they build systems that are maintainable, meet business needs, and are less costly. They probably are worth more than their manager.

See the Big Picture, Plan for Change

You can observe a lot just by watching.

Berra's law

Most experienced developers have at some point felt frustrated because the applications they are maintaining or having to extract data from have not been designed for change. They have probably also experienced this frustration from the other side—frustration that they are not provided with the time or resources to develop a system that provides a flexible but sound foundation for future work.

Data from one application is often reused in multiple applications. The second and subsequent uses are often unanticipated, resulting in a range of problems. For example, data quality might be poor or new databases with gross data transformations between the new and the old databases might be required. (See Figure 15-6 for examples of bad and good data management planning.) The problems arise because the original application was not designed in the context of a corporate long-term view. Without a forward-looking view, some data is not captured and overoptimized structures are used. A business architecture provides a logical view of function and data and attempts to anticipate future needs. To design an application successfully (where success is viewed over the lifetime of the application), you must take the bigger picture into account. A well-planned application can grow organically as new requirements emerge. To plan and design solely for the current application creates problems for the future. For example, databases might not be structured flexibly to support future queries; designs might be highly optimized for a particular application but prove to be inadequate for a subsequent application or after maintenance. Producing reusable business rules and generic code tends to take a low priority if the focus is only on the current project. Designing logically, based on a high-level view of core business operations, tends to produce a reusable design that will support multiple applications at the database and code levels.

Figure 15-6 Design for the future