5.2. Project Metrics and Estimates
This section discusses the measurements and estimations that are relevant to the project as a whole. These metrics help a project manager to understand the type and size of the project and also to estimate the time and budget that will be expended in executing the project. An attempt is also made to spread the time, budgets, and people over the various modeling spaces for UML-based projects. Needless to say, project metrics, like all other metrics, continue to remain a combination of some good scientific theory and a lot of practical experience.
5.2.1. Project Size and Type
In Chapter 1 we discussed the various types and sizes of UML-based projects and the underlying reasoning for the classification. Here, we elaborate on that same discussion and look further into the reasons for the categorization.
First, we categorize the size of projects into small, medium, and large. This categorization is done with the intention of finding out how UML benefits these projects. Categorizing helps us to understand the intensity with which the UML quality checks are applied and the formality of applying the process. During enactment, more than one person fills a role described in a process-component. Also during enactment, one activity is repeated many times. Therefore, the categorization of projects in Chapter 1 is taken further here, in practice, to enable good measurements and good estimates.
Second, we consider the various types of projects, also discussed in Chapter 1. These project categories influence the way in which the project technology, methodology, and sociology are enacted. Readers will recall that the six types of projects are:
Development projects
Integration projects
Package implementation projects
Outsourcing projects
Data warehousing and conversion projects
Educational projects
Each project type is estimated differently. And the same process-components in different projects are estimated differently. This is because each of these projects has different needs for the UML diagrams, and therefore the time and effort spent on each of the UML diagrams varies depending on the type of project. Furthermore, the number of people fulfilling a particular role also differs based on the project type and the project size. A data warehousing project, for example, needs more than one person to fill the role of a database manager, whereas a CRMS implementation needs many business analysts but perhaps only one database manager (as the database doesn't need to be designed in a package implementation project—only fine-tuned).
5.2.2. Project Time, Budgets, and People
Let us consider some practical estimates in terms of distribution of time, budgets, and people over the various modeling spaces for projects of three different sizes. This is followed by brief comments on the variations to these estimates based on project types. It is worth mentioning at this point that process-components such as those of project management, process configuration, and quality management, which are executed in the background, are common across the modeling spaces. Therefore, estimates related to these process-components are shown in a separate column, whereas estimates related to the architectural work are shown in the MOBS column.
Small Projects
| MOPS | MOSS | MOBS | Common | Total | |
|---|---|---|---|---|---|
| Budgets | $300K | $400K | $200K | $100K | $1M |
| Time | 2 months | 3 months | 1 month | all | 6 months |
| People | 2+1 | 4 | 1 | 1+1 | 10 |
Comments
In a small project a project manager should expect to spend around 30 percent of his budget and time in the problem space. The time assigned will be spent in understanding and modeling the requirements in the MOPS. Part of this work in MOPS includes discussion sessions on the whiteboard and later, optionally, in a UML CASE tool. The 2+1 people in the problem space include a user who may not be onboard full time for the project. Similarly, the common roles include the roles of the project manager and the quality manager. Small projects may not have budgets for both roles in a full-time capacity. Following the IIP lifecycle, the first iteration includes all aspects of modeling and management; therefore, the above distribution is also iterative. If it is an educational project, then of course the budgetary constraint may not apply. Furthermore, the time requirements will be limited to 14 weeks.
Medium Projects
| MOPS | MOSS | MOBS | Common | Total | |
|---|---|---|---|---|---|
| Budgets | $2.5M | $3M | $3M | $1.5M | $10M |
| Time | 4 months | 6 months | 3 months | all | 1+ year |
| People | 4+2 | 15+3 | 5+1 | 5 | 35 |
Comments
In the MOPS, one would envisage four business analysts, together with two users, conducting workshops and interviews to elicit detailed requirements. The people in the solution space involve approximately fifteen developers and three testers. The five people in the background space play the role of architect, process consultants, and senior designers. The one extra role shown here is filled by the vendor representative. This role is a combination of consulting support from component, database, and Web application vendors.
Large Projects
| MOPS | MOSS | MOBS | Common | Total | |
|---|---|---|---|---|---|
| Budgets | $5M | $10M | $15M | $5M | $35M |
| Time | 1 year | 1.5 years | 6 months | all | 3 years |
| People | 20+10 | 100+20 | 20+10 | 20 | 200 |
Comments
Figures in Table 5.3, based on the description of large projects provided in Chapter 1, provide some interesting insights in the distribution of effort in the modeling spaces. Consider how, in this example, the amount likely to be spent in the background space is high—three times the amount spent in the problem space. The time, however, that the project spends in the background space is half the time spent in the problem space. This is attributed to the fact that the architectural work in the background space involves buying third-party components, application servers, and databases. If these infrastructural things are present in the project (unlikely in a large project), then the distribution provided here must be modified.
Furthermore, in a large project, one expects a large number of users involved in the problem space (shown by the +10 figure indicating 10 user representatives), working alongside the business analysts and requirements modelers in the problem space. Development teams in the solution space comprise the 100 developers, in addition to the 20 who focus on the quality control or testing part of the project. One would expect more than one project manager in this project, reporting to the senior project manager or equivalent role. Overall, in large-scoped projects, not only do all the roles of a process-component come into play, but also the number of people fulfilling the roles and the number of instances of deliverables produced multiply.
5.2.3. Caveats in Project Estimates
Project managers are surprised to find their estimates go awry despite having based them on as much logical information as was available. Furthermore, the exercise of estimation itself has an effect on the time and budget consumed by the project—as was shown by the Jeffery and Lawrence study at the University of New South Wales, reported by DeMarco and Lister [1987]. Interestingly, this study reveals that productivity seems to increase where no estimates on the project are prepared.
Following the advice of this study verbatim is most likely impractical. Yet there is something of immense value in this reported study for those who make estimates: Extremely conservative or tight estimates may not always lead to a healthy working environment. Estimates that provide concessions for the road factors eventually turn out to be the most productive—or productivity-boosting—estimates. This also seems to ratify what most project managers already know intuitively, that compressing schedules beyond a certain point (for example, more than 30 percent of the original schedule) results in a recoil of a spring-type expansion of project timelines. Thus, considering road factors and the sociological impact of scheduling are essential to successful project estimates [Unhelkar 1995].