THE MACRO PLAN | Advanced Project Management: A Complete Guide to the Key Processes, Models and Techniques

Macro plans vary in length depending on the size of the project. The first draft of a plan can often be substantial, perhaps as large as 50 pages in length. This is too large, and the author, in this instance the project manager, needs to reduce the plan in size . An average length for an advanced project is between 3,000 and 6,000 words. Keeping the plan to this length makes it quick to read and also forces you to be succinct. This is important since the principal readership of the macro plan will be senior executives. These executives will have little time available and so will want to be able to understand the macro plan for the project quickly.

A well-written macro plan presents its reader with an overview of the project, enabling them to grasp its fundamental purpose and its objectives. It should explain how you, as project manager, will deal with the foundation aspects of the project effectively and what risks will be involved. There are three foundation aspects you need to consider:

timescale ;
scope;
quality.

Timescale and scope

Generally, those interested in the outcome of the project focus on two areas, timescale and scope. This can prove to be very challenging. It is difficult to set timescales without knowing the scope, and difficult to set the scope without understanding the timescales. To overcome this, the project manager should pick on one area and focus attention on it. Once a reasonable definition has been achieved, the project manager can then return to the other area. Generally , timescale should be tackled first since this is often the driving force behind the business case. It is also normally the question that is posed most often to the project manager: ˜When will the project be ready?'

Ideally you would be able to spend a significant amount of time working through the project requirements. As you completed the work you would feel able to produce estimates for timescales and task scope. Ultimately this would yield a plan which you would feel happy committing to. However, events rarely happen in this manner in advanced projects. Senior managers and directors are keen to set timescales early in the planning process. They want to see rapid progress and view the setting of timescales as an important milestone in that progress.

Inexperienced project managers find this part of the project process very difficult. They are in charge of a large and usually difficult project that is being carefully scrutinized by senior managers. These are the same senior managers who will help shape the project manager's future career. For project managers, this situation can be very challenging. They can and unfortunately often do fail at this stage. They fight senior managers for more time and in doing so they do significant damage to important relationships. Senior managers become disillusioned with the project manager and often this culminates with the project manager being replaced . Avoiding this is surprisingly easy. You should work initially with target timescales rather than estimated timescales. This will enable you to avoid potential conflicts with senior managers.

For inexperienced project managers, working with target timescales can prove to be uncomfortable. They are concerned that even discussing the targets might lead senior managers into expecting something that will ultimately not be delivered. They're worried that the timescales resulting from the estimation process will be significantly different from the target timescales and that they will be unable to explain the differences satisfactorily. The key to overcoming this is to effectively manage senior managers' expectations.

Setting senior managers' expectations and setting a basic time line

The first action you should take is to define what timescales are being requested by senior managers. This should not include any type of scope or feasibility assessment. You should simply seek to understand what senior managers would like to achieve and when they would like to achieve it by. Effectively you should be seeking the wish list of senior managers. This can be achieved easily by interviewing the key senior managers and asking them what their ideal project outcome would be. To ensure consistency throughout the interviewing process it is helpful if you use a standard form. A sample form is shown in Figure 2.1.

Senior Manager Interview Form
Name of interviewee:
Reference number: SMI/XXX/YYY
Date: DD/MM/YY
Questions
What would be a successful outcome for you?
What would be a successful outcome for the organization?
What would be a successful outcome for the project team?
What specific deliverables would you like to see?
What specific deliverables do you think the organization might want additionally?
When would you like to see these deliverables?
How would you measure whether these deliverables have been successfully achieved?
What if any interim stages do you see in producing the deliverables?
What level of resources do you believe should be applied to the production of the deliverables?
Wish list
Description	Ideal delivery date	Measurement of success	Interim delivery suggestion	Resource levels expected

Approvals

Figure 2.1: Interview template

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.

Table 2.1: Estimation form for task groups
Task group description (eg task group 1)	Analogy	Best case	Most likely	Worst case
Headcount
Other cost
Analogy code: DB - done this or similar before RS - done something reasonably similar before ND - not done before

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.

Quality statement

In advanced projects, planning quality in at the start is often overlooked or deliberately ignored. This is a mistake. Including a quality statement at this stage is simple and will result in the project being able to reap ongoing benefits. Describing quality does not have to be an onerous task. Instead simply defining a quality objective against each of the task groups is enough. This objective should be focused on setting out how the project should measure whether the task concerned has been successfully completed. An example of a task with a quality statement embedded might be: ˜A building should last a minimum of 20 years and require no maintenance for 10 years .'

Often project managers produce a large plan quoting the company quality manual standards. However, a simple table works just as well. The table allows you to set out clearly the known tasks against the quality goals. Where a task group has been subdivided into several activities, each activity should be given a quality objective.

Once the quality objectives have been defined it is worth while reviewing the plan to ensure that it still is achievable. You should review with each of the estimators the impact that the quality objectives might have on the estimates that they provided. They should check whether the estimates are still valid given the assumptions they made or whether a further revision is needed. If a further revision is made then the revised plan should be sent back out for review and agreement.

You should now be in a position to release a macro plan. This should be a combination of the high-level requirements from the brainstorming and the task estimates. This plan can now be used as the basis for generating other material prior to the preparation of the final business case.