|
|||||
Managing Large Projects (Part1)Development EffortDevelopment effort is typically defined measured in people effort, capital equipment investment and organization on-costs (accommodation, consumables, etc.). Few major business projects have kept detailed metrics and measures of costs so many of the examples in this paper will be drawn from IT-related projects, which traditionally have been more focused on measuring costs. However, the sizing data from IT projects is relevant for all projects. Similar sizing data is available from the construction, defence and aerospace areas. Boehm (1984) and Capers Jones (1991, 1995) provide estimating heuristics that put the development effort for large IT-systems at 50,000 work-hours plus or approximately 40 - 50 person years (based on 5 work-hours/day and 210 days/year). In addition, the actual development effort would require additional business professional effort not usually measured by computer-oriented project tracking systems. These people would be in-directly involved in education, physical office re-organization, testing, file conversions, etc. Assuming no direct capital investment for the project, the project would also consume computer-time and resources for development design, coding, file creation and so on. A reasonable rule-of-thumb could use the standard metric that the Information System budget is split roughly 50/50 between people and equipment, software and services. In which case, each dollar spent on people would be matched by a dollar of computer, software expenditure. Of course, many large projects such as Westpac's CS90, the US IRS system, the Millennium Dome and the Australian Taxation Office Re-development project involve direct capital investment of many hundreds of millions of dollars.
In summary, development costs for large projects would be of the order of $15,000,000 and greater. Development time-scale Given the 40-50 person year effort required for large projects to build the system, the minimum development time-scale would be around 12-18 months. However, as indicated by Boehm (op cit), Putman (1976), Brooks (op cit) and others, the scheduling of 50 person-years effort on one single product in a year can lead to inefficient staffing peaks. Therefore, as described later in Project Development Strategies, large projects would be divided into sub-projects (alternatively, projects would be grouped into a single programme). These sub-projects would be scheduled and staffed relatively independently and as a result the development time-scale is generally staggered over a longer period. Staggered development schedules over 2 years or greater is common for large projects. In a period of unprecedented economic, political and technological turbulence, the longer the project exists over time, the higher the probability that the project will have to accommodate external requirements changes, technology changes and internal changes such as staff attrition and turn-over. In other words, the very requirement for long development time-scales requires large projects to accommodate a high rate of change leading to a further expansion of the time-scale (see box). Application/software size Application size can be defined using three related groups of software metric: (1) lines of delivered source code, (2) input, output and file volumes and, (3) IBM's Function Point. Capers Jones (op cit) defines large projects as those projects which deliver a system of 64,000 LOC or greater. Barry Boehm (op cit) defines large systems as 128,000 LOC or greater. Other sources define a large system as one with more than 40-50 logical inputs, 40-60 outputs, 25-30 inquiry screens and 20 plus logical database views (files). Function Point sizing which is also based on inputs, outputs and so on would suggest that a large system would produce around 1500 Function Points or greater. Both Jones and Boehm agree that there is a special category of information system - the super-large system which would produce 512,000 LOC or greater. A large system (for example, one with more than 128,000 LOC or greater than 1500 Function Points) may also be considered as a super-large system should it require complex input, output, file considerations or require complex algorithmic processing. Technology Risk The use of leading-edge technology and/or the use of stable technology to the limit of its processing capability is another feature of large projects. In many cases, technology risk is also sufficient for a medium system (64-128K LOC) to be treated as a large system from the management perspective. Current examples of technology risk would include the use of object-oriented techniques, complex internet technologies, leading-edge programming languages and communications networks for large projects involving high data-volumes or transaction rates. The stretching of current technology would be typical for large projects. The size of these applications would require transaction rates, database volumes, communications network and systems design which introduce the exponential scale-of-effect multipliers first documented by Brooks in The Mythical Man-Month (1975, 1995). Organizational impact The final criterion for large projects would be the impact of the project on the organization's strategic growth path and the essential processing units in the organization. Typical large projects would be vital to the survival of the organization and would be a major element in the development of new strategic product. As a result, large projects require substantial re-organization and rationalization of many sections of the organization. This raises issues of job re-design, union involvement, client service facilities and products, physical office re-design and so on. Peter Keen (1981) is one of the few people who have documented the complex issues associated with the organizational change and it's impact on people associated with large computing projects. In particular, he addresses the difficult political issues that will be raised by the high degree of change. It would be common, as mentioned earlier, for higher costs and impact to be incurred outside the project than directly within the project. In addition, the development of large projects would require a higher level of intra-organization coordination. For example, because of the wide organization impact, many separate business groups and technical support groups (data-base, network engineering, operations, etc) would be involved in reviewing and approving planning, development and implementation of the various new products and deliverables associated with the project. In many cases, outside organizations such as vendors, contractors, unions and other companies or government departments would also be involved with the project. In addition, medium-size projects with leading edge technology and/or high organizational impact would tend to behave as large projects and exhibit the same issues. For the purpose of this paper, they will be considered as large projects. Management Issues
The management of large projects centers on a set of concepts relevant to all projects but which require special focus and variation for large projects:
|
| << Table of Contents | Part 2 >> | |||
|
copyright: Thomsett INTERNATIONAL 2010 | contact |
||||