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 chapter 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.
DETERMINING PROJECT DEVELOPMENT TOLERANCE
WITHIN THE ORGANIZATION
Every organization has a particular level of IT application project development tolerance. The level within a given organization depends on a number of items throughout the organization. One approach to improving the IT development project process is to come to an understanding about the practical manageable size of IT
applications projects within a particular organization. That determination can be made through a review of past projects. Reviewing the results of past IT applications development projects provides information that can be used to develop success or failure trends, which in turn, can be analyzed with reference to project size.
Some type of criteria must be developed by which to judge project “success” or
“failure.” Those criteria will vary within organizations, depending on those factors that are considered important within the organization. The key with regard to any single criterion used to make the judgements is that it should be seen as a reasonable measure within the organization. In addition, the criteria cannot be allowed to become cumbersome or complex. The goal here must be to select a set of basic components that will provide not the definitive answer but rather a guideline as to the probable success of a given project based upon past experience within the organization. Where that probability suggests that the project is likely to fail, adjustments must be made to bring project size, time, and complexity to a level that will provide a higher probability of success.
As an example, assume that during the past three years, the IT department has worked on 125 projects. During that time, an average of 700 development hours have been devoted to those projects, for a total of 87,500 hours. In doing an analysis of the 125 projects, it is found that, under the criteria developed for determining success or failure, 18 projects fall into the failure classification. Of those 18 projects, 14 have exceeded 900 hours of development time and again, using the success or failure criteria, all 14 projects carried a high level of complexity. In addition, only three projects taking more than 800 hours have been brought to a successful conclusion during the past three years.
At this point, what the analysis shows is that, within this organization, projects that exceed 900 hours of development time are prone to failure. The result of that analysis indicates that IT development projects in excess of 900 hours of effort seem to be beyond the management capabilities of the IT department. Another fact developed from the analysis showed that over the three-year period, three IT project managers had, regardless of the size or complexity of the project, always brought their projects in on time, within budget, and in accord with the project requirements.
Several quick conclusions can be drawn from the analysis. First, it is probably not in the interest of the organization to consider any applications development projects
that approach or exceed 900 hours of effort. Second, several project managers are, in spite of the development environment, able to bring projects to a successful conclusion. Two conclusions can be drawn about the role of those project managers.
First, those project managers should be assigned to the largest, most complex projects within the organization. Second, further study should be done to determine why those managers are successful.
Where the analysis is carefully done and the criteria used to judge success or failure are reasonable and consistent, patterns of IT project development success and failure can be identified. Done correctly, the analysis of prior applications projects should provide information about the optimum level of project size and complexity with regard to probable success. That should not be seen to imply that whatever that level is it is the best that can be accomplished. What it means is that for the present, a ceiling on project size can be determined. Remaining under that ceiling can bring about an immediate improvement in the management of projects, but it should also be seen as setting the base for moving to new practices that will allow that ceiling to be raised.
So, the analysis meets two requirements. It provides a guideline as to the limits of project size and associated complexity within the organization. It also provides the basis for moving forward to bring about changes within the organization, particularly within the IT department, that will lead to the ability in the future to handle larger, more complex applications projects.