Workshop Day 1

Welcome to the Undertake Project Work course. This workshop has been designed to provide you with the fundamentals for undertaking simple projects within your organisation.

Project Management is a complex and detailed specialisation that requires skills and capabilities in a range of competencies, many of which are honed through years of experience in the field. This course is a primer for people who need to understand the fundamental components of managing workplace projects, usually alongside their daily tasks.

Learning outcomes

Through this course you will develop the skills and knowledge to:

• Define a project and its scope
• Liaise with stakeholders and consider their needs in your planning
• Develop a complete project plan, including risk, quality and change requirements
• Implement and monitor your project plan for effective outcomes
• Complete the project, undertaking a review and lesson capture.

National accreditation pathway

This course is based on the BSBPMG522 Undertake project work unit of competency that contributes to the Diploma of Business.

The course provides optional assessment for pathway accreditation towards a Diploma level unit delivered in fast-track mode.

Accessing your participation guide

To access your participation guide document either in full or just the activities select one of the following: 

1. Participation Guide
2. Project Fundamentals Activities. 

Moving a Corporate Office

AlphaBeta Corporation is a supplier of consulting services and products to government and private industry. It has experienced considerable growth in the last 12 months, going from 80 employees to 150. This growth means that their current corporate offices are no longer adequate for their needs; four months ago they rented additional space across the road for 45 staff. Further to this, they anticipate that the organisation will continue to grow to possibly 200 people within the next 18 months, possibly reaching 280 in the next five years to align to their Strategic Plan to expand their corporate offerings and market share.

As a result of this situation, the Executive and Board of AlphaBeta have decided to relocate their corporate offices to a new location. The new site has already been chosen, it is 20 minutes out of the city, and will comfortably support their anticipated growth for the next five years.

The organisation has appointed a dedicated Project Manager and team to manage the Corporate Relocation Project. The project is responsible for:

• Ensuring that the new corporate offices are appropriately designed and set up to support the needs of the organisation – including offices and other working spaces; reception; meeting rooms and AV; break areas and equipment; other facilities (restrooms, first aid, stationery storage etc.); ICT cabling and other requirements; document and records storage. Their remit also includes: interior design choices, OHS compliance of spaces and furniture, and a range of requirements for break areas and other employee concerns.
• Identifying all items that will be moved into the new facility, and organising the removals processes.
• Identifying all items that will not be moved to the new facility, and organising disposal, sale or donation of these items.
• Organising the make good handover of the current facility back to the landlord, and finalising the leases on the main corporate office and the temporary space across the road.
• Ensuring business continuity throughout the move.
• Communicating and engaging staff in the process.

The Executive are anticipating that this will take six months to complete, but they have not authorised a final budget at this stage.

The Project Team consists of:

The project reports to a Relocation Steering Committee, and a business reference group is being established to ensure that the requirements and concerns of the five business units are factored into the low-level decisions.

While you will be working on the entire project for the scoping document, you will need to focus on one aspect of the project for the project plan development.

1.1.2 Project Management

In your small group, consider the questions below and write down your responses on post-it-notes (one response per post-it-note).

• Place your post-it-notes on the appropriate flip chart paper on the wall.
• Use the space below to record your responses for future reference.

1. What is a project?
2. What is project management?
3. What makes a project succeed?
4. What makes a project fail?
5. What do project managers manage?

A project is a temporary activity designed to deliver a defined outcome. It has a defined:

• Beginning and end
• Scope and resources
• Goal, or goals, outside business as usual operations.

A project is a unique activity, which is often delivered by a team that doesn’t usually work together. A project is usually deemed successful if it achieves its objectives within the time, cost and quality constraints agreed in the plan.

Developing a new piece of software to improve your business processes, moving to a new office building, the relief effort after a natural disaster, expanding your business into a new geographic market – are all projects.

And all projects must be managed to deliver their defined results on-time and on-budget; integrated to the business as usual components of the organisation.

Overview

Projects vary in size and complexity. All projects can be mapped to the following generic lifecycle:

Project lifecycle

1. Starting the project
2. Organising the project
3. Carrying out the work
4. Closing the project

Alongside the stages in the lifecycle, there are three processes that run throughout the project and are essential components to its successful delivery.

These are:

• Engagement with your stakeholders
• Identification and management of the project risks and processes to
• Strategically monitor and review the organisational environment and its impact on the project.

The image below outlines the high-level deliverables, activities and staffing across a generic project lifecycle structure. Each stage in the lifecycle has a gate, defined deliverables that must be completed before you can move on to the next stage.

Let’s take a few minutes to discuss this before we get into the specifics:

Identify the need	Opportunity for change is identified with the decision to launch a project. Determine the need for a project - what's the real problem to solve Ensure the problem/change required is linked to the business strategy Determine how the project will add value to the business -what’s the business case Identify critical key stakeholders - might there be a need for a steering committee Who’s best suited to be project manager Agree & sign off need for project.
Scope the project	Prepare the project charter. Assemble project team Scope the project Review learnings/recommendations from previous similar projects Engage stakeholders Identify project objectives, inclusions, exclusions, risks, etc Identify project deliverables Agree on levels of authority, roles, responsibilities, and governance Identify relevant frameworks, policies, legislation, regulations, etc Agree & formal sign-off project.
Plan & Design the project	Prepare the Project Plan.  Identify all possible solutions Develop a draft project plan using the following input tools/activities: Stakeholder mapping/analysis RACI/RAM matrix WBS/resource requirements PERT/ Gantt chart Comms plan Risk analysis & management plan Quality mgt plan Project interdependencies Issue mgt Change mgt Project governance & reporting Budget mgt Finalise & formally sign off the project plan.
Implement the project	Implement the project plan.  Monitor and control activities and/tasks/milestones Monitor & control costs/budgets/risks/issues Complete status/flash reporting & meet weekly or as agreed If required, completed testing/acceptance Manage change from a project activity perspective Manage change from a people perspective Complete handover deliverables and prepare to handover.
Handover the project	Handover the project deliverables Prepare for & conduct handover meetings with sponsor & critical key stakeholders as appropriate Complete handover report.
Evaluate the outcomes	Deliver project to Sponsor & critical key stakeholders Evaluate project performance, including learnings & recommendations Incorporate lessons learned/recommendations into organizational documentation for future reference Debrief with the project team Close project.

Before a project can commence, you need to develop a document that provides the organisation with a clear reason for needing the project, and high-level detail on the scope of the work to be undertaken. This is usually developed through a business case, or similar project initiation template.

Your project initiation document needs to provide decision makers with a reason for supporting and funding your project. It should clarify what the project is about and what it will deliver to the organisation. You could commence this process by answering the following high-level questions:

• What is the driving need of the project? What problem/issue is it solving; or opportunity it is taking advantage of; or legislative/regulatory need is it meeting?
• What does the project aim to achieve?
• What activities would achieve this desired outcome?
• Who does the project affect? Who are the other stakeholders?
• What is the scope of activity of the project?
• What is not included in the scope of this project?
• What resources would be required to complete these activities?
• What would the anticipated timeframe be to complete the activities?

Organisations use some form of charter, project initiation document, scope or brief to define and capture agreement on the scope and governance of your project. We’re going to refer to this as defining your scope.

Governance requirements

Project governance is an oversight function that is aligned with the organisation’s governance model and that encompasses the project lifecycle. A project governance framework provides the project manager and team with structure, processes, decision-making models and tools for managing the project, while supporting and controlling the project for successful delivery.

These structures provide a comprehensive, consistent method of controlling the project and ensuring its success by defining and documenting and communicating reliable, repeatable project practices. It includes a framework for making project decisions, defines roles, responsibilities, and accountabilities for the success of the project. It also determines the effectiveness of the project manager. A project’s governance is defined by and fits within the larger context of the portfolio, program, or organisation sponsoring it but is separate from organisational governance.

Project governance involves stakeholders as well as documented policies, procedures, and standards, responsibilities and authorities. Examples of the elements of a project governance framework include:

• project successes and deliverable acceptance criteria
• process to identify, escalate, and resolve issues that arise during the project
• relationship among the project team, organisational groups, and external stakeholders
• project organisation chart that identifies project roles
• processes and procedures for the communication of information
• project decision-making processes
• process for project stage/phase gate reviews (before proceeding to the next stage/phase)
• process for review and approval for changes to budget, scope, quality, and schedule which are beyond the authority of the project manager
• process to align internal stakeholders with project process requirements.

While project governance is the framework in which the project team performs, the team is still responsible for planning, implementing, controlling and closing the project. The project governance approach should be described in the project management plan.

Project governance accountabilities

Many projects run into trouble because they do not have clear accountabilities. A RACI or RASCI matrix is a great way to define your governance accountabilities up front.

RACI matrix

A RACI (Responsible, Accountable, Consulted, Informed) matrix describes how the project roles are involved in the delivery of tasks, activities and deliverables.

• Responsible
  • The role(s) who will do the work to achieve the task
• Accountable
  • The role with ultimate responsibility for the completion of the task or deliverable. There can only be one accountable person per task or deliverable
• Support
  • Depending on the project, you could also include Support and create a RASCI matrix
• Consulted
  • People whose opinions are sought, usually experts. (Two-way communication)
• Informed
  • The people who need to be kept up-to-date on the progress or completion of the task or deliverable. (One-way communication).

A template and more information is provided in Appendix B.

Defining your scope

There is no formal list of content for a project charter or other scoping document. Your organisation might have a template, or it will be up to you to create one. The following template includes the common requirements.

Knowing what you need to complete the scope will help you identify the work you need to conduct.

Your Project Scope effectively becomes the executive summary of your project plan, and the contract for what you will deliver in your project. It needs to contain enough detail to be meaningful, but it is not the project plan. It is the document that is usually developed to seek authorisation to continue with your project, at least to the Planning stage.

The following are usually developed in collaboration with key stakeholders and subject matter experts – who will also be involved in the planning process.

Project Name	What you plan on calling the project within the organisation
Project Sponsor	The delegate who will own and support the project
Project Manager	You
Project Governance	Simple statement about the governance structure – particularly noting any Steering Committees or other bodies that have a role in oversight or decision making.
Project Description	A brief description of the project. Don’t get too caught up in the details here, it’s often best to explain it in simple words about the problem it is solving or the opportunity it is taking. You could include the vision statement here too.
Project Outcomes	See note below on Outcomes – these are the long-term benefits that the project will deliver to the organisation.
Alignment to Organisational Goals and other Projects	Where does this fit into the goals in your Strategic Plan? Does it align to the delivery or outcomes of other projects? Include that here.
Project Goals and Objectives	See note below on Goals/Objectives. Remember SMART.
Resources and Budget	Since you have not completed actual tenders or procurement plans, this is a best guess for the information you have right now – but it should be altered after the final budget and resources have been approved. Include budget for external expenditure, people resources, equipment and other physical resources required.
Deliverables	A simple list of what you will be delivering as part of the project. This is not your full work breakdown structure, just the high-level deliverables. Remember to think broadly, if you are delivering a new IT system are you also delivering training and manuals?
Inclusions	What is included in the scope of the project? Think about whether it will cover the entire organisation, or only select units. Consider the deliverables above and what you might want to be explicit about.
Exclusions	This is extremely important to define early; what is not in your scope? This will help you avoid scope creep. Even if you think it is obvious that you aren’t doing something, spell it out for everyone else.
Assumptions	What have you assumed will be available or will be happening to make this project work? This could include simple things like, The finance unit will provide the team with a SME for the duration of the project. If you are relying on another part of the business to complete a project or activity, then include it here as well.
Constraints	What are your known constraints within this scope? Capture them here so people know you have taken certain issues into consideration. This could include availability of people, peak season timings, deconflicting projects etc.
Key Risks	You are only including what you see as the major risks for the successful delivery of the project. You might have already identified them in the assumptions and constraints, but spell the key ones out here – you do not need mitigation strategies in the Scoping document.
Key Stakeholders	Who are you Key stakeholders? Who is going to be primarily affected by the project? Who needs to be involved in any aspect of the delivery? Who do you require support from? List out your Key Stakeholders here, not the analysis of them.
Responsibilities Reporting, accountability and limit of authority	What are your responsibilities as the Project Manager. Include reporting requirements, your personal responsibilities and what you need to seek approval for.
Proposed Start Date		Proposed Completion Date
Signature of Project Manager		Date
Signature of Sponsor/Manager		Date

Benefits and objectives

Importantly, every project needs a well-defined purpose and set of objectives. These statements not only provide detail to decision makers, but they will become a fundamental aspect of communication and broader understanding of the project’s scope.

The purpose of the project is the answer to the question, “what is it aiming to achieve?”. This is a very broad statement but think about what your project is uniquely attempting to deliver to the organisation. Most often, projects are developed to solve a problem within the organisation, which makes their purpose easier to define. Does the project:

• Improve the efficiency of a business process?
• Remove redundant and unreliable systems?
• Allow the organisation to better accommodate its workforce?
• Allow the organisation to meet legislative requirements?

Framing it as the problem you are solving for the organisation is often a great way to start.

You need to understand the difference between these terms:

• Outcome (or Benefits) – this is what the business, staff, or customers gain from the project
• Objective (or Goal) – this is what you are aiming to achieve and should be written SMART.

Outcomes

The outcomes are usually written as To statements:

• “To promote…”
• “To provide…”
• “To improve…”.

For example:

“To provide clarity around procurement” or “To improve the safety of warehouse operations”.

Importantly, these are high-level statements that express the benefits to the organisation. You must have at least one Objective for each Outcome, so you can measure your success.

1.1.4 Activity: What are the outcomes?

Using the Project agreed upon in your group, define at least two Outcomes for your project.

Objectives

As part of your project initiation and definition, you will develop a range of objectives or goals. It is important that these statements are clear and well-defined. This will help guarantee everyone is working towards a common end state and defines how the success of the project will be measured.

One way of developing these statements is the use of the SMART goal framework:

S.M.A.R.T. goals

Specific	Make the desired goal as specific as possible, avoid generalisations.
Measurable	How you will measure it- what can you measure? Is it indicative of project intent?
Achievable	Consider the activities in the project and whether it is doable.
Relevant	Does this goal align to the purpose of the project?
Time-bound	The date you will achieve the goal.

An example of how this might look:

• unSMART goal
  • Provide the organisation with state of the art meeting rooms.
• SMART goal
  • In the new office we will provide five meeting rooms that will support the majority of meeting requirements for the organisation, with integrated AV systems – as outlined in consultation with key stakeholders and IT.

1.1.4 Activity: Project goal

Using your Project, develop a SMART project goal that will help achieve your outcome above.

Other definitions

Assumptions

According to PMBOK, an assumption is A factor in planning process that is considered to be true, real or certain often without any proof or demonstration. There are things that, through experience or known processes, you can presume will be true for your project.

Importantly, all project assumptions are potential risks and need to be stated clearly for everyone involved in the project.

Constraints

According to PMBOK, a constraint is A limiting factor that affects the execution of a project, program, portfolio or a process. The might be imposed by stakeholders, the environment or other organisational factors.

Importantly, constraints need to be considered in the planning and delivery of the project and can often compete against each other. For example, a constraint in available resources, which requires you to hire an industry specialist, could directly conflict with the budgetary constraints. The project manager is required to balance and deconflict these matters.

Deliverables

A deliverable is any product, service or result that must be provided to complete the project and achieve its outcomes. There are different categories of deliverables, best described as Internal and External. Internal are the deliverables required for the project to run (project management materials, reviews etc.); external are the deliverables for the users, clients or customers (systems, products, services etc.),

Stakeholder identification and analysis

The project initiation phase also requires the identification of key stakeholders, and their interest/ involvement in the project. The stakeholder analysis developed in the initiation phase will be expanded in the planning phase, and we will focus our discussion when we reach that part of the process.

Remember though, a stakeholder analysis must be conducted in the initiation phase to ensure you fully understand the impact of the project on people and groups inside and outside your organisation.

Influence and interest matrix

• Quadrant 1: High/High
  • These stakeholders have a high vested interest in the successful delivery of your project, usually because it will impact what they do or how they work with you. They also have high influence over the success of your project, largely because they have a role within it. This could be as a Project Sponsor, a team member, the manager of a team you need something from to ensure delivery.
• Quadrant 2: High/Low
  • These stakeholders still have a high interest in the successful delivery of your project, but their ability to influence the success of it is low. These are likely to be people at the end of a value chain, or people who will use what you are implementing but they are not part of the implementation itself. These could be staff who will use the new system, but they are not part of the project to deliver it.
• Quadrant 3: Low/High
  • These stakeholders have a low interest in the delivery of the project, usually because there is no or minimal impact on their work or how they engage with you. However, they still have high influence over the success of the project because they have a role to support or deliver it – this could be the Finance Manager who will provide you with your budget allocation and process invoices.
• Quadrant 4: Low/Low
  • These stakeholders have low interest and low influence for your project. They are the groups or individuals with no vested interest in the project and no role in its delivery. This could be people who receive your services or products, who do not have to change their actions or behaviours.

1.1.4 Activity: Who are your stakeholders?

Using the agreed project and the template below, come up with the list of stakeholders for your project. Complete the Name, Overview, Must haves and support columns in the table – the idea is to come up with a description about what their stake in the project is, what they might want to see included and their perceived level of support.

• For support they are either: Strongly Against (SA), Against (A), Neutral (N), Supportive (S), Strongly Supportive (SS).
• Then, decide which quadrant your stakeholders are in and put that in the Influence column. Use the quadrant numbers to make it easier.

1.1.4 Activity: Engaging stakeholders 

Considering their influence, how will you engage with them? Do they need the ability to contribute? If so, what is your Engagement strategy?

Remember: the engagement plan is more than only communication. It might include other activities like site visits, demonstrations, training etc.

Once all stakeholders have been identified, you can use the Stakeholder Commitment Curve to assess and define their level of commitment towards your project. It shows us the two paths that can be taken to achieve stakeholder commitment to a project.

Commitment grows from the bottom of the curve to the top and can branch in two directions. The left-hand branch represents a project where commitment is attained because it has to be done. This type of commitment is known as compliance.

The right-hand branch represents a project which is embraced because they want it to happen and see benefit in a positive outcome. This is where real “hearts and minds” commitment occurs.

Along each path there are phases stakeholders pass through and how you manage them through these processes will influence the final outcome.

Stakeholder Commitment Curve

Once your project is approved and established, you should start to develop a more detailed understanding of the requirements of your project. The Project Management Plan is the mechanism most organisations use to capture:

• Detailed analysis of the project stakeholders, requirements and strategies
• Detailed definitions of the work, which will include the work breakdown structure and deliverables
• Detailed estimates of project resources and timeframes:
  • Resources include people, expertise, materials, facilities, equipment, money etc.
  • Timeframes include capturing the milestone delivery, dependencies and developing a critical path
• Project risks which identify the owners, mitigation or management strategies
• Project quality strategies, guidelines and management activities
• Communication strategies and plans for the project.

Project updates and registers

Alongside the project management planning documents, the Project Team will create and manage a set of reporting and management documents to support the process. The organisation and size of the project will drive the amount and detail of this documentation. But during the implementation phase of the project, the team will usually manage:

• Project report to appropriate governance bodies
• Project Issues Register
• Project Risk Register
• Project Budget
• Project Gantt Chart
• Content calendar/schedule for communications.

The following sections are all part of the planning process. Some of them also extend into the implementation phase of the project.

Defining activities and milestones

To appropriately manage the scope of your project you need to include a detailed list of:

• All the work required, and
• Only the work required.

Part of this was already developed and identified in your initiation phase. During that phase, you developed a high-level definition of the project scope, resources, timeframes and deliverables.

A significant part of the scope management process is to refine these high-level requirements into granular scope definitions, scope control plans and a work breakdown structure (WBS).

There are a range of actions and planning processes you will undertake in this stage. For now, our next task is to clearly define the project milestones, which creates a detailed understanding of timings and resources for the project and is the catalyst for the more detailed WBS.

A milestone is a particular point in the project that is used to measure progress towards the ultimate goal. They can include: review or input dates, budget checks, due dates for major deliverables and many more activities, events or processes.

Initial WBS planning – using sticky notes

What is it?

Planning your work breakdown structure with sticky notes is a process tool that can be used to create a high-level milestone plan at the beginning of any project.

Why use it?

It helps steer and support key decisions around a project. It can help you plan and decide:

• What to do
• When to do it
• Who will do it
• How long it will take.

When to use it?

Planning your milestones with sticky note is done in the early stages of a project when it is important to establish your WBS. We do this for a number of reasons:

• To assess the project’s feasibility
• To look for interdependencies with other projects
• To review resource requirements
• To assess and develop a financial case
• To sequence and structure tasks.

Who uses it?

This process can be used by either an individual, or a small group of people who are working together on a project – it is preferable to get a group of people together who are specialists in their areas and are more likely to identify area you would not have considered.

1.1.5 Activity: Your sticky notes

Watch the video Project Planning with Sticky Notes and try it for yourself using your Project:

• You will need: flip chart paper, post-it-notes, textas and sticky tape.

My insights

1. Plan with your team – start with the project name and brief them into the activity
2. Brainstorm work packages – get the group to do a sticky for each activity or deliverable they can think of
3. Group work packages into streams – structure the sticky notes into groups of activities/tasks and give the stream a name
4. Check for completeness – review using the 100% rule, whether you have included all required deliverables for the complete product/system/service
5. Check for clarity – confirm understanding, renaming packages or streams to make it clearer if required
6. Keep a record – take a photo or the structure on paper.

Capturing timeframes and dates

After identifying all the milestones, the amount of time required to complete them, and the responsible people in the organisation – you can develop a Gantt chart with dependencies.

Gantt chart

A Gantt chart is a tabular and visual representation of tasking, like the image below. It allows people to better visualise the timeframe for the project, where the milestones sit, and the current status of tasks.

If you are using sophisticated project management software, there are a range of details you can identify in the system: start and end times; dependencies of the activities; the resources allocated to the activity, and whether they are overtasked; the percentage complete, etc.

Importantly, the dates and dependencies allow these systems to automatically monitor the flow on effects of delays in activities that later activities rely upon. If you are managing this manually, you might miss some of these connections.

Estimation issues

Most people work on an optimism bias when they calculate the time an activity will take. Further to this, project managers often fail to consider the project management requirements for a task. When you are learning to estimate, add 50 percent to your initial concept and you will probably come close to the figure – remember to review this at the end to improve your estimation skills.

1.1.5 Activity: Create your Gantt chart

In your group, run an abbreviated process for your project and create your Gantt chart (use Gantt this chart template – there is another copy in your appendices).

Understanding the resources required

Once you have defined the discrete pieces of work required to deliver your outcomes and objectives, you can work out the resources required for your project. You should have done a high-level budget for the Project Scope, but this is where you get more detailed again.

Your resources will include things like:

• Project Team members – can include skills and knowledge required for each deliverable and the hours, to help you determine the team makeup
• External procurement for deliverables – the consultants, experts, products and services you need to purchase as part of your deliverables. This could be things like the software and specialist IT professionals, or office equipment and removalists
• Insurances – where you might need this for the activities you are conducting
• Supporting materials – communication and training collateral required to conduct the project and keep people informed
• Facilities and resources – rooms, AV resources and similar required for use in communication, training and housing the project team.

Ongoing costs

It’s also important at this time to define the ongoing costs that might be associated with the ‘business as usual’ handover of your project. Things like annual licensing fees, rental fees, insurances and warranties etc. You should have an estimate of this in your Initiation document, so as this is clarified in the planning and delivery phase you need to capture it for handover.

1.1.5 Activity: Defining your resources

Using the template below or in your activity document, define your resources for your Project. Where you are unsure of costs, make a best guess for now – you could try Google for a general idea, depending on what it is.

Once you have completed this activity, you can validate the initial Scope of your project. In particular, whether you can deliver the identified deliverables (WBS), within the estimated timeframe (Gantt chart), with the anticipated budget and identified staff (resources).

Identifying project quality

It is important for you to define how you will evaluate and maintain quality assurance for your project. Certain projects will require a very explicit and compliant assurance program, especially projects that are being delivered to a certain quality standard – like construction or some manufactured products.

The quality process could mean you will manage and review the following details.

• Issues raised by you governance body, sponsor, team, contractors and stakeholders
  • Formal Issues Register process. You would need to define how these issues are captured by your team, documented, resolved and communicated back to the original reporter.
• Whether the deliverables received are fit for purpose and meet the stated requirements
  • Outline the review process, who will be involved, how the deliverable will be evaluated and what will happen if it does not meet the brief.
• A formal Change or Variation request process to appropriately capture, review and implement required variations to the plan
  • Outline the process for requesting a change (form); how these are reviewed, and by whom; and how changes are formally captured and relevant people notified.
• Project management processes and performance through an identified audit program
  • Plan for, conduct and capture quality audits on the performance of the project, to ensure identified processes and procedures are being followed.
• Records and other requirements for documentation for the project, and for the business as usual operation/maintenance of the deliverables
  • Outline where and how project documents/records will be stored and which records will be transitioned to the business owner on completion.

Developing your communications plan

The biggest issue with projects is the ambiguity and uncertainty of the change they are creating. Therefore, as the project manager, it’s important for you to provide certainty and clear messages about what is actually going happen, and when.

Nature abhors a vacuum. If you are not communicating, someone else will – and that’s where the misinformation and disinformation begins.

To achieve this, you need to develop a detailed communication plan. This will take the information you developed for your stakeholders, to develop a more detailed picture about what communications they will receive, how they will receive it and how often that will happen.

Project lifecycle and communications

Communications can seem so obvious to us, that at first it may seem unnecessary to give much time to planning one’s approach. However, given all the attributes that impact on how we receive messages it is imperative that we know where communication is vital, what our approach will be, and address the preferred communication style and therefore needs, of each and every one of our stakeholders.

Be assured, particularly for major projects that poor communications planning will almost certainly impact negatively on outcomes. The diagram below depicts where communications plays an important role in the project lifecycle.

^{Diagram source: A Handbook of Project Management: A Complete Guide for Beginners to Professionals. 2013}

1.1.5 Activity: Identifying the messages

Using your Project, what are the key messages for your stakeholders? Define three key messages that incorporate the need for the change, benefits of change and at least one action they need to take.

You then need to understand what sort of communications you are going to develop and who needs which messages, and when.

1.1.5 Activity: Who needs what?

Using your stakeholder analysis and the key messages outlined above, provide a brief overview of the communication plan for your Project.

Note: the what is the general topic of the communications, in a large project you might develop a list of all the What’s first before you start this process.

Once you have developed this outline, you would include each of these communication requirements in your project schedule/Gantt chart. These are usually grouped together, but it’s important to include them in case a piece of communication relies on an activity being completed. If it’s not together, then you run the risk of not updating communication dates when deliverable dates change.

Remember, to support your positive change, people need to have trust and confidence in the project.

Change management is an essential part of project management, which focuses on helping people through the changes through communication. The core of change is to create the compelling reason for change, understand your stakeholder wants and needs, and develop a ‘project’ to manage the change – including a change strategy and communication plan. But it’s important to understand some of the basic principles.

Kotter's 8 steps:

There are many models for managing change within organisations; Kotter’s Eight Steps is one of the more popular and enduring models. It goes from Step 1: Create Urgency, through to Step 8: Anchor the changes in corporate culture, and it is largely the same as every other change model that has been used since the 1990s.

You can see how this aligns with the standard project management methodology, but the focus of change is people, whereas the focus of the project tasks.

• Create a shared vision for the change
• Identify the stakeholders and their role/impact in the change
• Communicate the change – often, at different levels so everyone can appreciate what it means for them
• Embed the change into ‘how we do things around here’.

1.1.6 Activity: Your vision

Using the agreed Project, develop the vision for change in your project.

Change is an organisational activity – transition is an individual process to adapt to the change.

Individual transitions

Bridges’ Transition Model is the most popular methodology used to consider the impact of change on individuals. The basic idea is that once the organisational change commences, the individual’s internal transition to the ‘New Beginning’ can also begin. As you can see from the three stages below, Bridges’ model is predicated on the fact that change creates a loss for individuals, and that there has to be some inner turmoil and stress before they can transition into the changed environment.

Bridges’ Transition Model

It is based on the premise that you are always losing something or having to let go. This will lead people through a process of grief, which has to be acknowledged and worked through before they can start rebuilding an acceptance of the new thing… or does it?

Everyone has a different appetite for change, and that can alter based on the nature of the change and what else is going on in their lives. People usually sit somewhere on a continuum of seeing the opportunities in a change, or seeing the risks in the change. Understanding that you will help you tailor your communications to ensure you acknowledge and respond to the more risk averse staff.

Further to this, there are legitimate reasons that people might be resisting the change. Gibbons’ Holistic Model of Resistance to Change demonstrates that resistance is not simply because “they don’t understand the change” or “they just don’t like change”.

Cause	They resist because…
Rational	…they possess insufficient or wrong facts, or disagree with reasoning based on those facts – they might agree with the premise but dispute the conclusions.
Habitual	…they have a will to change, but habitual behaviours produce a lack of adoption or relapse.
Emotional	…they are angry at or afraid by the proposed change – “Will I be able to do this?” “Will I lose my job?” “How dare they?”
Identity	…they see change as a threat to “who I am” or how they see themselves – you might be removing their power or changing a process that labels them an ‘obstacle’ to getting things done.
Ideological	…the change is contrary to values (theirs or the organisations), a philosophical stance, or their morals.
Social	…there are social disruptions to important relationships or loyalty to others harmed by the change (e.g. the survivor effects), nonlinear network effects on information transmission (virality, influencers).
Cultural	…organisational norms, meaning social mimicry, rituals, language and values that reinforce old (undesirable) patterns of individual thinking and behaving.
Political	…political allegiances, change in power structures, or loss of perceived power, influence, control or autonomy.

1.1.6 Activity: Addressing resistance

Your facilitator will give you two causes to discuss. Looking at why people resist, can you come up with a couple of methods to help you guide people through this resistance? Share with the group through discussion.

Take a moment to list the three most valuable things you took from today – an idea, a method, a resource. Include a brief explanation of where you plan to use it back in your workplace.