Critical Factors in Successful Enterprise Development

Unfortunately, we can offer no formula you can follow that will guarantee the success of your enterprise development. You can greatly improve your odds of succeeding, however, if you adhere to some guidelines as you proceed through the development process. We've discovered, often the hard way, that certain factors are critical to successful enterprise developments.

Insist on Great Project Management

Misfortunes always come in by a door that has been left open for them.

Anonymous

Effective project management is critical to the success of Visual Basic development projects. Strong project management can lead to success even in difficult circumstances. Weak project management can result in failure when success is there for the taking. In the Visual Basic world, many good project managers seem to have mentally wandered off, neglecting their professional responsibilities. The most basic disciplines such as planning, phasing, tracking, managing change, and setting milestones all seem to have been forgotten. Project managers seem to be sucked into a way of working that in their heart-of-hearts they know is wrong—but they do it anyway. The best project managers are prepared to put their jobs on the line to do what's right. They realize that their jobs are at risk anyway. Even the best project managers will be seen to be at fault by someone no matter what the outcome of the project, so why not do the job the right way from the start? It is essential that proper, disciplined project management occur within every Visual Basic 6 team.

Visual Basic project managers are typically not technical enough. Project managers cannot lead effectively unless they have credibility within the team and are able to discuss critical design issues. Many of the project managers we speak to don't know, for example, what system resources are, or what MDI is—even though their team is being forced to code a complex finite state machine as a result of the interface style being chosen.

When we ask a project manager why a substandard Visual Basic application has been released, we normally hear something along the lines of, "The business demanded it quickly," "Our competitors have one, so we had to have one," "We'll use it now and fix it later," "The users expect it now," or "The users are already using it, so we can't withdraw it." The poor management of user expectations and requirements is to blame for much of Visual Basic's bad press. All too often, a manager will allow a program to go live because he or she has failed to adequately manage the expectations of the users (or perhaps of the senior managers).

Visual Basic 6 offers the opportunity to produce component-based solutions. Managing a project of clients and servers in which you do parallel development by using a defined interface (building stubs and then filling them with real functionality) works up to a point; the difficulty comes on the human side. Parallel development requires a high degree of flexibility and interaction from all members of the team. Developers—especially inexperienced ones—or people who haven't been on a team before find the personal-contract nature of this type of development difficult and would prefer to be told what to do in what order and by what date rather than to make personal, flexible "contracts" with team members. The only way to pull off a parallel development project is by using the following ingredients:

• A great deal of project management effort (micromanaging)

• A highly cooperative, established team

• Long lags and leads

The difficulties compound because of the tendency to fiddle (and think you can) with declared object interfaces after they are defined.

On the technical front, beware of technical customers—they'll continually want to revisit the design without ever recognizing the impact of this dabbling on the project. Also, even with small teams, on a highly technical project in which people take responsibility for certain areas, the project manager will have trouble keeping on top of the day-to-day technical details. The best way for the project manager to keep track of the details is to delegate responsibility and require written notification (e-mail works well) of how things are progressing.

Know Why You're Taking the Risk

To do great work a man must be very idle as well as very industrious.

Samuel Butler

New, inexpensive technology provides greater access to and more uses for information. With Visual Basic 6, there is a major challenge to technical departments to deliver the technology benefits quickly. Effective development means delivering swiftly and economically so that the business can gain competitive advantage or make strategic shifts.

New technology provides businesses with new opportunities to one-up their competitors. This advantage will be short-lived because the competition will rapidly equal or better the development. This competitiveness produces even more pressure to achieve results in record time.

The same new technology provides IT departments with the challenge of learning about and using it. The pace of change, the visibility of new technology, and the need to exploit it quickly mean that system development has become very high risk. You can lower this risk by ensuring that you understand the technology.

In this context, it's vital to understand how to balance risk and benefit. Only the business managers can judge whether the benefits are worth the risks, so project managers must be able to communicate with the business managers about these issues.

Visual Basic 6 provides even more productivity tools, and tools to build productivity tools. You can reduce the risks if you invest in learning and developing wizards, add-ins, templates, and other reusable components.

Understand Where You Came From

Have the courage to act rather than react.

Earlene Larson Jenke

A traditional development environment (such as the one depicted in Figure 15-2) in a large, well-established organization has typically grown up over a period of thirty years or more. During this time, procedures and practices have been implemented to control and manage the development, operation, support, and maintenance of the IT function. The environment is mature.

This type of mature technical environment was relatively slow to change, so methods and people were able to adapt easily to the changes. The environment was relatively simple and stable. This slower change and general stability meant that a small number of well-trained staff could investigate change, develop a coherent technical strategy, and adapt the system management practice to take account of this change. The skills required of the majority of development and support staff were relatively low level.

Figure 15-2 A traditional corporate environment

Understand Where You Are

Make it work first before you make it work fast.

Bruce Whiteside

Today large-scale Visual Basic 6 distributed systems, such as the one depicted in Figure 15-3, are normally attempting to achieve high levels of integration within a business. This implies integration among systems that might require links to e-mail, workflow, document image databases, multiple conventional data sources, and the Internet.

To achieve the necessary integration and performance, you might need to use multiple APIs and protocols. The technical skills required to architect, design, implement, and support such systems are significantly higher level than those called for in traditional mature environments.

Figure 15-3 A modern corporate environment

With so many technologies and products involved, the development environment and tools are very fluid. The tools are increasingly complex in order to cope with the complexity of the environment. With the move from Visual Basic 3 to Visual Basic 6, we have seen Visual Basic move through three major leaps in functionality and capability. Practice and skills in this environment are immature.

Build Commitment and Understand Users

Pick battles big enough to matter, small enough to win.

Jonathan Kozol

Project managers and users often have problems with defining project scope and keeping it in line with schedules and budgets. Continual commitment to dialogue is essential to ensure that business domains and technological solutions actually produce benefits in spite of the fact that normally not everyone involved completely understands these domains and solutions. The effect of normal business risks on a project can be greatly magnified to job-threatening and sometimes business-threatening proportions.

Your approach to development must make it possible for you to cope with large projects. Many attempts at rapid development have been based on scaling up small-project development practices. This model of development provides some useful lessons, but it must be placed in a framework designed for large-scale developments.

The development process must allow for managing changes in requirements without excessive bureaucratic burden and large amounts of rework. Often a way to achieve this goal is through prototyping. Visual Basic has always been an excellent prototyping tool that can be used to improve the understanding of requirements. Keep in mind, though, that the techniques for building rapid prototypes are very different from the effective use of Visual Basic 6 for building robust distributed systems. Users must not be misled into thinking that prototypes are anything other than prototypes. This misconception is a classic way of losing your users' confidence and commitment. (For more information about prototyping, see the "Why Are You Prototyping?" section later in this chapter.)

User commitment and involvement are critical factors to all application development. These factors have traditionally involved a contractual, even adversarial, relationship. On this basis, user commitment and involvement have been relatively easy to manage but not necessarily successful. If you are to speed up development, you must make users part of the development team and involve them continually.

The commitment from the business manager must be to assign to the development team a user who understands the business in sufficient depth to answer developers' questions, has the authority to make decisions on behalf of the business, and can live with the result of his or her decisions. To find such a user and release him or her to an IT project takes commitment. Major projects typically cross functional boundaries. Giving someone authority to make decisions across those boundaries means commitment from the top.

Understand the Technology

Any sufficiently advanced technology is indistinguishable from magic.

Clarke's Third Law

To manage risk on Visual Basic 6 distributed development projects, managers must get closer to the technology. Managers need to be clear about why and how design decisions are made. If you're hanging your career on a technology, you'd better understand that technology. Managers need to know where tools are weak and understand how different architectures perform.

Often when there is a decision to be made about what tools to use, what method to take, and so on, there is no clear-cut choice, so the project management approach must take this uncertainty into account so that correct decisions can be made at the appropriate time. It might be necessary to test different approaches prior to making a decision. Time must be figured into the development schedules for research and benchmarking.

With any major new technology, you should set up a Pathfinder project to investigate the technology. A Pathfinder project is a miniature, timeboxed project that identifies the risks within a larger project. Typically, such investigations are not emphasized enough. Users often don't want to pay for something that they see as producing nothing at the end. Instead, you might hear a manager say, "We recognize the need to learn more about the technology, and if our developers need more knowledge, we'll send them to a class." However, with the rapid growth of technology and the complex way in which it applies to existing businesses, there is often not an applicable class, so the Pathfinder approach is a better way to investigate new technology. See the "Creating a Foundation with a Pathfinder Project" for more detailed information about such projects.

One of the objectives of the Pathfinder approach is to provide an initial knowledge base. Providing a knowledge base must be handled carefully, however. Many companies have older, established development environments on which they have spent a great deal of time, effort, and money. They might be reluctant to compromise the status quo by chasing after some new, unproven technology. New skills and methods need to be incorporated alongside existing strengths so that the current knowledge base can be improved rather than undermined or replaced.

At TMS, the approach we have used successfully in setting up Pathfinder projects is to create a small, highly skilled team to develop and prove the infrastructure and the tools. In subsequent project phases (after this Pathfinder project), this team carries out the technical supervision of other teams involved in the project to maintain the technical integrity of the application architecture. This core team, or "SWAT" team, has a role in developing skills in the other teams. It also helps other teams by providing resources to assist in clearing tasks on the critical path.

Some technical decisions have to be made early. For example, the choice of hardware platform or the database management system to be used is often fixed, or at least assumed, before the formal development project is kicked off. Inappropriate decisions at this stage can be very expensive. For example, we know of several cases in which relational approaches were used to address problems that are better suited to Online Analytical Processing (OLAP) solutions. Consequently, effort was expended writing complex SQL and application code to produce functionality that already existed in the OLAP extensions to the relational database. Hasty decisions such as these can lead to a 30 to 50 percent increase in development costs. The ongoing cost of maintenance is also much higher than necessary. Such costs normally don't come to light because of the general ignorance of the appropriate use of technology or through inertia. However, there are kudos to be gained by stepping out, taking a risk, and delivering a better solution ahead of schedule.

It is vital that you understand Visual Basic 6 if you want to use the technology to its full advantage and to avoid pitfalls. Using a sophisticated technology such as Visual Basic 6 without adequate knowledge could cost you your job.

Create a Sensible Management Structure

It was a relief to know that it was just bad management and not technical problems.

Development manager after firing the head of IS

The rapid development of new tools and operating environments has meant that many information systems development management staff have little understanding of the technical issues and risks involved in these new technologies. As we have said, a key role of a project manager is to manage risk. Rapidly changing technology increases risks dramatically. Technical managers must understand the technology sufficiently to assess risk and act appropriately. The management structure might need to change to ensure that managers are close enough to the technical issues to manage risk. This generally means flattening the structure and devolving responsibility. The implications of this type of change extend to all facets of the information systems development organization, including organizational structures, salary and reward structures, skills planning, and training.

If a project involves prototyping, it might be necessary to give more responsibility at lower levels for managing user relationships and expectations. Prototyping provides an opportunity for developers to work more closely with users and to become more involved with business issues.

Get a Process

Standards were ignored, no method was applied, the system was not designed, staff were not adequately trained, management did not have sufficient technical knowledge to run the project, poor internal support mechanisms, no quality assurance, no test plans, no resources for testing, poor development environment, no risk analysis, 100 percent staff turnover, little documentation, no application architecture.

Project review

Project managers must plan the project and use an appropriate process to deliver the application. The approach they adopt should be based on the business and technical architectures and the project risks. The approach can be pure waterfall, spiral, incremental, or evolutionary. The life-cycle model used should not be dictated by a method but should instead be based on the characteristics of the project. Standards are no substitute for a project manager's experience and judgment.

Given the technical complexity of Visual Basic 6 distributed development, any approach must allow sufficient time for architecture and physical design. Doing these tasks up front can provide significant productivity gains by reducing rework and allowing more tasks to be carried out in parallel.

If Visual Basic 6 distributed development is used for high-profile and high-risk projects, a number of issues need to be addressed. A formal approach to the management, specification, design, and development of applications will be needed. A risk-driven design method that focuses on creating an appropriate application architecture will have to be created.

Visual Basic 6 distributed development lends itself to object-oriented analysis and design and to rapid development. Object techniques can be used to enhance communication between users and development professionals. Version 6 has further extended the object-oriented character of Visual Basic. To make best use of Visual Basic, the development process must reflect this character and take advantage of it. This endeavor will bring challenges in developing the skills of staff and managers.

Visual Basic 6 offers a range of productivity features that must be integrated into the development process. The public ActiveX interface of Visual Basic and the extensibility and configurable integrated development environment (IDE) provide the opportunity to integrate Visual Basic and other tools that automate and control the development process. To exploit fully the power of Visual Basic 6, you need to take its features into account in the development process.

Please refer to Appendix C for details of the TMS Developer's Framework, which combines Visual Basic 6 standards and base code to boost quality and productivity.

Choose a Method

Never confuse motion with action.

Ernest Hemingway

Off-the-shelf development methods are often static prescriptions for "how-to" development; more fluid guidelines and a toolkit of techniques might be more appropriate. However, switching to new methodology entails high costs of adjustment. A better approach is to combine the best of existing practices and standards with the newer techniques to evolve an adaptable in-house Visual Basic 6 distributed development method. The key to a successful method is to manage risk while allowing development to proceed rapidly.

A desire for quality and technical purity encourages a rigorous approach to development. Methods such as SSADM (Structured Systems Analysis and Design Method) promote rigor and tend to be used with a waterfall life cycle. This approach works in traditional environments with skilled project managers. In unskilled hands, the level of rigor tends to be too high. When unplanned backtracking also occurs, costs soar and schedules slip. To counter this excessive rigor, iterative rapid application development (RAD) approaches are used, such as the Dynamic Systems Development Method (DSDM) or the Microsoft Solutions Framework (MSF). These often produce solutions with short lifetimes because they lack the framework more rigorous approaches provide.

Successful users of prototyping and rigorous methods have concluded that no one approach has all the answers. Controlling the development and project management processes is critical to the successful delivery of a system. Design requires high-quality management and good technicians. Controlled RAD applies rigor where necessary, and prototyping for specific goals can accelerate the development process. It allows you to balance the needs of the business, the limitations of a technical infrastructure, and the desire to deliver quickly.

As illustrated in Figure 15-4, a solid component-based architecture and reusable design patterns allow development activities to be carried out in parallel without compromising design quality. Development phases can be decoupled and development speeded up.

Figure 15-4 Decoupling the development process

Rapid development is often thought unsuitable for applications in which the design is not visible at the user interface. Using business objects allows design to be taken out of the RAD life cycle. In simple terms, the RAD life cycle then consists of prototyping and gluing together business objects. Business objects, design patterns, and architecture are the key components that capture the design and enable RAD to take place.

ActiveX is Microsoft's component strategy and the core of Visual Basic 6. The features in Visual Basic for enabling reuse provide a basis for developing a pattern- and component-based architecture.

A critical prerequisite for carrying out controlled RAD is that the main risks are understood and minimized. In taking on Visual Basic 6, a new set of risks have been created. Your first Visual Basic 6 project will not be a RAD project, whatever your intention—it will be a learning experience.