Project Management Using OPEN

• By Brian Henderson-Sellers
• December 1, 2001

Project management (PM) is an integral part of software development. Although some OO processes avoid these important, people-related issues, OPEN addresses these fully in terms of Activities, Tasks, Techniques, and Roles that best exemplify practice in PM. Indeed, project management issues have long been an important part of the OPEN mindset.¹ However, the extent to which PM is used depends on whether we are using a heavyweight or a lightweight process (see below) generated from the OPEN Process Framework (OPF).² The OPF is flexible on providing this wide range of PM support.

For a lighter weight OPEN process (Figure 1), an approach which has much merit for many software developments, we might introduce a minimalist set of OPF PM-focussed Tasks associated with the development activities and integrate these PM aspects fully into the system development cycle by associating each PM Task with one or more Activities. This is the approach initially advocated in the OPEN approach (e.g., The OPEN Process Specification³). There are also some occasions, perhaps less common, when a heavyweight process (Figure 2) requires the notions of a Project Management Team and several subteams, with extensive reporting, checking and validation, in which case, the OPEN Process Framework permits you to create a separate Project Management Activity composed of the various OPF PM Tasks. In both situations, the project management tasks and the development tasks are occurring concurrently with each other.

Figure 1 Illustrative "lightweight" OPF exemplar process in which the project management Tasks are integrated within these selected Activities. The sequenced activities shown should be enacted for each increment of the IIP lifecycle.

We'll thus give an overview of the flavor of some of the extensive support in the OPF for PM at this Task level and leave it to the reader (or their friendly process engineer) to decide whether to leave these as Tasks (Figure 1) or to agglomerate them into a PM Activity (Figure 2).

Figure 2 Illustrative "heavyweight" OPF exemplar process in which the project management Tasks are gathered into a new Project Management Activity (after ref. 4).

PROJECT MANAGEMENT
Project management-focussed Tasks in the OPEN Process Framework attempt to cover all aspects of these people-oriented components of software development. Project management focuses on the application of knowledge, experience, tools, and techniques in the context of a single project. The project manager aims to meet all the stakeholder's needs and expectations from the project. Typical components of a project manager's job include project planning, contract management, cost management, customer relationship management, human resource management, resource management, schedule management, and policy establishment.⁴ As noted, each of these may be significant enough (particularly on large projects) to be a stand-alone Activity within the OPF or may be simply part of a single Project Management Activity or, for small projects, be reflected simply by the PM-focussed Tasks integrated into the development-focused activities.

The spread of responsibilities of the project manager is supported by a significant number of Tasks within the OPF. These Tasks are listed in Table 1—here we illustrate PM by discussing only a representative few of them. We concentrate on project planning, human resource management, and schedule management.

Table 1. Project Management Tasks of the OPF.

Undertake feasibility study Undertake project planning (with several subtasks) Establish change management strategy Establish policy on component acquisition Establish policy on COTS Establish policy on outsourcing Manage contract(s) (with several subtasks) Undertake cost management (with three subtasks) Manage the customer relationship (with several subtasks) Manage human resources (with two major subtasks) Identify project roles and responsibilities Choose project team Allocate tasks Manage resources (with three subtasks) Ensure schedule management (with four subtasks) Obtain business approval

Task: Undertake project planning
This task focuses on how to execute the project. Subtasks include: (a) develop the overall project plan—perhaps using PERT, CPM, Gantt charts; (b) develop the iteration plan; (c) develop the contingency plan—for when things go wrong; (d) develop security plan; (e) consolidate and agree project plans—agreement is needed from all stakeholders; (f) maintain plan documentation; (g) communicate plan—to all stakeholders; and (h) execute plan.

The role of the project manager is to identify, construct, and seek endorsement of a variety of planning Work Products—documents that specify the various elements of the project plan. As well as the plan for the technical development of the software, there are various other plans more associated with risk assessment and amelioration. These include the creation of a contingency plan so if/when things go wrong, these problems have, to some extent, been foreseen and alternative actions formulated so that the project does not simply derail at that point. The suite of plans needs to be shared with all stakeholders and agreed by them. Common mistakes are when plans are kept "secret" or become shelfware. It is important that developers and customers alike are aware of the plans available both for normal operation and to cope with possible extenuating circumstances. Remember the context—for OO developments, an iterative, incremental, and parallel (IIP) style is widely advocated. This sets a background somewhat different from that of traditional software development, thus demanding additional project planning skills of the project manager.

Task: Manage human resources
While the OPF Task: Manage human resources, only has two major subtasks (Create an appropriate organizational structure and Project staffing), these are areas not usually included in discussions of software development—yet without successful management of human resources, any project is destined for failure. Project staffing is crucial and seldom done well. Often the project team is a conglomeration of "who is available" whereas all good books on team building (e.g., Belbin^5,6) advise us that personalities need to be positively evaluated and team structures created to take best advantage of the different skills sets, temperaments, and personalities of each individual. In project staffing, we need to consider (i) interviewing prospective staff members; (ii) hiring of new staff; (iii) assigning staff to roles and to teams; (iv) evaluating performance of team members; and (v) specifying individuals' goals to maximize their impact on the team and, perhaps more importantly, to facilitate further development of the individual's skills set.

Task: Ensure schedule management
To ensure timely completion of the project both in toto and its individual milestones, we need to (i) estimate the time of each task and every stage; (ii) develop a schedule based on these estimates, perhaps using timeboxing, (iii) communicate this derived schedule to all stakeholders, not just the developers; and (iv) control the schedule to try to avoid schedule slippage.

An important deliverable from this Task is, of course, the project schedule itself, with its various milestones. Risks also need to be considered in terms of their impact on the project schedule. These are discussed below.

Other groupings of Tasks discussed in Firesmith and Henderson-Sellers⁴ are closely related to PM. These include:

• Risk Management Tasks
• Configuration Management Tasks
• Metrics Management Tasks
• Quality Engineering Tasks
• Process Engineering Tasks

Of these, only the first is solidly in the people/resource area. The other four combine technical considerations in the resource/management context and are not discussed further. (For full details see Firesmith and Henderson-Sellers⁴)

RISK MANAGEMENT
Identifying risks and managing them is a critically important part of a successful project. Risk management (RM), as an OPEN activity, focuses on:

• risk identification
• risk avoidance
• risk mitigation

although it is not always necessary to have this as a separate activity, instead being incorporated, in terms of a set of RM-focussed OPEN Tasks, into ongoing project management. Indeed, risk management should be a normal component of project management. In fact, it has even been argued⁷ that risk management should be regarded as a replacement for project management. This activity/set of RM tasks should result in the creation of a risk management plan. This will identify each risk, ranked from the risk evaluation, together with a decision on an acceptable risk level cutoff. For each risk above this cutoff, an appropriate contingency planning recommendation should be made. This decision comes from compounding the risk level and its impact (if the risk eventuates). A low risk level with little impact is unimportant whereas risks that are either rare with high impact or common with low impact should be seriously considered.

McConnell⁸ lists 10 of the most common risks likely to adversely affect the schedule of a project: feature creep, requirements "gold-plating", shortchanged quality, overly optimistic schedules, inadequate design, silver bullet syndrome, research-oriented development, weak personnel, contractor failure, and friction between developers and customers (in rank order). He also identifies and itemizes more than 100 potential schedule risks.

In terms of the OPEN Process Framework, a number of Tasks associated with risk management can now be identified. These have been documented in the OPF⁴ and include:

• Identify potential risks
• Undertake (formal) risk analysis
• Document risk potential
• Establish risk avoidance strategies
• Mitigate risks

The first three cover the ground named "Risk Assessment".⁸ Risks are first identified and then analyzed, the evaluation being as quantitative as possible. Combining the numbers for the impact on the project, should the risk eventuate, and the probability of this happening, permits a compound numerical assessment of schedule slippage to be ascertained. This then permits these risks to be prioritized in terms of a simple ranking. These tasks are supported by a number of useful Techniques, which we now add to the "OPEN Toolbox". These are:

• Risk exposure
• Estimation of size of loss
• Estimation of probability of loss
• Expected value of schedule slippage
• Schedule buffering
• Top 10 risk list

These are described below.

The last two of the OPEN Risk Management Tasks focus on planning for and executing plans for the resolution of (perhaps by means of avoidance strategies or by risk mitigation) these identified risks. In Task: Establish risk avoidance strategies, we undertake extensive planning based on the risks identified and quantified in the first three OPEN Tasks (or "Risk Assessment"). Risk mitigation involves both mitigation—avoidance and amelioration of risks and their likely occurrence—as well as monitoring the execution of these plans. A useful Technique⁸ is "Top 10 Risk List" (see below). The existing OPEN Task: Undertake in-process review³ may also be useful. In some organizations, a new role is also established: that of Risk Officer.⁸

Risks change as the project progresses. Thus risk management is not a one-off task that is accomplished at, say, the beginning of the project; but one that needs continual reapplication. Furthermore, risks are perceived differently by different groups of people. Thus to get stakeholder buy-in, a questionnaire to elicit relevant risks should not be circulated just to management but to four approximate groups⁷ of:

• techies
• management
• marketing
• users

Responses can then be merged together with appropriate weightings and a true overall picture of pertinent risks painted.

Remember that risk management is like an insurance policy. Paying insurance premiums seems a bind; but when disaster happens, the payout far exceeds the premium and the financial disaster is averted. Just because risks don't turn into reality doesn't mean we should therefore annul them in the future. Rather the reverse. Keep a contingency of resources for the unknown. That buffer of resources will almost always be called on—yet the exact context can almost never be readily identified. Sometimes what is the largest risk does not eventuate, yet the contingency carefully planned for is needed for the realization of a risk initially perceived to be much smaller. Probability is notoriously difficult to come to terms with as a human because the quantitative values pertain to much longer time spans than we can readily comprehend. So keep a contingency explicitly for those risk realizations; explicitly rather than the implicit approach often taken at present in many organizations.

Some New Techniques for OPEN Risk Management
Risk exposure
Risk exposure, or risk impact, is a numerical value which expresses the product of the size of loss and the probability of that loss occurring. In terms of schedule impacts, we can express the product in terms of weeks. So for instance, if a 50% likely risk has an expected 4 week schedule slippage, then the risk exposure is 0.5 x 4 = 2 weeks.

Estimation of size of loss
To calculate risk exposure, the size of the loss for each risk must be evaluated. For many risks, this might be easily established. For instance, if a committee that must approve the next budget meets only every two months, and one meeting is cancelled or missed by one day, then the estimated size of loss for this risk is two months. If such an estimate is hard to obtain for the risk, then perhaps the risk can be broken down into smaller losses and these then estimated more easily.

Estimation of probability of loss
Estimating the probability of the loss is a second component to risk exposure evaluation. It is generally harder to assess probabilities than it is the size of losses because it tends to be more subjective. Some ways to facilitate this assessment include (i) have a person familiar with the system do the estimation and then hold a review session; (ii) use a Delphi approach; (iii) use a betting analogy; or (iv) ask people to describe the risk using an adjective chosen from a set such as "highly likely", "very good chance", "probable", "likely", "improbable", "unlikely", and "highly unlikely".⁸

Expected value of schedule slippage
The expected value (a statistical term) is the product of the probability and the size. Summing all these values arrives at a figure which represents the expected value of schedule slippage (without any risk management). This calculation should be repeated whenever any risk mitigation is performed.

Schedule buffering
Starting with the expected value of schedule slippage, it would seem reasonable to build this value in to the schedule as a schedule buffer. This should then be recalculated following any risk management strategies that are put in place. An alterative⁸ is to publish a schedule with error bars associated with each risk and then adjust the schedule if/when one of these risks eventuates.

Top 10 Risk List
Construct a list of top 10 risks based on the quantitative assessment undertaken initially. Update this week by week. Have columns for "This week's ranking", "Last week's ranking", and "weeks in list" using as a metaphor the best selling lists for books or CDs. For each risk so-listed, include a column describing the progress of the ongoing risk resolution.⁸

SUMMARY AND CONCLUSIONS
Project management, including risk management, provides an important element of any OO process or methodology. Large projects particularly in a safety-critical environment need more formal PM directives (i.e., as a separate Activity); smaller, less critical projects may be able to have PM Tasks integrated into other OPF Activities. Here we have described not only these two options and some of the supporting Tasks from OPEN, but also identified some new Tasks and Techniques, particularly associated with risk management (RM), that we add to the OPF Repository.

Acknowledgement
Thanks to Richard Dué and Bhuvan Unhelkar for reading and commenting on an earlier draft of this article. This is Contribution no 01/15 of the Centre for Object Technology Applications and Research (COTAR).

References

1. Dué, R.T. and Henderson-Sellers, B., 1995, The changing paradigm for object project management, Object Magazine, 5(4), 54–60, 78.
2. Henderson-Sellers, 2002, "Agile or rigorous OO methodologies—getting the best of both worlds," Cutter IT Journal, 15(1).
3. Graham, I., Henderson-Sellers, B. and Younessi, H., 1997, The OPEN Process Specification, Addison–Wesley, UK, 314pp.
4. Firesmith, D.G. and Henderson-Sellers, B., 2002, The OPEN Process Framework. An Introduction, Addison–Wesley, Harlow, UK.
5. Belbin, R.M., 1981, Management Teams. Why They Succeed or Fail, Butterworth Heinemann, Oxford, 171pp.
6. Belbin, R.M., 1993, Team Roles at Work, Butterworth Heinemann, Oxford, 141pp.
7. Lister, T., 2000, "Risk management," keynote address at Software Developers 2000 Conference, 20–22 March 2000, Software Education Associates Ltd., Wellington, NZ.
8. McConnell, S., 1996, Rapid Development, Microsoft Press, Redmond, WA, USA, 647pp.