The Dimensions of Development Speed

According to Steve McConnell, there are four dimensions, or components, that impact development speed.^[1] If any or all of these dimensions can be improved, the development schedule is likewise improved. The four dimensions are:

1. Process

2. People

3. Product

4. Technology

These four dimensions apply in every project, in every industry, and in every organization. The obvious, but often not recognized, solution then would be to examine each of these four dimensions and to change those that are adversely affecting the project. The problem is that we often opt for some magic solution to our problems rather than recognizing our weaknesses and correcting any problems. However, each dimension has associated with it a number of common problems that can seriously impact any project. Recognizing these problems (and some possible solutions) could significantly improve your schedule and your company's competitive position.

Process

Every organization has processes for developing software or their other project tasks. The processes may be informal, that is, not documented or rigorously followed, or they may not be current.

Every organization should have documented guidelines for each of the processes supporting the project. Some common processes include:

• Developmental fundamentals (a process for establishing a development methodology)

• Quality management (a process for identifying and implementing quality standards and assessing the product's quality against them)

• Risk management (a process for identifying, assessing, and controlling the project risks)

Every organizational process should be examined and reengineered for currency and effectiveness. Rigorously recording and implementing lessons learned from each project that passes through the system should constantly improve them.

People

The human side of project management is often its most challenging element. Compared with managing people, technical problems are relatively easy.

There are several key factors a project manager should consider when forming and managing the team. They are:

• Skilled talent

• Job matching

• Career advancement

• Team balance

• Misfit elimination

Skilled Talent

Too many projects fail or suffer because the team members are not the best for the job. Many project managers approach functional managers with requests for personnel without indicating the specific individuals she would like to have on the team. The most important skill of a successful project manager is the ability to negotiate. Considering that the project manager generally must negotiate for everything—budget, personnel, capital equipment, more time, and so on—it is not surprising that the more successful ones have highly developed negotiating skills. To ensure that the project team is composed of the best talent, the project manager must approach functional management and request specific individuals. The individuals requested may not be available to work on the project, but having asked for them by name immediately establishes the experience, education, and capability level the project manager needs. So, rather than supplying someone who happens to be available at the moment, the functional manager is more likely to attempt to replace the requested individual with someone who has as good or better qualifications.

Job Matching

Forcing someone into a job she is not qualified for, or not happy doing, is sure to result in a team member who is dissatisfied and even detrimental to the project. As obvious as that statement is, it is not difficult to find team members who are ill suited for their positions or performing tasks they detest. A good leader will recognize the importance, not only to the team member but also to the project, of matching each person with the right job. However, job matching means more than assessing skills; it also means assessing personalities and preferences. Using standard assessment tools such as the Myers-Briggs Type Indicator is a good way to determine team member preferences in terms of whether a person likes working alone or in a group, working at tasks requiring attention to detail, or whether he might be a better planner than a developer. Whatever the process used, the likelihood of project success improves significantly with team members whose skills, experience, and preferences are matched to their assigned jobs.

Career Advancement

To the best extent possible, every project experience should be one that enhances the team member's potential for advancement. Helping the team member self-actualize will gain the project a loyal, dedicated, and highly productive worker and will help the organization in training its future senior management.

Career advancement in the context of project management has taken on a new meaning since project management came to be viewed as a legitimate career path during the late 1980s and early 1990s. Before that time, project management was a respected job description. However, to progress up the corporate ladder, one typically had to take either the marketing and new business development or financial path. Today project management is recognized as a career path in its own right. Project managers have a much broader knowledge base about company operations than do most functional managers. This is particularly true in those organizations that encourage project managers to attain the project management professional (PMP) certification. Many organizations are providing their project managers and team members with additional project management training. Some companies are requiring that their employees be certified before they can even become project managers.

Team Balance

Team balance means that the each team member's skills, knowledge, and experience must complement every person on the team. For example, if one team member is an exceptional software developer but a poor communicator, another team member with strong communication skills might be assigned to translate the developer's progress into reports, briefings, and status reviews. Not only must the team's technical skills and knowledge be balanced, but it also needs to have balance in the way the team members interrelate with each other. Maintaining team balance is more challenging for the project manager than solving technical problems in the project.

Misfit Elimination

Though a difficult and unpleasant task, eliminating team members who do not pull their weight, or who cannot get along with the other team members, is crucial to any project's success. Too often, project managers allow a problem to fester because they do not like confrontation, they want to give a person another chance, or they simply do not know how to handle the situation. Nevertheless, a key leadership requirement for the project manager is to know how and when a misfit must leave.

The project manager faced with a misfit on the team should try to determine the root cause of the problem, and she should try to resolve any issues. All conflict issues must be addressed immediately as they occur, and a reasonable time should be allowed for correction of the problem. But for the good of the team, project, and organization, the project manager must be decisive and expeditious in bringing any issue to a final and clean solution. This includes eliminating team members.

Product

This dimension, arguably the most damaging to development speed and perhaps the hardest to control, has to do with the project deliverable or product. If the development speed is to be improved, two characteristics of the product need close attention—the size and the complexity.

Failed projects typically have one recurring characteristic— they are very large, or they are large relative to the size of the organization's capability. Software developers in particular have no fear about attacking products (i.e., project deliverables) that are designed to perform myriad functions. However, more functions require greater, and longer, efforts.

The product is the most tangible part of the project. It offers the best opportunity for making changes that will favorably impact the schedule. The size of the product in terms of cost to develop and build, numbers of resources required, and time to complete may be beyond the organization's capability to perform, even if the product represents the organization's core business. To control the size of the product, the organization can either team with other organizations and approach the project from the perspective of a larger entity, or the product can be divided into manageable pieces, options, or phases.

In terms of functionality, the complexity of the product is also troublesome for most organizations. Engineers are notorious for adding functionality to a product, even when it is not specified. But added functionality begets added effort. It has been estimated that cutting the functionality of a medium-sized product in half reduces the effort required to complete it by two-thirds. In other words, for every function added, effort increases exponentially.

Development speed can be greatly improved by controlling the product size and complexity.

Technology

There are two aspects of technology that impact development speed—rapidly changing technology that makes the product obsolescent before it is introduced into the market, and changing old technological tools for new ones.

We can control the first problem, rapidly changing technology, by being circumspect in the choices made during product design. If the technology is unpredictable, relative to when it is liable to change, then an alternative design is in order. However, it is also the case that technology changing in the middle of a product development cycle can be worth the risk, depending upon the business benefits of the change and how well it is planned and controlled.

The second aspect of technology change, changing old tools for new, is predictable and can significantly improve development speed. We simply mean that existing software design, development tools, and equipment need to be examined periodically to ensure that the project team is using the most effective and efficient tools available.

Having considered the four overarching dimensions that impact development speed, it is possible to develop a general strategy for implementing a rapid development process into the team's working environment.

^[1]Steve McConnell, Rapid Development: Taming Wild Software Schedules (Redmond, Washington: Microsoft Press, 1996).