Visual Basic —

Cut the Politics and Get Serious

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

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

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