Congratulations! You've just been designated the project manager of your first CORBA project! "Help!" you say? Even though you may not have any CORBA experience at all, you needn't panic. This article describes how you can grab this bull by the horns and guide your project to a successful completion. Not only can you survive your first CORBA project, but you can do everything in your power to make it a success. Luck isn't the missing ingredient knowledge is.
This article describes how I approached my first CORBA project and my second. It also describes how I'd approach my next CORBA project, the next one, and so on. This article is based loosely on Steve McConnell's award-winning books Software Project Survival Guide and Rapid Development (see References 1 and 2). They provide some additional discussion of the approach described here.
The Project Charter
I start a project by clarifying its "charter." At a minimum, the project's charter defines its goals, objectives, completion criteria, resources and constraints. It really doesn't matter what form the project charter takes, such as a formal document, a memo or even an e-mail message. The critical point is that the project manager and the project team have an explicit agreement with the project stakeholders over what constitutes project success.
The Risk Assessment
The second step in the project is the risk assessment. In this step we try to identify the major stumbling blocks that could prevent the project team from achieving success.
Risk can be defined as "the possibility of an unwanted consequence of an event or decision." There are two important components of this definition. First, unlike the financial markets, software project risk is not a good thing there's no upside to it. Second, software project risk is a probability. A "problem," however, is a certainty; it's a previously known or unknown risk that has already materialized.
The steps in a risk assessment are as follows:
- Risk identification
- Risk analysis
- Risk prioritization
The most abstract, highest-level risks are the same on every project:
Except for outsourced projects, it ends up being impractical to deal with software project risk at this high a level. It's necessary to drill down one level and ask, "Why might the project experience a cost overrun?" "What are the reasons why we might experience a schedule overrun?" etc.
- Cost overrun
- Schedule overrun
- Quality underrun
- Functionality underrun
One effective way to identify risks is to start with a list of generic software project risks. Several such lists are available, including one at www.construx.com (click on Software Resources, then Software Development Checklists, then Complete List of Schedule Risks). Let the team identifying risks select those candidates that warrant further investigation from the generic list. Don't limit risk candidates to what's on the prepared lists. Be willing to consider any factor about the project that could cause difficulty. Generally speaking, project risks relate to the following project characteristics:
Since this is probably your first CORBA project, it's likely to be everyone else's as well. Some common CORBA-specific technology risks for first-time projects are:
- The product itself (complexity, size, the "ilities," such as reliability, portability, etc.)
- The processes, tools, techniques and technology being used (e.g., CORBA)
- The project team itself (size, abilities, desires, team cohesion)
- Parent organization(s)
- Supplier(s) and subcontractor(s)
- Lack of project team familiarity with CORBA and/or the specific ORB product
- Immaturity or instability of the ORB products
- Not meeting performance requirements (e.g., insufficient network bandwidth)
In risk analysis the probability and severity of each candidate risk is estimated. The probability estimate is a judgment of how likely we think it is that the risk will turn into a problem. Probabilities can be estimated using any number of scales, from a simple "low-medium-high" scale up to a numeric probability. For example, "If nothing is done to prevent it, there is a 40% probability that our lack of familiarity with CORBA will become a problem for the project."
The severity estimate is a judgment of how much difficulty the project would incur if the risk were to turn into a problem. Estimating the severity for each candidate risk is similar. You can use the simple low-medium-high scale again or you can estimate the dollar-cost for what it would take to deal with the problem. For example, "If our lack of familiarity with CORBA did turn into a problem, we believe it would cost us about $50,000 to recover from it." The recovery costs could include bringing in an outside consultant, delayed deliveries because of missed milestones, and so on.
Practically speaking, the project team can probably handle active control of between a half-dozen and a dozen risks. It's not uncommon for the previous risk identification step to identify two or three dozen candidates. The risk prioritization step is used to figure out which of the candidate risks will be actively controlled and which will be deliberately ignored. The "risk exposure" for each candidate risk is calculated and the risks are then rank-ordered by exposure. Risks that carry a high exposure will be actively controlled, while those with low exposure can usually be safely ignored.
When probability has been estimated in terms of percentage, and the severity has been estimated in terms of dollar cost, the exposure for each risk is simply the probability times the dollar cost.
For example, the lack-of-CORBA-familiarity risk, with a probability of 40% and a severity of $50,000, leads to a risk exposure of $20,000. If the immaturity/instability of the ORB product had a probability of 10% and a severity of $100,000, the risk exposure on this risk is $10,000. We should be more concerned about controlling the CORBA familiarity risk than the immaturity/instability risk.
When the probability and/or severity are estimated in terms of a simple low-medium-high scale, the prioritization is less straightforward. Clearly, a high probability/high severity risk carries a higher exposure than a low probability/low severity risk, but judgment will be required to prioritize a low probability/high severity risk relative to a high probability/low severity risk. The important thing is not to have precisely calculated risk exposures. Rather, it's to understand which risks are more important and warrant more effort and attention.
Once the candidate risks have been rank-ordered by exposure, the list is examined from the top down (from the highest exposure to the lowest) to decide which risks should be actively controlled.
I've also found it useful to consider software project "assets," which are like inverse risks. They are characteristic of the project that the team should be careful to take advantage of. For example, a very tight set of customer requirements that must be precisely satisfied could be considered a project risk. On the other hand, maybe the customers are much more flexible and willing to give the project team significant control over the detailed requirements. The flexibility offered to the team is an asset that the project team should be aware of and take advantage of.
Asset assessment can be performed alongside risk assessment, since it follows the same steps. The generic risks can also be considered candidate assets. For instance, a large, geographically dispersed project team would be a risk whereas a small, colocated project team would be an asset.
The probability that the asset will turn out to be useful can be estimated as the risk probabilities are being estimated. Similarly, the asset benefit, that is, the value to the project team if the asset were realized, can be estimated alongside the risk severities. Finally, the assets are rank-ordered in terms of potential benefit exposure (probability times consequence or some similar formula) and a decision is made about which assets will be managed actively.
The Project Plan
The third major step is to develop the project plan. The most important thing to remember while doing the planning is that every activity in the plan, and the level of formality that those activities will be performed at, should be selected carefully to:
In short, every part of the charter, as well as every high-priority risk and asset, must be addressed adequately by one or more planned actions or activities, and every planned action or activity must be there to help satisfy the charter, control risks or maximize assets. Some project teams have taken the extra step of developing a "traceability matrix" to verify the consistency between the project plan and the charter and risk/asset assessment.
- Help the project satisfy its charter.
- Help the project control a high-exposure risk.
- Help the project maximize the benefit of some asset.
The sample traceability matrix in Table 1 shows, for example, that Charter component 2 (whether it's a goal, resource, constraint or asset) is being addressed jointly by Plan components 2 and 6. Similarly, Plan component 3 is in place to address Assets 1 and 2. In this format any empty row means that a charter component, risk or asset isn't being addressed by the current plan. An empty column means that a plan component isn't addressing any charter component, risk or asset.
To the extent that a charter component, risk or asset isn't being addressed by planned activities, the project has a much lower probability of successful completion. Your chances of surviving this project have been reduced. Similarly, to the extent that the planned activities don't address the project's charter, risks or assets, the project team will be wasting its time. Time spent on these activities won't carry any benefit for the project team and may prevent it from doing things that would benefit the project. Given the tight constraints that the typical software project operates under, we should be very sensitive to wasted effort.
To illustrate the variation in process formality based on risk, consider that a large, geographically dispersed project team would probably benefit from a formal approach to configuration and change management, while a small, colocated project team may find an informal approach entirely sufficient.
I start the detailed project planning with the project charter and the list of high-priority risks and assets, together with a project plan template that identifies the basic planning components. Table 2 is a high-level view of this template.
Planning to Control Risk
There are four basic strategies for controlling any given risk:
- Avoidance: Act to make the probability go to zero (i.e., make it impossible)
- Mitigation: Act to reduce the probability and/or the severity
- Transference: Push the risk onto someone else
- Acceptance: Develop a contingency plan for handling the problem should it occur
(More information on risk management can be found in References 3 and 4.)
As there are probably some fairly obvious CORBA-related risks on your first project, we can think about specific actions to control them.
- Lack of development team familiarity with CORBA and/or a specific product:
1. General CORBA training (see the OMG Web site at www.omg.org) free training is provided for OMG member organizations five times per year at OMG Technical Committee meetings.
2. OMG's "Ask the Experts" forum
3. Specific ORB and Services training from the vendor
4. Expert consulting help from the vendor or a knowledgeable professional consultant
- Immaturity/instability of ORB and/or Services products
1. Early prototypes to determine ORB/Services stability
2. Contact other users of the same vendor product
- Not meeting performance requirements (e.g., insufficient network bandwidth)
1. Early prototypes of performance-critical code sections
2. Expert consulting with the ORB vendor regarding performance tuning
Tracking and Oversight
Planning the project is one thing. Guiding the project to successful completion requires more. It takes careful monitoring of the project's ongoing performance, comparison of the project's actual performance with the expected status as derived from the plan, and the careful application of corrective actions when significant differences between the actual performance and the plan are discovered. The corrective action could include an entire replan of the project if one or more of the basic planning assumptions turns out to be incorrect.
Ongoing Risk Management
The project manager needs to understand that risks (and assets) have a lifetime. The earliest lifetime phase is where the risk is known but it's too early for it to become a problem. As an example, consider the risk of a lack of ORB knowledge. Once the use of CORBA has been decided, we can identify that risk. But until the ORB product is selected, it's impossible for the risk to materialize. The middle phase is where the risk has a nonzero probability of materializing. The final phase is where the risk has actually materialized as a problem or its probability has gone back to zero. At some point either the project team's lack of ORB knowledge has materialized as a problem or the team has obtained adequate knowledge so it's no longer a problem.
The point is that we can't view the project's risks as being static. It's important for the project manager, and the team as a whole, to keep in mind that some active risks will disappear at certain points in the project and other new, previously unrecognized risks may come into play. Since major changes in the risk landscape are most often associated with major project phase changes (e.g., moving from requirements to design or from design to code), it's recommended that the project team reassess its risks (and assets) at every major project milestone.
As existing risks (and assets) are retired and new ones are discovered, it's vitally important that the project plan be modified to account for those changes to maintain the traceability of the project's charter, risks and assets and the current project plan. It's also possible that the project's charter may undergo change over the course of the project. Again, it's vitally important to the survival of the project that any significant changes to the charter be matched by corresponding changes to the project plan.
A Summary of the Approach
This approach really suggests the adoption of a "project development lifecycle" that's similar to the more familiar software development lifecycle as shown in Table 3.
The project charter establishes the ground rules for the project. The risk and asset assessment is used to discover the important characteristics of the product and the organization(s) working on it. This is the basis for developing the project plan. If the same charter were given to different organizations, different project plans would likely result owing to important risk and asset differences between the organizations. Execution of the plan results in producing a system that satisfies the given charter in light of the known risks and assets. And just like ongoing software product maintenance, the project plans will likely need maintenance due to recognized changes in the project's circumstances.
Results of Using This Approach on
My First CORBA Project
In January 1997 I was assigned to my first CORBA project as its manager. The project involved developing a set of CORBA performance benchmark applications to investigate the use of ORBs in high-performance, safety-critical avionics applications. While I had significant personal experience with CORBA, having been involved with the OMG since 1993, the other project members had none to speak of. As a team, we documented the project's charter, assessed our risks and assets, and built a plan consistent with the particulars of this project. Partway through the project it was decided (outside the project team) that one of the benchmark applications should be subcontracted out to a neighborhood software vendor who also had no significant CORBA experience. Again, we chartered the vendor project and walked the vendor through the risk and asset assessment. We then helped them develop an appropriate project plan (which, by the way, was significantly different than our plan for that part of the project). In the end, the benchmark applications were delivered on time and, in fact, under budget.
Beyond CORBA Project Survival
What's the difference between the way I managed my first CORBA project and how I'd manage any software project? Very little. The only substantial difference is in the candidate risks and assets to be considered. In the CORBA project case we considered risks about the use of a technology we might not have used before. Similar risks would be encountered on your first Java project, your first DCOM project or your first anything project.
This approach to project survival was initially developed while I was obtaining my MS in software engineering at Seattle University. It's been used successfully, starting with my senior capstone project (a six-person/year project demonstrating agent-oriented applications) up to and including the redevelopment of the corporate employee records system at a major manufacturing corporation.
At this level of actions and activities in a project plan, the message should come across that there's no one-size-fits-all software project methodology. Nor could there ever be, despite what some methodology vendors would like us to believe. Only when the specific actions and activities in the project plans are tuned to the peculiarities of the project at hand (i.e., are directly related to the charter, the risks and the assets) will the project be capable of performing in an efficient and effective manner. Only then will you stand the best chance of surviving your first CORBA project or, in fact, any project.
- McConnell, S. (1996). Rapid Development. Microsoft Press.
- (1998). Software Project Survival Guide. Microsoft Press.
- Boehm, B.W. (1989). Tutorial: Software Risk Management. IEEE Computer Society Press.
- Fairly, R. (1994). "Risk Management for Software Projects," IEEE Software, May.
Steve Tockey is vice
president of consulting at Construx Software and has been employed in the software industry since 1977. Steve has an MS in software engineering from Seattle University and a BA in computer science from the University of California, Berkeley.
He can be reached at [email protected].