Define your project organisation
This chapter explains the steps you need to take during the Initial Investigation Stage to set up a project and ensure that control is established from the very start.
‘Mix a little foolishness with your serious plans; it’s lovely to be silly at the right moment.’
HORACE, 65–8 BC
This chapter explains the steps you need to take during the Initial Investigation Stage to set up a project and ensure that control is established from the very start. For clarity these steps are described sequentially, but in practice you will find that you need to do them in parallel, as each step may influence any of the other steps.
There are five key activities for you to undertake when setting up a project:
The purpose of formally setting up the project is for you to state explicitly the business drivers, scope and objectives for the project, that is:
This information is gathered in a document set which, together with the associated plans, provides you with the starting point (baseline) on which all subsequent project decisions will be taken and against which you can measure project performance. Different organisations have different sets of documents to support this, the common ones being:
All these mostly contain the same information, it is just the way they are assembled and named that changes. For example, the Project Management Plan often comprises a subsidiary set of documents defining how each aspect of the project is managed, for example risk management plan, schedule management plan. Some organisations combine the ‘business case’, which justifies why you are dong a project and proves its viability, with the ‘definition’, which defines the scope, schedule and costs. The reason for this is simply to ensure the two documents align as there is often a degree of duplication. In this book, I have assumed the business cases and the project definition are combined in a single document, called a ‘business case’.
The headings under which you should define your project follow. I have chosen to structure the document in three parts, each serving a different interest group. It is important for you to avoid having to write up your project in many differing ways to meet differing needs. For example, it is not unusual for finance functions to want a ‘special’ document on which to base the authorisation of funds for the project (hence why some organisations have a separate business case document altogether). However, good design of a key document, such as that outlined here, can avoid such duplication and thus reduce your workload and the discrepancies which can appear if separate documents are required for different interest groups.
‘But why do I need to write it all up? Isn’t it just a waste of time?’
Writing up your project in a structured and thorough way helps you to ensure that all the important aspects are covered. The template is, in itself, a checklist for building quality into your projects.
Unless you are the only person involved in the project, you will need to communicate your intentions. You may know everything about the project, but if the others who need to be involved don’t understand what you are trying to achieve, the project will fail. The document is your explicit form of communication.
Keep the document brief. Put in the minimum content to communicate the bare essentials. Ironically, the simpler the project, the more people tend to write, as they know so much about it. Larger, more complex projects are frequently ill defined and too brief.
The three parts of the business case are:
Part 1 – Finance, which is primarily aimed at the finance function. They will be interested in this section as a priority and then Section 2.1 to 2.4. The project sponsor will also be interested in this as it sets out the financial criteria to be met.
Part 2 – Project Definition is of interest to the project sponsor, stakeholders and project team. It is the meat of the document.
Part 3 – Project Organisation is of most interest to the project manager, team and line managers as it sets out how the project has been organised.
Section | Section heading | Question answered |
1 | FINANCE | |
1.1 | Financial appraisal | HOW MUCH? |
1.2 | Sensitivity analysis | HOW MUCH? |
2 | PROJECT DEFINITION | |
2.1 | Background | WHY? |
2.2 | Business objectives | WHY? |
2.3 | Benefits | WHY? |
2.4 | Output description | WHAT? |
2.5 | Scope, impacts and interdependencies | WHAT? |
2.6 | Deliverables | WHAT? |
2.7 | Timescales | WHEN? |
2.8 | Risks and opportunities | CONTEXT? |
2.9 | Prerequisites, assumptions and constraints | CONTEXT? |
2.10 | Project approach | HOW? |
2.11 | Analysis of options | HOW? |
3 | PROJECT ORGANISATION | |
3.1 | Review and appraisal points | HOW? |
3.2 | Change control | HOW? |
3.3 | Progress reporting | HOW? |
3.4 | Project team and stakeholders | WHO? |
The content of Part 2 is described in detail later in this chapter.
The typical ‘project structure’ was described in Chapter 4 and is shown again in Figure 19.1.
Project teams are:
Bearing this in mind, it is essential that you agree the project roles from the start (e.g. project sponsor, project manager and project board membership) with the individuals concerned and their line managers (if appropriate). As many of the team members are likely to be part time and have other daily duties to attend to, it is essential that you agree with their line managers what their commitments are and how you should handle changes to this. The line managers may also have a quality assurance role to undertake, if so this must be agreed. If necessary, write and agree a role description, defining the individual’s accountabilities. Even if these descriptions are never referred to again, the act of creating them with the individuals, and agreeing them, will clarify each person’s role and ensure there are fewer misunderstandings. Finally, do ensure that accountability for any activity or work package on the project rests with a single person only. Shared accountabilties do not work; they lead to omission, duplication and confusion (see also p. 286). Summarise the key members’ roles in Section 3.4 of the initial and full business case documents.
You should create, with the team, a set of values for the project to share and an agreed way of working together. Project Workout 19.1 provides some ideas for this. Fostering team spirit is the responsibility of all on the team, led by the project manager. The sooner the team can settle down to work together in an environment of openness and trust, the better it will be for the project. Project setup is the ideal time to do this. Even if you know what to do on the project, sparing the time for the team to contribute will lead to greater commitment and better results. Preferably the early days of the project should be spent as much as possible as a group working in a creative environment. Project planning is an ideal vehicle for forming the team as well as being of vital importance to achieving results. Projects that are designed solely by one person usually lack the vitality and level of involvement necessary for achieving extraordinary results.
It is all well and good ensuring the team is bonded and aligned from the start but do not forget that as the project moves through its life cycle, team membership will change. Welcome new team members and ensure they have bought into the team values and the project objectives. If there are a number of new members, for instance for a new project stage, treat it as if it is a new project. Project Workout 19.1 (The first team meeting) and those related to planning can easily be adapted for the start of each stage.
This is best done in a relaxed atmosphere without any tables acting as barriers between people. The ‘board room’ arrangement is not recommended. Team meetings are best in rooms with space to move around and wall room for flip charts. Confined rooms confine thinking.
The first time team members gather is very important and can set the tone for the rest of the project. Some individuals may know each other (and you) well. Others may know no one. Some may have worked together before on other projects. Even if some have not met before, they may have preconceived ideas of others on the team based on gossip and rumor from other colleagues. It is you, as project manager, who must bond this disparate group into a committed team. One way of doing this is to:
1 | Ask all present to introduce themselves and say a little about their interests outside work. Ask them to tell the others something about themselves that none of the others knows. |
2 | Ask each person to say what his/her commitments are to the project, why he/she would like to see it succeed and what that person will do to help success become a reality. |
3 | When the individual has finished, each of the other team members should build on what that individual has said about him/herself by saying what skills and competencies they know or feel the person has which they respect. Keep to positive and strong points only. |
On receiving this acknowledgment, the individual should not be embarrassed. ‘Thank you’ is all he or she needs to say. | |
4 | Steps 1 to 3 should be gone through for every person in the group. |
This may sound contrived, but it does work if treated seriously. It can remove or dispel rumour. It brings people onto a personal footing.
Team values
Creating a set of ‘rules’ that the team agrees to live by and uphold is also a powerful way of bonding:
During the brainstorm, individuals will often shout out things that annoy them. For example, if someone really gets heated if meetings start late, he/she may want the rule/value ‘All meetings start on time’. The brainstorm list, therefore, becomes a set of potential ‘hot buttons’, which can turn each person from a likeable, rational soul into an angry unreasonable one. It’s good to know what these are at the start! Some of the most powerful values can also appear very shallow. One senior team had ‘chocolate’ as a value. At every meeting someone was accountable for bringing one or two bars of chocolate. It became a symbol of ‘looking after each other’ and something to joke about to lighten the tension when business issues were weighing heavily and the team could not agree a way forward.
Part 2, the project definition section of the business case document, defines your project – why you are doing it, what you will produce and how you will go about it. The details for each section are as follows:
Describe, briefly, the background to the project:
You should describe why you are doing the project. Explain:
You should describe the benefits you hope to achieve from the project (see also Chapter 20). These may be in two forms:
Include a statement on what else the project will accomplish, for example say what new possibilities will be created operationally, commercially, or for new projects.
In addition you should outline:
Answering the question ‘Why?’ is very important. There are four basic reasons why you should want a project:
All programmes (related projects) will ultimately be aiming for one or more of these. In a programme, however, individual projects may focus on other benefits, for example improving performance or service quality. Other projects are created as vehicles to learn about new markets, technologies or approaches. Be honest when stating the business objective. If you pretend a ‘learning’ project is a revenue generator, don’t be surprised if it is cut in favour of projects which generate greater revenue.
You should describe, in one paragraph, what the project is going to produce overall. This may be a new product, a new culture, process, manufacturing line, computer system, etc. Section 2.6 will list the key deliverables and these need not be stated here. The output description document will contain the detail.
Define the work necessary to meet the business objectives outlined in Section 2.2 and to create the output described in Section 2.4. Include:
You should also state, in broad terms:
Interdependency. If Project B requires a deliverable from Project A in order to achieve its objective, Project B is dependent on Project A, i.e. a deliverable is passed from one project to another.
For example, Project A builds a computer platform as one of its deliverables. Project B uses this platform to run software it has built as one of its deliverables. If Project A failed, Project B will fail as it is dependent on it.
A deliverable can be created by one project only. It may, however, be used by many subsequent projects.
The project scope must comprise everything which is needed to ensure that the benefits can be realised. There should be no assumptions that ‘others’ are providing a key part. If other projects are providing deliverables, this must be stated explicitly as a dependency, and not assumed.
List the work packages and major deliverables from your project, which are needed to create the output described in Section 2.4. Deliverables may take two forms:
For each deliverable, specify:
If the list is extensive, you should detail them in an appendix and list only the key ones in the main body of the document.
Outline the overall project timescales by stating the target completion dates for key milestones. Include all the staged framework milestones: Development Gate, Trial Gate, Release Gate, launch, project complete (see p. 60). Add any other significant milestones or events such as the letting of a major contract.
This section should contain:
You may conveniently present this in the form of a risk and opportunities log. (See Chapter 23 for a full discussion of risks and opportunities.)
Include:
It is important that you list all assumptions and constraints, even if they appear obvious to you; they may not be so obvious to others associated with the project.
Describe how the project will be undertaken and explain why you have chosen this particular approach. Include:
Where subprojects are complex, you should consider having each one formally defined by the sub project manager using Parts 2 and 3 of this document.
Summarise the key points from the investigative studies, stating which options have been rejected and which have been carried forward for further analysis. Give your reasons for any choices made.
Take any new project that you are associated with. With the project sponsor, project manager and key team members, create, on flip charts in a workshop environment, the project definition part of the business case document. Base it on the template given above.
Ensure you answer every section fully – it all counts.
Note where there are gaps in the answers and be honest. You will fool no one but yourself in the long term.
Work with the team to fill the gaps identified in this workout:
Use this checklist to review any projects currently in progress.
Criteria | |
Has a project definition been written, reviewed by the stakeholders and approved by the project sponsor? | |
Do the scope and objectives of the project meet the needs of the business? | |
Have the benefits been fully assessed and quantified wherever possible? | |
Do the benefits match the needs? | |
Have all significant risks been identified, categorised and taken into account in the plan and business case? | |
Has a comprehensive and satisfactory work breakdown been developed? | |
Does the work breakdown reflect the deliverables to be produced? | |
Are all key logical relationships between projects and activities clear? | |
Has the plan been developed to minimise or offset the risks? |
The only way a project can be delivered is by its deliverables. For each deliverable check:
Are the project deliverables relevant and are they feasible both to produce and use? | |
Have quality criteria been established? | |
Is it clear who is accountable for preparing each deliverable? | |
Is it clear who will review the deliverable prior to signing off acceptance of each deliverable? | |
Is it clear who will approve each deliverable? | |
Has sufficient time been allowed for reviewing/amending each deliverable? |
A major food manufacturer was undertaking a radical reorganisation of its processes and working methods. This involved warehousing, distribution, manufacturing, marketing, human resources and sales. In all, there were seven projects within the complex change programme. A considerable amount of study work had been completed and some of the projects had actually started. The managing director asked his management team, each member of which was sponsoring one or more projects, to write up each project in a form similar to that given in this book. When asked how long it would take, they all said a week. The managing director gave them two weeks.
Seven weeks later the last project definition arrived. ‘What took you so long?’ the managing director asked. One director said that as he was writing his, it dawned on him he wasn’t really sure what he was doing. Further, when they read each others’ documents they were surprised and often perturbed at what they were doing. The extra time was to work on the gaps and to check that they all formed a coherent programme.
With the projects in the case study, I designed a front cover with a space for the name and signature of the project sponsor and project manager, No one was asked to sign anything. Of the seven documents, four came back, unprompted, with both signatures and the other three with only that of the project manager.
Guess which projects proceeded more smoothly and with fewer misunderstandings!
I do not advocate inky signatures on every piece of paper. It looks too much like bureaucracy. However, it can be used as a device to test commitment in a culture where a signature has value.
Preparing a project plan enables you to control the project by:
The content and format of the schedule plan are described in the following sections. While these deal with schedule plans, the approach is also valid for the related resource and cost plans which should always use the same work breakdown structure.
Earlier in this chapter we discovered that ‘Projects which are designed solely by one person usually lack the quality and level of involvement necessary for achieving extraordinary results’. I was illustrating the vital team-building benefits of working together at the start of the project. However, the benefits are far more practical and tangible than that. If a team develops an approach to the project and plans it together, there will be debate and argument based on the differing perspectives of each team member. As a result of such discussions, each member will come to understand the needs and viewpoints of the others. Building a good plan is hard work, however, and, once done, all the reasons for it being as it is are embedded in the minds of those who created it. Each individual is less likely to make independent decisions on his/her work scope which will have adverse effects on the work of others. Similarly, when things go wrong (as they probably will), the team will know more instinctively the correct way to handle it. Team members will be more likely to concur on the method of resolution: they will have already cleared away all the inter-functional blockages in their minds when they created the original plan.
The project was one which comprised a number of related software changes to four interrelated systems. The owners of each system had planned their parts of the project, BUT no one had as yet put them all together. They spent two full days locked in a room listing what each needed from the others and eventually built a plan which showed how the whole project fitted together. They had it on large sheets of paper with Post-It Notes joined by arrows. It was hard work. They didn’t understand each other. Everyone else was unreasonable. They didn’t know why the ‘others’ had to do their work in such an inconvenient way (a way inconvenient to them).
Once completed, the plan looked obvious. The approach was clear and the team members were happy with each other. They had even agreed who would be accountable for end-to-end testing across the systems (previously missing from the plan). When the inevitable happened and one team member’s part went wrong, there was no blame apportioned, only solutions offered. They didn’t even need to consult the plan; they knew it well enough as it was theirs.
The project was completed successfully.
‘Planning is everything – the plan is nothing.’
EISENHOWER
A good project plan should include consistent plans for benefits, schedule, cost and resources and would include:
You will very rarely be able to plan a project in full at the very start but you should always be able to plan the next stage in detail, with an outline plan for the remainder.
Cost and resource plans are best shown in tabular format, perhaps summarised in a graphical format (S-curve) or histogram. See Chapter 21 for a fuller treatment of this topic.
Project schedule plans are most conveniently presented as bar charts, two forms of which are illustrated on the following pages:
Once you have your project defined and planned out you should make sure that other organisational aspects of the project are addressed, including defining:
The last three points are documented in Sections 3.1 to 3.3 of the initial business case.
Projects can generate a considerable volume of information, correspondence and reports, most of which needs to be accessible and some of which needs to be archived. It is essential that the project manager sets up the administration of the project as soon as practical and that he/she makes sure that all team members and support staff understand what is required and available. The format and media for storing such documentation can vary from being paper based to a full electronic ‘groupware’ platform accessed via an intranet. In many cases, different sections will be held in different formats thus harnessing the capabilities of any support tools and avoiding duplication. Regardless of how you choose to store the information, its content will be similar. The following comprises a checklist on which to base your own project administration requirements. Benchmarking shows that many organisations have a prescribed structure, such as the following, to ensure that records are kept in a consistent way, enabling newcomers to the project to know where to start looking for the information they require.
1 Project summary details
This should comprise a short description of the project and the names of those holding the key accountabilities. The summary, as held on a project-tracking system, should fulfil the needs of this section (see p. 263).
2 Contact list
A list of all the team members, their roles and how they can be contacted.
A chronological record, owned by the project manager, of significant meetings, events and commitments. This should refer to detail in other sections of the file where appropriate.
4 Business case and change log
This section contains the fundamental definition of and case for your project. The change log is an amendment record, listing any changes to the business case which are under consideration or which have already been approved or authorised. By having a change log as a supplement to the Business Case, you avoid the need for updating the main document for every change. You need only reissue it when the number of changes becomes too unwieldy to keep in separate documents.
5 Progress reports
All regular and special progress reports should be retained. If a number of different reports are to be prepared for particular audiences, this section should be subdivided accordingly.
6 Project logs
7 Schedule
This section contains a copy of the most recent schedule showing achievement and forecast against the agreed plan.
8 Finances
This section contains a copy of the most recent cost and benefit position showing achievement and forecast against the agreed plan.
9 Meetings
All meetings should either be minuted or notes should be produced to promote clear communication. This should include:
10 Key deliverables
This section comprises a listing of the key deliverables (with accountabilities for preparation, review and approval). Copies of the documents themselves must be held for team use and archive purposes.
For Gate Decisions | Other deliverables |
Proposal Ready for Trial Report Ready for Service Report Project Closure Report Post-Implementation Review Report |
Output Description Feasibility Report Test Plan Test Results Trial Plan Trial Results |
PLUS any others that are required, as defined in the project, such as detailed specifications, requirements, documents, tender documents, etc.
11 Correspondence
Record of all incoming and outgoing correspondence.
12 Reviews
Copies of any additional project reviews, other than the mandatory gate reviews (held in Section 10), should be kept.
For complex projects, individual subprojects and work packages should follow a similar structure to that held for the overall project.
If you are the project manager, you are accountable for controlling the project and taking the necessary actions to ensure that it delivers the expected outputs. You therefore need to be clear what is actually happening.
You should gather your team together on a regular basis (preferably physically) and check what progress has been made and what progress is forecast. You should also assess the issues which have arisen and the risks which are looming on the horison.
Progress should be recorded by updating the project benefits, schedule and cost forecasts to show:
Additionally you should prepare, for the project sponsor and other key stakeholders, a concise written progress report which includes the following information:
A description of the content of each of these sections follows. Progress reporting should be active, with you telling the stakeholders what they need to know in as concise a form as possible. If your organisation has a single defined format for the report then that is excellent. It helps make sure the reports are full and complete and aids the reader by providing a familiar, consistent format. So, if you have a reporting system, use the same headings.
Make sure your reports:
1 Business objectives
As many stakeholders will not be familiar with your project from its number or title, you should summarise:
This is taken from Section 2.2 of the business case (see p. 298).
2 Progress summary and outlook
Briefly describe the progress of the project both in terms of achievements to date and expected future performance. Will it achieve its objectives? For any significant schedule slippage or cost variance give the reason, its impact and any corrective action being taken.
3 Financials
Provide a summary of the project finances in terms of expected benefits, spend to date and total expected spend compared to that planned.
4 Milestones
List the major milestones. These should at least be the gate milestones as defined in Part Two. For each give:
Describe the key issues which require escalating for resolution. For each give:
6 Key risks and opportunities
Summarise the high risks and major opportunities which have arisen. For each give:
7 Changes
List all outstanding changes which are beyond the project manager’s authority to authorise. For each give:
8 Attachments
It may be convenient to attach, for detailed reference:
Don’t be modest; if you don’t acknowledge the achievements made by you and your team on the project, don’t be surprised if the stakeholders don’t either. It has been said that the definition of an easy project is one which is successful. If it wasn’t easy, it would have failed. The project managers and teams of successful projects are, therefore, in danger of becoming ‘invisible’ or having their achievements undervalued even if it was their own hard work, excellent planning and adherence to best practice which got them there. DON’T BE INVISIBLE!
Once the project has been authorised, its scope, cost, benefits and timescale are baselined and used as the basis on which to monitor progress. Under certain circumstances it is, however, legitimate (and often desirable and/or unavoidable) to change these baselines. Who authorises such changes depends very much on the impact. It is, therefore, essential that the extent of the authority given to the project manager and project sponsor is defined. (Chapter 25 describes this more fully.)
Document who has accountability for authorising changes in Section 3.2 of the business case.
The management framework comprises a staged approach to projects with the ‘gates’ defining the key points when a formal project review is undertaken. However, the time lapse in some stages can be very long, particularly in the Develop and Test Stage. It is, therefore, essential that a sufficient number of additional review points are built into the plan to check that:
As a guide, a project should have a formal review every three months or when a major commitment is to be made. The occurrence of such reviews should be formally documented, as they comprise an essential part in managing the risks.
Reviews are often regarded as taking up valuable time and hampering progress on the project. However, it is in the project sponsor’s interest that reviews take place with accountability to make sure they happen. (Chapter 26 discusses reviews more fully.)
Document the additional reviews in Section 3.1 of the Business Case.
Use this checklist to audit any projects currently in progress.
Criteria | |
Have progress reporting formats been set up? | |
Have progress reporting lines been set up? | |
Has a system for capturing and managing risks and opportunities been set up? | |
Has a system for capturing and managing issues been set up? | |
Has a system for recording and approving changes been set up? |
Every project will create some change in the organisation; otherwise there is no point in undertaking it! However, some changes are ‘easier’ to effect than others as they align with the status quo and do not cross any politically sensitive boundaries. In essence, most of the people carry on as they always have done. Other changes, however, are fundamental and will result in shifts in power bases internal to the organisation or even external, such as unions, suppliers or customers.
Stakeholders are those affected by the project. All those involved in the project are, therefore, stakeholders. However, there are also those who take no direct part in the project as team members, but whose activities will in some way be changed as a result. These could be users of new systems, people in new departments resulting from reorganisations (or those made redundant), those taking roles in new processes as managers, supervisors and workers. Often the project is of little importance to them but they are of great consequence to the project if their consent is critical to success. It is essential to identify them because it is critical to enroll them at an early stage in the project to ensure their power does not cause the project to fail later. Never underestimate stakeholders’ ability to ruin your best laid plans!
It is both the project manager’s and project sponsor’s role to ensure that all stakeholders are adequately briefed on the project. Too much communication will drown them – they won’t read it. Not enough will mean your project will be lower down their priority list than you want it to be.
Engaging stakeholders and keeping them enrolled is a taxing but essential task. It is accomplished both by a formal communication plan and by ‘enrolling behaviour’ on behalf of all the project team on both a planned and opportunistic basis.
All organisations are ‘political’ to some extent and the greater your project’s scope to change the status quo, the more you will need to be tuned in. You will need to identify the power bases you and others are operating from. These include:
To be done in project team mode.
1 | Brainstorm who your stakeholders are. Write each on a Post-It Note and stick them onto a white board or flip chart. Stakeholders may be individuals or groups. | |||
2 | Cluster the stakeholders into groups based on similar need or impact from the project. Rationalise the stakeholder list if possible, but don’t worry if you can’t. | |||
3 | Define the role of each stakeholder (Figure 19.4). Stakeholder roles are defined as: | |||
• | Decision maker – this stakeholder is required to make a decision regarding the project. | |||
• | Influencer – this stakeholder has influence over the project and/or over the decision makers. | |||
• | Player – this stakeholder is required to play a part in the project, perhaps providing resources, facilities or review time. | |||
• | Consent – the consent of this stakeholder is required if the project is to be a success (e.g. computer system users, customers). | |||
4 | Take each stakeholder in turn and, using one flip chart per stakeholder, answer the following questions: | |||
• | What is this person or group’s stake in the project? | |||
• | What is their role in the organisation? | |||
• | What will they gain as a result of the project? | |||
• | What will they lose as a result of the project? | |||
• | What do they control, which the project needs? | |||
• | What is their source of power now (see above)? | |||
• | What will be their source of power after the project (see above)? | |||
• | What is their attitude to the project? (strong/weak/positive/neutral/negative)? |
|||
• | How are they likely to be influenced (e.g. emotion or logic)? | |||
It may be convenient to capture this information in a template for future reference (See CD-ROM for an example). |
Work with your project team using the output from Project Workout 19.5.
Planning | ||
1 | On a flip chart, brainstorm the following for each stakeholder: | |
• | the messages you need them to receive; | |
• | possible methods/media or people you could use to communicate with them; | |
• | frequency of communication. | |
2 | Consider, if you were them, what you would want to know and when? Aim to see things from their perspective. If possible, ask them! | |
3 | On a large sheet of paper or a white board, list each stakeholder along the top. | |
4 | Decide who should receive the standard regular progress report. Put an asterisk over the relevant stakeholder to indicate this. | |
5 | Brainstorm the possible communications which you may wish to send out to the stakeholders. Write each on a Post-It Note. Place these on the chart on the left-hand side, in chronological order. | |
6 | On smaller Post-It Notes, add a tick to show which stakeholder(s) is/are ‘hit’ with each particular communication. | |
7 | Review how frequently each stakeholder will receive a message. Is it too often? Is it not frequently enough? Rearrange the Post-It Notes until you create a plan that the team is comfortable with (Figure 19.5). | |
8 | Transfer the key communications to your schedule plan and ‘fix’ the plan onto your white board by rewriting directly onto it rather than onto Post-It Notes. |
Do not be concerned that you cannot see very far into the future. The objective is to make sure you consider who you need to communicate with, when and how.
Tracking
Using the same white board output, simply write the communication made and the date on the left hand side, ticking the relevant stakeholder columns.
You will thus build a listing from which you will easily see who you have missed. You can then work both from your formal plan and add extra communications when you see these as desirable. You will also be confident that they look rational and consecutive to the recipients.
3.147.69.49