THE TRADE OFF BETWEEN ADDED VALUE AND INCREASED PROJECT COMPLEXITY

The question to ask, relative not only to the use of new technology or approaches but to any other project encumbrances, is How will this, in terms of lengthening the project or adding complexity, affect the project? If the answer is that the effect will be negative or the answer is not clear, caution should be exercised with regard to opening the project to include those additional items. The argument should not be allowed to move to the validity of the requests or their value. It should be recognized that the proposed additions to the project would all probably be beneficial. The issue is what, in terms of time and complexity, will those items add to the project. The focus must be on the balance between adding the requested items whatever they may be and the potential cost in terms of project risk associated with accommodating those requests.

In thinking about adding new technology, it is important to keep in mind that either little is really understood about the technology, or that the levels of IT time and effort needed to get it to work are going to be underestimated. In dealing with medium to large IT development projects, given their inherent complexity, adding a technology learning curve portends difficulty for the project.

Given that the probability of success with IT applications projects can be increased if the complexity of those projects is reduced, taking an approach of developing more but smaller IT applications should be accorded serious consideration. Assume that a request for an IT application project is made and the request is approved for investigation. After the analysis of the request, it is found that the project as proposed will require 3,000 hours of effort to complete.

The duration of the project has been established as eight months. Although the time estimated to complete the project at this point in the development cycle is probably arbitrary, that estimate is likely to be seen as absolute. That circumstance, quite common in the development of IT projects, represents another negative aspect of project development that adds to the level of risk. Although the setting of arbitrary project completion dates present serious project complications, that is a topic beyond the scope of this article other than to acknowledge it as a negative factor.

Subsequent to approval, a project team is assembled and work begins on the project. As that work moves forward, requests begin to arise for additional functions within the project. Given the business needs being addressed by the project and the benefits to be derived from the expansion of the project, the levels of staffing to complete the new requirements are approved. At this point, the completion date may be moved out to accommodate the additional work, or, it may be assumed that by adding staff, the completion date need not be adjusted. In terms of outlining the increased needs of the project, adding the needed staff, and in at least attempting to reset the completion date, the project team has done the right things. What has not been done correctly and what will bring about difficulty is that the project team has not, in this situation, considered the increased complexity that has been layered into the project. The assumption is that adding staff and adjusting the completion date will cover the requirement to add features and functions.

In this example, the project team, even though it has considered the need for additional resources and time to handle the project expansion, has put itself in an unfortunate position. By not recognizing the issues of the expansion and increased complexity of the project as they relate to potential difficulty, if not serious problems, the team has set itself up for, at the least, disappointment. Too often as a project expands and it becomes clear that the project is experiencing difficulty, the focus moves to the issue of adding people and time to meet the project goals. While that is an appropriate focus, it is only a partial focus in that the factors of project expansion and its related additional complexity must also be considered in the analysis. In reality, adding people to the project, whether at the beginning of the project or after it has been determined that the project is in difficulty may be an apparently easy answer to the problem, but it may be the wrong answer. Adding more people to the project increases the level of effort associated with the issue of project management and coordination and, as a result, adds to overall project complexity.

The correct way to handle the issues involved in the example would have been, in addition to calling for more staff and time to meet the new project demands, to present and push for the option of dividing the project into more manageable components. That process might have been to structure the project into smaller components (phases), to break the work into separate projects, or to reduce the scope of the project. Finding the right answer would depend on the circumstances, but the concern should have been with avoiding undue size and, as a corollary, complexity.

It is of course correct that reducing the size of the project or breaking it into phases would cause the potential benefits associated with the project to be reduced or delayed. Every organization must make decisions about the acceptable size and risk of IT projects. However, in many instances the belief that smaller is better represents a pragmatic approach. Many large, well-intended IT applications projects have floundered. Some of those projects have been scaled back and salvaged, but others, after considerable cost and organizational stress, have been abandoned.