Chapter 7: Process Management: Integrating
Project Management and Development
Chris Gane
OVERVIEW
To most software developers, the areas of project management and systems development methodologies are related only loosely. Systems development methodologies provide general information about standards and practices; project management is concerned with budgeting and reporting of project activity cost and time.
Automated tools to support project management and systems development methodologies have evolved separately. However, it has become apparent that the two areas need to be unified into a single discipline of process management that has a single underlying metamodel. This chapter provides the rationale for unifying systems development methodologies and project management and describes one type of process management metamodel as well as an approach to its automation.
Process management has much in common with business process reengineering.
Organizations that have adopted process management are applying the principles of business process reengineering to application development. In this chapter, process management is defined as the unification of methodology with project management.
PROJECT MANAGEMENT: FORMAL AND INFORMAL
There has always been tension between the formal and informal aspects of project management. Formal project management is concerned with the generation and execution of plans; informal project management is concerned with the motivation and coordination of project staff.
Formal Project Management
Formal project management involves project planning as well as project control.
Project planning attempts to provide answers to such questions as:
§ Which tasks have to be done?
§ Which tasks must be complete before others can be started?
§ Which skills are needed for the tasks defined?
§ Who is available when and for how much time?
§ How long will the project take, given the people available (i.e., resource-driven estimating)?
§ How many people are needed to get the project done by a certain date (i.e., date-driven estimating)?
§ How much will the project cost?
The questions on estimating time and cost are always difficult to answer; one of the main objectives of process management is to make estimating easier and more reliable.
Project Control Project control deals with executing the project plan and is concerned with regularly (e.g., weekly) answering the following questions:
§ Where does the project stand?
§ Based on this status, when will it be done now?
§ What has been spent so far?
§ Which assignments are critical this week?
§ Who needs help?
Project control also deals with coping with such unplanned problems as
§ When employees are pulled off a project, how is the work to be reassigned so that it gets done as soon as possible and as inexpensively as possible?
§ A program was estimated to take 100 hours to complete; 80 hours have already been spent but the program is only halfway through. How does this affect the project deadline?
Informal Project Management
Formal project management can be automated because it makes use of such approaches as critical path analysis. Informal project management is concerned more with intuitive judgment and relationships among personnel. Informal project management tries to answer such questions as:
§ How reliable are an employee’
s estimates?
§ A group of programmers is on the critical path this week; how can they be motivated to finish faster?
§ Who needs formal training in which areas, and who needs coaching?
§ What is the state of the team morale? Should anything be done to improve it?
Some of these judgments can be decided with quantitative information. If the history of an employee’
s estimates can be accessed as well as the actual time the employee took for each assignment, this information can be used to correct estimates.
In this way, formal project management skills can support and improve informal project management, although they are no substitute for intuition and judgment.
People who are proficient at formal project management may not have outstanding interpersonal skills. Similarly, good informal project managers may be impatient with the effort involved in creating plans and revising them as a project unfolds. Formal
project management can be learned, and it appears that informal project management cannot — either someone simply is or is not good at it.
Organizations are thus under pressure to find talented informal project managers and to support them with aids for formal project management. Some organizations provide staff to help project managers with project planning and control; automated tools are being used increasingly, but they will be commonplace only if they are easy to use and provide obvious value to the project manager.
THREE APPROACHES TO ESTIMATING
Project managers are under a lot of pressure to produce estimates of time and cost for systems development very early in a project, typically in the first two weeks.
However, estimating a development project from outline requirements and not from a physical design is like a home buyer saying, “Quote me a price for building a house, but I am not sure where I want the house located, or about the number of rooms, or whether it should be of brick or wood.” It is not surprising that project estimates are as bad as they are, but that they can be made and met at all. Three approaches can be taken to estimating:
1. Using industry experience
2. Using the experience of one’
s own organization
3. Rolling up more or less detailed estimates of the project effort Using Industry Experience: Function Points
Perhaps the most useful form of recorded industry experience comes in function point counts. Many people measure software efforts based on the number of lines of code. The trouble with this measure is that the same function involves many more lines in a low-level language than in a high-level language. Often, an algorithm coded in one language requires more lines to be coded in another language.
A function point count is a more stable measure of software size than lines of code, because it is based on the number of inputs, outputs, files, and other measures of complexity. The International Function Point Users Group (IFPUG) has put considerable effort into devising and maintaining standard methods for sizing software.
The Function Point Method Briefly, one counts the files, inputs, outputs, and queries involved in an application. Each is rated as simple, average, or complex.
Each rating is weighted to yield the unadjusted function point count. For example, if five files in an application are of average complexity (for which the IFPUG method specifies a weighting of 10), they add 50 function points to the total.
The whole application is rated on 14 measures of overall complexity, which include the degree of distributed processing and the proportion of transactions that involve online data entry. Each complexity measure is rated on a five-point scale (i.e., 70 is the highest score possible). The complexity rating is divided by 100 and 0.65 is
added to yield a factor ranging from 0.65 to 1.35. The unadjusted function point count is multiplied by this factor to obtain the adjusted function point count.
For example, the counting and weighting of files and other items produces an unadjusted function point count of 1000. The application is of significant complexity and the rating of the 14 complexity measures gives a total of 60 points. As 60/100 +
0.65 is 1.25, the adjusted function point count would be 1250.
Measuring Productivity in Function Points Many thousands of projects have been analyzed to build up function point databases, which can be used to compare the effort that went into each project with the number of function points created.
Wide ranges of productivity exist. For example, with inexperienced staff, unstructured methods, ordinary tools, and low-level languages, productivity ranges from 0.25 to 5 function points per staff month. At the other end of the range, with experienced staff, structured methods, power tools, and high-level languages, productivity ranges from 20 to 100 function points per staff month. IS projects generally range from 3 to 50 function points per staff month, and the average is 8
function points.[1]
If a project team can achieve ten function points per staff month, then a 1250-function-point project takes 125 staff-months or ten people a little longer than a year.
If productivity is 20 function points per staff month, then the work can be done in half the time.
Although function points are a reasonable sizing measure, they are not much use in estimating effort unless productivity can be estimated. To do that requires a track record of the project productivity of the staff.
The Value of Project Experience
Despite its importance in estimating, very few organizations have a database of project experience. Instead, experience on a project is in the heads of project team members and is not easy for the manager of the next project to access. Indeed, very few organizations keep reliable figures on the actual hours taken in project development. As automated process management tools become more widely used, it becomes less expensive and easier to use past project history.
A process management tool should help in answering the following questions:
§ Which past projects are similar to the current one?