The Busy Person's Project Management Book

Chapter 8 - Additional Tips for Travellers

Throughout this book, we have been discussing the basic techniques for managing your small projects. By using these techniques, you should find that your project does succeed and that you and your team enjoy the process.

In this chapter, we'll cover some additional techniques that you may wish to use on more complex projects. Sometimes you'll find that a small project in terms of time and effort may still be complex in terms of the changes that it is bringing to your organisation. In addition, we have included a typical list of the people who could provide consultancy and advice to you and your project team.

Analysing stakeholders and related projects

As we covered in Chapter 2, you and your team will generally need assistance from people outside your project and its organisational area. To remind you, some of these people will be the sponsor of your project, the clients or users of the project's deliverables, support groups and other project teams.

For some projects it may be useful to more rigorous in examining your stakeholders and any related projects. In particular, for stakeholders, you should determine which areas or people are the stakeholders, what service or services you require from them, who is the person who is prepared to act as the contact person or responsible agent and whether they are an essential stakeholder. If they are on your critical path (that is for each day they delay providing you with the service, your project is delayed a day) or they are important from an organisational point of view (a senior manager for example), then, you would treat them as essential. There may be stakeholders as well who may be interested parties. These groups may require information about the project as distinct from providing a service. For example, the Finance group may need regular reports on expenditure. Essential stakeholders (or the contact person) should attend all your project planning sessions as discussed throughout this book. Interested parties should be sent copies of your Business Case and any major project reports.

Your project may also have related projects. These are projects that may be either dependent on your project's deliverables or alternatively, may be producing new changes, products and so on that your project requires to be successfully completed. You and the team can identify a similar set of information regarding related projects as for stakeholders.

As for stakeholders, a related project may be related to you by new equipment, funding, resources, data and knowledge. For example, in Mary's project, she has a related project - Office Automation - that she needs to install the computers that she and her team are going to use in her project.

It is important to remember that if you fail to identify all essential stakeholders and related projects during your planning sessions, then they will be extremely difficult to deal with at a later stage as they may not be able to provide the service you require at short notice.

Figure 28 provides a sample form that you can be use to document your project's stakeholders and related projects.

Fig. 28 - Analysing stakeholders and related projects

Analysing and Controlling Quality

Analysing and controlling Quality is a difficult concept for project people. Whereas each one of us has a pretty good idea of what we personally regard as a quality car, shirt, toilet roll or biscuit, we would also recognise that, in this context, quality is a personal thing. It is in the eye of the beholder.

However, as Phillip Crosby [1979] noted, quality is conformance to requirements. If you are concerned with environmental issues then your requirement for a toilet roll is that is is made from recycled paper. If you are a small child then your requirement for a toilet roll that it is strong so that you can get the whole roll off the toilet roll holder without it breaking. In other words, different people have different requirements and, as a result, different definitions of quality. While this is the case in our personal lives (unless you see the choice of toilet rolls as a public issue), you and the team should attempt to define the expected quality for your project's deliverables. This is because many of your stakeholders may have different requirements (i.e. different quality expectations). In Mary's project, for example, the computer people are concerned that the system is efficient while Mary is more concerned about the documentation and the impact of the new system on existing working patterns.

For most projects, quality will be a combination of the following attributes:

• Conformity

  The degree to which the product or service must meet the functional and technical requirements. For example, Mary's new system does not have to have all the changes required at one time to be useful for her clients;

• Usability

  The ease of use and understanding of the new product or service. Mary and her people want the new system to be easy to use and understand without a lot of training;

• Efficiency

  The degree to which the product or service must be efficient in its operation. Mary does not care how slow the system is as long as it is easy to use;

• Maintainability

  The ease with which the product or service can be maintained as delivered by the team. Mary wants the system to be easy to maintain as she will be responsible for keeping the system running;

• Flexibility

  The ease with which the product or service can be changed or enhanced. Mary wants the new system to be easy to enhance as she knows that the statistics area is undergoing a lot of changes that will need to be added to the system;

• Reliability

  The degree of errors and non-operation that can be tolerated by users of the new service or product. Mary has a requirement for a high degree of reliability as the system will be processing essential data;

• Portability

  The need for the product or service to operate in different areas or regions taking into account the differences between these areas. Mary does not need to use the system in other areas;

• Auditability / Security

  The ease with which the product or service can be audited and made secure from illegal access or fraud. Mary does not see a need for these quality attributes in her system;

• Job impact

  The degree to which the product or service disrupts the existing working and social patterns of the clients or users. Mary is very concerned about the new system's impact on her people.

These attributes (and others) may or may not be applicable in your project. By developing a Quality Agreement with your stakeholders during the planning session, you can avoid confusion as to what quality means for your project.

Steps in developing a Quality Agreement

• Step 1 - Evaluate and rank stakeholders

  In conjunction with the team, you should rank the project's stakeholders as essential or interested parties as described earlier in this chapter.

• Step 2 - Determine project's quality requirements

  Using the form in Figure 29, determine in conjunction with the team which of the Quality Attributes are Mandatory, Non-mandatory and Not-applicable.

• Step 3 - Determine and review stakeholder's ranking

  Preferably in a group session, interview each essential stakeholder and review and determine their quality requirements using the same process as in Step 2.

• Step 4 - Derive final ranking

  Evaluate all mandatory Quality Attributes looking for a majority agreement between the team and stakeholders (say, where 80% of the stakeholders agree then the attribute is mandatory for the project).

• Step 5 - Review Quality Agreement with senior management

  The final rankings should be reviewed with your project sponsor and any unresolved conflicts in the stakeholder's rankings should be raised for resolution by senior management.

Fig. 29 - Quality Agreement

The Quality Agreement should be added to the Business Case and you can use the Quality Agreement as another component to review during the Post-implementation Review process.

A Note on Quality Reviews

Having determined the expected quality for your project, you should set up a process during your project to ensure that the various deliverables that you are producing are meeting the agreed quality requirements.

The most common technique for reviewing the quality of a product is a team-based session where the team members assess each deliverable from the point of the Quality Agreement. For example, Mary and her team produce the system specification for her new statistics system. In a quality review, her team reviews the specification from the perspective of Conformity, Usability, Maintainability, Flexibility, Reliability and Job Impact.

These reviews should take about an hour and should focus on finding any major errors. However, be careful here in ensuring that the process is constructive in its criticism. Remember, it is OK for a person to make a mistake. It is also OK to find the mistake. It is not OK to make them feel bad about the mistake.

It is a good principle to have all major deliverables reviewed by at least two people other than the person who produced the deliverable.

Who else can help you?

It is important to look for help when planning and managing your project. You are not alone in grappling with some of the issues that will confront you and your team. There are a number of people and groups within your organisation that can give you advice and assistance. These may include:

• Finance people
• Human Resource people
• Your computer group
• Training people
• Strategic Planning people
• Marketing people
• Internal Audit folks

copyright: thomsett INTERNATIONAL 2008 | contact