The form contains nine questions whose objective is to guide you through the general areas that should be covered. It is simple to add more questions to the form to cover the specific issues that are relevant to the project. However, before doing this you should consider whether there will be time available during the interview to capture more specific information. Most interviews will be one hour or less in duration. This gives you about five minutes a question (based on the template form) with a few minutes to cover introductions , getting coffee, etc. Practically this means that if you want to add questions then you probably need to remove the equivalent number of questions from the standard form. If you feel that you do want to remove questions then you should be careful in their substitution.

None of the questions in the standard form are very specific. This is achieved through careful design. They are designed to ensure that the interviewee is encouraged to talk. The assumption behind the questions is one of listening and understanding. It is worth remembering that this is not formal requirements capture. This activity is designed to enable you to gain a general understanding of what is desired by senior managers. Questions like ˜What should the colour of the building be?' or ˜What should the user interface on the program look like?' won't help you to gain that understanding.

Once the basic ideas have been captured they should be put together in a list. This list then forms the initial baseline that you should work towards. You should pass a copy of the completed form and the associated wish list back to the senior manager concerned to allow the manager to correct misinterpretations.

When all of the key senior managers have contributed to the wish list you should publish a final list. This list should be passed to all of the people interviewed, which should include all the members of the project steering group . When this list is published you will have accomplished an important milestone. For the first time you will be able to state publicly the key objectives of the project including the target time line. Importantly, you will be able to back the statement with support from the organization's principal project sponsors. The next stage is to refine and develop that list into a high-level target plan. This is the start of the formal requirements capture process.

Capturing the requirements

Many organizations have departments who are dedicated to defining and capturing requirements. Other organizations operate on an ad hoc basis, setting up meetings on an ˜as needed' basis. In both types of organization you will need to take on a coordinating role. In an organization where a requirements department is available this role will be much simpler. However, as with many other areas of advanced projects it is unlikely that the department will have processes set up specifically to cover advanced projects.

When an organization does not have a requirements capture department you will need to lead the process yourself. One of the simplest but most effective ways of capturing requirements is the use of brainstorming sessions. There are many different brain- storming techniques available and many consultancies happy to run sessions for organizations unsure of the process. Whilst external parties can add significant value it is probably sufficient at this stage to run the session using in-house resources. Later, once the direction is clearer, external help could be sought.

Running a brainstorming session is something that you should be capable of. It is a key technique that will be used repeatedly in various forms throughout the course of the project. The technique described below is simple. This makes it easy for participants in the session to understand their role and what is expected of them. This helps to ensure that they are concentrating on the outcome of the session rather than the methodology that the brainstorm session is using. Participants focused in this way normally are able to produce good results that centre on the question being asked.

• Step 1

  Prior to the meeting you should send each participant a copy of the senior management wish list. You should also send them a copy of the brainstorming technique explanation sheet included on the CD ROM.

  At the start of the session you should gather all the participants together and explain how the brainstorming session will work. You should explain that at the end of the session you would like to have gathered a high-level task list. This task list should enable the project to produce a plan that will deliver the senior managers' wish list. Therefore you require:

  • a proposed task;

  • timescale for the task;

  • likely cost for the task, in terms of people and equipment.

  It is worth while reassuring the participants that it might not be possible to cover the whole project in one brainstorm session. You should explain that if this happens then you will arrange a further session to enable the brainstorm to be completed.

• Step 2

  Give each person a small pad of paper and a thick marker pen. Ideally each person should have their own identifiable colour. You should ask everyone to write one requirement per page on the writing pad they've been given. Each idea should be expressed in a few words. Participants can use as many or as few pages as they wish. However, they should write down all of the high-level or overview requirements that they can think of.

  This process should be allowed to continue for between 10 and 15 minutes. This is usually long enough for the brainstorm meeting participants to run out of ideas. Participants are allowed to write anything on the pads of paper. Ideas can include process, timescale, costs, risks, people issues and of course scope.

• Step 3

  When participants have exhausted their ideas, ask them to stick the individual pages on to a designated wall. This can be done with tape or sticky tack. Ideally, pads with sticky backs should be used. The ideas can be placed anywhere on the wall although it will speed up the process if like ideas are grouped together.

• Step 4

  After all the notes have been placed on the wall you should ask one or two members of the group to sift through the pages and order them into groups of like ideas. Now the wall should be covered with a series of groups. Some of the groups may only have one member.

• Step 5

  Once the sorting is complete the team should collectively audit the grouped ideas. Whilst doing this the group should ensure that they understand the ideas by questioning the author. Often this will result in the addition of timescales and resource requirements. The participants should ensure that the pages are grouped in a manner that all of the attendees agree with. They should add a name for each task grouping.

• Step 6

  You (or someone nominated by the brainstorm team) should gather together the groups of ideas and translate them into a form that explains the rationale behind them. This should be done outside of the brainstorm session. You should now have a list that outlines a series of high-level requirements. This should include both the task to be completed and the target timescale for its completion. You should now send the output to the brainstorm meeting participants for comment and review.

The whole process is shown diagrammatically in Figure 2.2. Initially, a template, Figure 2.2(a), is given for the capture of the various tasks that will need to be completed. These are then written on pads of paper, Figure 2.2(b), and then the papers are grouped together on a wall, Figure 2.2(c). Finally the task groups are translated into a simple schedule, Figure 2.2(d).

Figure 2.2: Target plan creation

It is worth remembering that at this stage the requirements will be written in their simplest form. Detailing them will happen during the next phase of the project when the detailed plan is produced.

The simplicity of this technique masks the underlying expectation management. It tackles this in three ways. Firstly, it ensures that ideas are captured in the words of the author. No idea is perceived to have been changed in the capture process. Secondly, all of the voices in the group are heard . The ideas from the less vocal members of the group are as visible as those of the more forceful members. Thirdly, everyone feels that their idea has added value to the process since it ultimately contributes to one of the final task groupings.

If the work was carried out by an internal requirements capture department there should be a similar list to the one produced by the brainstorm session. Whichever list is available it should provide a series of tasks and associated timescales. It should now be translated into a simple schedule and published to a wider audience for comment. When resource or quality requirements have been identified these should be included with any material sent out for comment. The audience should include any technical authorities within the organization or other groups that may be involved in successfully delivering the project. The recipients should be asked to consider the proposed timescales, the desired scope and the associated risks. Their remit is to check whether the schedule can be developed into a reasonable plan. The plan sent out for review should look something like the one shown in Figure 2.2(d).

This is only a sample plan and you should expect that your plan will have more activities. The number will be defined by the number of task groups resulting from your brainstorming session. You should, however, consider carefully the needs of the audience of this plan. There are likely to be two types of reader: firstly, senior managers who want a high level understanding of the project and, secondly, more junior managers who want a more detailed understanding of the project.

The senior managers need a one-page picture of the key events that will happen over the project lifetime. This means that if your current set of task groups won't fit on to one page you should consider combining some of them. For example, you could set task group 1 as the initial design specification, task group 2 as the building of the new building, task group 3 as the fit-out of the new building, task group 4 as the transfer of staff and task group 5 as the commissioning of the building.

The more junior managers will be interested in the one-page picture as well but they will also need the explanatory notes. You should produce these notes in accordance with your interpretation of the brainstorm session. They should enable the reader to begin to understand what is being sought and enable them to make a better judgement about scope feasibility. It is also helpful to supply these managers with a copy of the initial senior managers' wish lists.

Although it is possible that you could gain agreement to this outline plan by simply sending it out for comment, it is unlikely. Instead to enable you to reach a plan that is accepted by the various stakeholders you should set up a review schedule. This schedule should set out the timing of several review iterations. Each of the iterations should include some time for comment and then some time for upgrading the document prior to it being sent out for further comment. For an advanced project you should plan on between three and five iterations. You should encourage iterations to happen quickly. Those involved in the review should be encouraged to adopt a best-guess approach; accuracy will come later.

Each round of commenting will result in more detail being added to the overall plan. This will mean that a deeper understanding of each task grouping will be developed. You should be able to develop a schedule that represents each task grouping leaving you with a more detailed plan at the end of the iterations. This plan should be sufficient to allow the initial planning and estimation of resources, which is the next stage in the development of the macro plan development.

Estimating the resources

The planning and estimation of resources should, where possible, be undertaken by the line units that will carry out the work. Ideally these units will have experience of similar work in previous projects. This experience will help to improve the accuracy of the developing plan. Working in this manner also helps to ensure that the units have the opportunity to influence the work. This helps the units to feel part of the overall project and ultimately part of the team.

At this stage the purpose of estimation is to gain a high-level assessment rather than an accurate detailed plan. As a result, those estimating should be encouraged to be quick and coarse in their estimation. To help those estimating, a simple estimating technique should be used. Those estimating resource levels should be sent the form shown in Table 2.1 to complete and return.

There are two main types of estimators, those with a pessimistic view and those with an optimistic view. When estimating tasks, people generally fall into one of these two categories. The form is designed to overcome these natural tendencies, by enabling estimators to put down a range of estimates. Estimators are also asked to include an analogy assessment in addition to the three-point estimate: best case, most likely case and worst case.

An analogy estimate is simply a method of estimating based on previous or historical data or experience. Analogy data are very important for the project manager. It is the analogy assessment that enables you to make a judgement about which estimate to use. For example, if the analogy is DB (done before) then you can with a degree of confidence use the most likely estimates. Conversely if the analogy is NB (not done before) then you might choose the worst case estimates. This is the simplest approach to picking which estimate to use.

A more comprehensive approach can be achieved by determining the nature of the estimators. The easiest example is for estimates classed DB. If the task has been done before then the range given should be small or non-existent. So if the estimator has given a large range then it's reasonable to assume that the estimator is highly cautious in nature. However, care needs to be taken not to assume that the opposite is true. If the class is DB and the range small then this doesn't mean that the estimator is optimistic; it's more likely that the estimator is realistic. To discover optimistic estimators, the ND classification should be examined. If the range is small then it's likely that the estimator is being optimistic.

Armed with the estimates and knowing the nature of the estimators, you are now able to build the first draft of the project plan. This plan will still be a best-guess plan but the estimation technique and the process to get to this point mean that the plan is likely to be a reasonable representation of the final plan. Once you have completed the first draft of the plan you should send it to the various team members involved so far, for review, comment and in due course agreement.

You should treat this plan in a similar manner to the requirements that you generated previously. This means that you should set up an iterative review whose objective is getting the plan agreed.

Once the estimated plan and the requirements have been completed and agreed two additional parts need to be added to complete the macro plan: a quality statement for each task group and a high-level resource plan.