The Busy Person's Project Management Book

Chapter 3 - What else to consider

As with all journeys, there is more to consider when you're planning than the objectives, scope and who else needs to be involved. You have to plan your finances, the itinerary, stop-overs and insurances, for example.

In projects, there are similar factors that you and the team have to consider before you begin the project in earnest. In this chapter we will concentrate on two factors - risk and project strategy - and in the next chapter, we'll examine tasks, estimates and schedules.

Risk assessment

The concept of risk should be familiar to all of us. When you are planing an interstate business trip, you check out if there is the likelihood of a refueller's strike; whether fog or rain could delay the planes; whether there is enough time from when the plane lands to your making your appointment and so on. In other words, you undertake a risk assessment. Risk assessment is the identification of factors which can affect the probability of success for your project. The more likely the possibility of rain or a strike, the higher the risk of the journey and the lower the probability of you making the meeting on time.

While the process of risk assessment in our everyday activities is generally done "in our heads", in project work, it is important to examine the risks in a open and documented manner.

In projects, there are three distinct areas or categories of risk:

• Product Risk

  This category of risk deals with the product or service that the team is developing in the project. Some products are simple and therefore low risk while others are complex and of higher risk. For example, Mary and the team who are developing a new computer system and revised statistics processing cycle are working on a product (the new statistics system) that is not complex, is based on existing procedures and does not require processing a lot of data. Therefore, the team perceives the product to be relatively low risk.

  The product risk can be assessed by considering factors such as:

  • how innovative is the product?
  • are the requirements well understood and stable?
  • the complexity of processing or procedures involved in the product? and
  • are there high expectations for product performance or quality?
  
  
• Team Risk

  Different teams have different skills and experience and it is important that you honestly look at the team and its members to determine whether there are some risks associated with the team and the team process. For example, Mary and the team have not worked together before, there are a couple of inexperienced computer people on the team and the project has very tight deadlines. In this case, the team assesses themselves as a high risk team.

  The team risks can be evaluated by considering factors which include:

  • how experienced are the team members?
  • are they full-time on the project?
  • do they have management support? and
  • do they have a common working area?

  Don't worry about declaring your team to be a high risk team. It doesn't mean that you are incompetent or "out of control", it simply means that you are undertaking a new and demanding project.

• Target Area Risk

  As we discussed in the earlier chapters, projects change the way people work and the people and areas who are affected by the project (some of the stakeholders) can be considered as the "target" area. In Mary's project, the changes are primarily directed to Mary and the people she works with in the Industry Statistics Section and to Bill and his publishing group. They are all positive about the new system and are prepared to work with Mary's team. Mary and her team assess the target risk category as low.

  Target area risks can be evaluated by considering such factors as:

  • are the people impacted by the project supportive?
  • are there a number of different stakeholders?
  • are the stakeholders involved full-time or in an ad-hoc fashion? and
  • is the project going to significantly alter existing work flows?

  Again, it is important to be honest about your evaluation of this risk category. Having a high risk target area does nor imply that they are a rabble or that they are going to sabotage your project. It means that there is a need to carefully support the people and to work with them to ensure that the project succeeds.

Once you have evaluated and agreed on the risk factors and their score (Low, Medium or High), you can then come to an assessment of the overall risk of your project. In the case of Mary's project, the product was Low risk, the team was High risk and the target area was assessed as Low risk. Overall, Mary's project was considered as Medium risk because the team is an important factor in any project but the High team risk was offset by the Low risk in the other two categories.

A sample risk assessment questionnaire is included in Appendix C and you can use it as a basis for formalising the risk assessment for your project.

The Risk Assessment Process

As with all activities in planning and managing your project, the risk assessment process should be undertaken with your team members and, if possible, the stakeholders for your project. This is very important as different team members will have different views on the risks of your project.

Fig. 8 - Different people see different risks

What is really important is that the risk assessment is undertaken in a democratic fashion. The best way for you and your team to undertake a risk assessment is to copy the form in Appendix B for each member of the team and, if possible, any key stakeholders. Each person answers the questions on the risk assessment form and then in a team session, you discuss the answers and see if you can reach agreement on the risk factors.

Given that risk is generally subjective and personal, you will find that after the discussion, there may be still some risk factors upon which you cannot agree. In this case, you vote and the majority wins.

If you have a tied vote, then the worst case wins. For example, two team members see the project as Low risk and two see it as Medium, then the project would be treated as Medium risk.

It is also very important to note all high risk factors and to discuss with your team, stakeholders and project sponsor any actions that you and the team can implement before the project starts to reduce and manage the high risks. The capability of pro-active reduction of risk before the project starts is a very powerful aspect of formal risk assessment.

In Mary's project, because the computer people are inexperienced and the project has tight deadlines, some possible actions that she, in conjunction with her project sponsor, could implement to reduce the risk of the project are to negotiate a smaller scope and objectives for the project by producing a system that only processes certain key statistics, to get some training for the computer people and to see if there is a computer expert that the team can use as a consultant.

As we'll discover in the next chapter, the risk of a project has an effect on the estimates as well as on the probability of success. Further, the risk of a project influences the choice of the project strategy.

Project strategy

When planning a journey, you face a choice as to how you organise your overall approach to the trip. For an overseas trip you may decide to visit as many countries as possible spend a couple of days in each place. Alternately, you may buy an open ticket which enables you to spend as little or as long as you wish in any country. You may decide to quickly visit one area to check it out and then plan to return to that area for a longer stay later in your journey. Another option is to take an organised tour that spends only three days in each area.

In projects, the overall approach is called the project strategy. Put simply, the project strategy is about whether the project is done as one whole unit or broken into sub-projects. There are four basic strategies which can be used for small administrative and computing projects. These strategies have been developed in other industry areas such as construction and manufacturing which have extensive project management experience.

Let's assume that in Mary's new project, the basic activities that will be required are Analyse Requirements (interview people, examine existing procedures, to determine the requirements for new software), Design Solution (examine alternative mechanisms, procedures, forms design, etc to select an appropriate processing design), Build Solution (develop new procedures, systems, training programmes, etc) and Implement Solution (install new procedures, train people and convert existing forms, etc).

Monolithic Strategy

This strategy involves undertaking each development activity in sequence developing the product or service as a whole. Each activity is completed and reviewed before the next activity starts. While each activity such as Analyse Requirements may be broken into smaller tasks (see Work Breakdown in the next chapter), all activities associated with Analyse Requirements are completed before any of the Design tasks are commenced.

Fig 9. - Monolithic Strategy

This strategy is suitable for Low risk projects where the requirements are stable and the project environment is not likely to change during the project.

Sequential Release Strategy

In some projects, it may be more advisable for you to partition the project into smaller sub-projects and to implement the new product or service that you are developing as a series of small increments or releases. In this case, you have the choice of two strategies - sequential or concurrent release. The sequential release involves breaking the project's requirements into segments and developing one segment first using the monolithic strategy as shown in Figure 10. Once the first segment is implemented, the team moves to the next segment or release.

Fig.10 - Sequential Release Strategy

In our example project, Mary could develop new procedures only for a sub-set of the processing (for capturing the basic data, for example), implement those procedures and then begin another project (release) on the more complex statistics analysis. Alternately, she could develop all procedures for all statistics processing but Release 1 only handles certain key industries with Release 2 adding the other industries.

This strategy is suitable for most projects where you can negotiate the delivery of partial products or services and there are some deadline constraints.

Concurrent Release Strategy

Concurrent release is an alternative to sequential release where the various sub-projects and product components are developed concurrently as independently as possible. As shown in Figure 12, you can schedule as many sub-projects or releases as you can staff the project. There are some additional project management costs in this strategy as each release has its own scope, objectives, risks and so on.

Fig. 11 - Concurrent Release Strategy

This strategy is suitable for all types of projects where you can break the project up into releases and you have the people to staff each release.

Fast-track or Evolutionary Strategy

This strategy is the most controversial of the project strategies as it involves developing a version of the product, procedures or services as quickly as possible then after reviewing the first version while it is being used it is enhanced and improved through another fast-track project/release. It is inherent in the strategy that the quality of the early releases of the product will be lower than in the other strategies and that refining and improving the product's quality while it is being used is more expensive.

However, for high risk projects such as innovative products or products with dynamic requirements, this strategy is quite successful. The proviso here is that all stakeholders and the project sponsor must be comfortable with the use of this strategy and it's quality problems in the short term. The other danger with using the fast-track strategy is that it becomes an excuse for lack of planning and rushed delivery. You still plan and control a fast-tracked project - you only cut corners that make sense.

Fig 12 - Fast-track or Evolutionary Strategy

You should treat the choice of the project strategy as one of the most important decisions taken during project planning. As we'll explore in Chapter 7, the changing of project strategy, from monolithic to sequential release, for example, is a powerful technique for dealing with project changes.

copyright: thomsett INTERNATIONAL 2008 | contact