Featured

Scaling Agile Delivery – Revisiting the Spotify Model

I was thinking about some of the challenges with scaling Agile software delivery recently and I took another look at the Spotify Agile engineering model which I hadn’t looked at for some time.

The YouTube video further down this article is a few years old now but it is excellent and still relevant to today’s challenges. I outline some of the key points in this article.

Many of the Agile teams that I have worked with have adopted many of these practices and it is worth taking another look and seeing if your teams can improve their performance by adopting some of them too. It is often the case that what wouldn’t work 6 months ago might work now as people move around between teams, learn more and change their minds.

Before we jump into the scaling Agile part let’s have a quick look at Spotify the company.

Spotify overview

Spotify launched in Sweden in 2008. Today, Spotify is the most popular global audio streaming subscription service with 271m users, including 124m subscribers, across 79 markets. They have 50 million tracks, including 700,000 podcast titles, available to discover, manage and share.

Their development teams are distributed globally so they know a thing or two about managing Agile at scale.

This is what they discovered…

Challenges of scaling Agile delivery

Scaling Agile delivery is challenging. It is quite straight forward to make big strides over the first few years, setup Agile delivery well, and get it functioning effectively. But then what? Where do you go? How far can you go with it? What are the benefits of further improvements and more agility?

Starting with Scrum delivery

Spotify started out using Scrum delivery and this worked very well for a number of years. This gave a nice team-based culture but as the company grew with multiple teams, they found that some of the Scrum practices were getting in the way. So, they decided to make some of them optional.

Agile matters more than Scrum

They discovered that Agile principles mattered more than specific Scrum practices. This was more of a change in mindset, so they renamed some of the elements:

  • The “Scrum Master” became an “Agile Coach” to focus on working with teams to improve Agile delivery
  • They became “Servant Leaders” rather “Process Masters” there to serve the team rather than stick dogmatically to a process

Squads and autonomy

Spotify replaced the terms “Scrum team” with “Squad”. The key driver became autonomy, and this meant:

  • Small cross functional teams of less than 8 people that sit close to each other
  • The Squad have end to end responsibility for one or more products
  • They do design, build, testing, deployment and operations
  • Each Squad has a long-term vision

This means they own the whole thing – so if they build it, they own it and if they break it, they fix it.

Autonomy with boundaries

Autonomy means the Squad decides:

  • What to build
  • How to build it
  • How to work together when building

There are some boundaries that the Squad needs to operate within:

  • The Squad’s mission
  • The overall product strategy

Agile workspace

You can tell a lot about how Agile teams are by walking around their workspace – this is so important. The workspace setup increases the collaboration for teams:

  • Squad members sit close together
  • They have easy access to each other
  • There is nearby space for retrospectives, planning and problem solving
  • All walls are whiteboards

How this works in the changing workplace where more diverse teams are often located in different places, offices and even countries also needs careful consideration (the subject of another video).

The importance of autonomy

Autonomy is important because it motivates people. They are motivated to build better products faster. Autonomy means that teams can make decisions locally and minimise hand-offs between teams so that they don’t get bogged down in dependencies and coordination.

Squad alignment

Although each Squad has a mission they need to be aligned with:

  • Product Strategy
  • Company priorities
  • Other Squads

So, this means:

  • They need to be a good citizen in the Spotify ecosystem
  • Spotify’s overall mission is more important than one individual Squad
  • Be autonomous but don’t over optimise
  • Like a jazz band – everyone has their key role
  • Loosely coupled but tightly aligned

The Squads experiment a lot with different ways of working now and for the future.

Alignment with other Squads enables autonomy.

Squads, Tribes, Chapters and Guilds

These are some of the other organization and community elements:

  • A Squad is a product team owning one or more products
  • Squads are grouped into Tribes
  • A Tribe is a lightweight matrix
  • Chapter is a competency eg. Developer, Agile coaching, DevOps, Testing
  • Chapter lead is the line manager of engineers

A Guild is a lightweight community of interest where people share knowledge eg. Leadership, Web Development, Continuous Delivery. Anyone can join or leave a Guild. A Guild has dedicated communication channels and regular meet-ups.

Spotify preference is for community over organisation structure

Role of the company leadership

The company leader’s roles are different too.

Their job is to communicate what problem needs to be solved and why.

The Squad’s job is to collaborate with each other to find the best solution.

Architecture and internal Open Sourcing

Spotify’s aim is to have a systems architecture where components are small and decoupled. They use an internal Open Source model and there is a culture of sharing rather than owning.

Anyone can edit any code even if another Squad technically owns the codebase. So, if a Squad needs some changes to a product or system component and the owning Squad don’t have time to do the change themselves; then the requesting Squad can make the change instead. The owning Squad will simply do a peer review of the code before it can be released.

Small frequent releases

The focus at Spotify is on doing small software releases often. This led, over time, to the reorganization of the architecture so that it is de-coupled to enable independent releases that can be done separately to reduce impact radius of any failures.

Architecture and Squads evolve to enable easier releases

Because the architecture has evolved to enable decoupled releases, then so has the structure of the Squads. So, the Squads evolved to include:

  • Client Squads – eg. iOS, Android
  • Feature Squads – eg. Search
  • Infrastructure Squads – that provide tools to make it easy for other Squads eg. AB testing, CI etc.

Spotify strive for a self-service model and they aim for no handoffs between teams.

Synchronisation of releases

Some coordination of Squad releases is needed. This is achieved with Release trains and Feature toggles.  

Release trains are releases that are done at a specific regular frequency or date for example: Every 2 weeks on a Thursday. The release happens every time whether there is much ready for the release or not.

If features or functions are not ready for the release then they miss the release or if they are nearly ready then they can be released as a feature but toggled off. When the code is fully ready for release the release is done and the code is toggled on.

Built on trust

The Spotify model is based on trust so that the development teams have enough autonomy to make good decisions within their boundaries and work across teams to deliver great products.

This is a very brief summary of the Spotify experience of running Agile delivery at scale so have a look at the video too.

Scaling Agile delivery – the Spotify way
Featured

How To Start A Project And Increase Its Chance Of Success

Set your project up for success

Setting up a project properly from the start is fundamental to its success. If it is started poorly then the chances are that you will be playing catchup right from the start.

I have rescued many projects over the years, and what is often very clear is that they were never set up for success from the very start.

It’s like playing a game of football: if you get 2 goals scored against you in the first 5 minutes – then the game may well be winnable, but you have a lot of work to do to get it back on track.

This article gives some pointers on how to set projects up properly from the start.

You can also try our FREE Training course that will take you step by step through the process of setting your project up for success.

Avoid the temptation to just get going with the project

Once the project has approval to start it is really tempting to gather a team and get going immediately. However – all projects need a plan and there are some fundamentals to put in place before the plan can be started.

A few simple steps can be taken to avoid a world of pain later in the project.

How do we set up the project for success?

Five questions to answer before planning

Before starting the detailed project plan it is essential to get these 5 key questions answered first.:

  • Who wants the project?
  • What is the project about?
  • Why are we doing the project?
  • Who is impacted by the project?
  • What does success look like for the project?

Getting answers to these questions will mean that you have a really solid foundation from which to start the detailed planning.

The Project Sponsor

Question: Who wants the project?

Answer: Project Sponsor.

Role of the Project Sponsor

The Project Sponsor is the person who wants the project and is typically the person paying for, or funding, the project.

Identifying the Project Sponsor is the key first step as they can tell the Project Manager what the project is about and help them work out who they need to talk to get a detailed understanding of the full project scope.

The Sponsor is also likely to be one of the main stakeholders in the project. They should be seen as the main customer and key decision maker in the project.

It is really important to be clear on who the Sponsor is (not always as straightforward as it should be) and the role they will play on the project. They will set the direction for the project and will help you outline the key objectives, requirements and deliverables.

Sponsor helps define the scope of the project

Question: What is the project about?

Answer: The Project Sponsor will tell you what is in-scope and what is out of scope for the project. This will likely be at a high level initially, but it can then be scoped out in detail in the planning stages of project initiation.

Project Stakeholders

Question: Who is impacted by the project?

Answer: The Stakeholders are the people impacted by the project.

Role of the Stakeholder

A Project Stakeholder is anyone impacted by the project. In any project there are likely to be multiple stakeholders. The project manager needs to

  • Identify all the stakeholders or groups of stakeholders
  • Identify which are the key stakeholders – these are the groups, departments, teams etc. that are most impacted by the project

Key Stakeholders help define detailed project scope

The key stakeholders will help you define the project requirements and will help you define how the project will need to be approached. They will also provide you with some of the constraints that the project has to work within.

The Project Manager will work closely with the Key Stakeholders throughout the project as they are effectively the customers for the project deliverables. They have a big say in the project so it’s really important to work well with them.

The Business Case

Question: Why are we doing the project?

Answer: This should be written down in the Business case.

Understanding the business drivers for the project

Understanding why we are doing the project is essential for success as it provides a reference point throughout the project for what is being delivered.

The Sponsor should be able to articulate the business drivers, benefits and Business Case for doing the project. Often there will be a detailed Business Case document that is agreed before the project has authorisation to start. Sometimes this may not be the case – but the project may have very strong business reasons for its existence.

Use the Business Case as a reference point throughout the project

The Business Case should be summarised in the Project Plan (may also be called the PID – Project Initiation Document, or Project Terms of Reference). This can then be used as a reference point throughout the project to ensure that what is being delivered matches with what the sponsor requires. If there is a request for change in requirements, deliverables etc. then this should be referenced against the Business Case and clarified with the Sponsor.

If there isn’t a written down Business Case then this needs to be agreed with the Sponsor and documented, either in detail or at least in summary level in the Project Plan.

Typical business drivers

There could be many different business drivers for a project. Some of the typical ones are as follows:

  • Improve operational efficiencies and reduce running costs
  • Deliver a new product or service
  • Meet a set of legal requirements, standards or regulations

Where possible the Business Case should state the specific values such as time, cost saved, revenue expected etc.

The Project Vision and Objectives

Question: What does success look like for the project?

Answer: This is defined in the Project Objectives and Vision statement.

A clear definition of success

Having a Project Vision for the project and a set of clear Objectives give a very clear definition of success for the project. If this is done properly it can be referenced throughout the project when decision making. It will also provide clarity and direction for the project delivery teams.

The Project Sponsor will help with definition of the high-level project Vision and Objectives.

Use the Vision and Objectives as a reference point throughout the project

I have found that writing down a really clear set of measurable objectives for a project can be really beneficial. It is then really clear to everyone what success will look like when the project is completed. If done well, they should be cross-reference throughout the project to ensure what is being delivered is compliant with the objectives.

The objectives need to be agreed with Sponsor and validated with the Key Stakeholders. They should be stated unambiguously ie there is no room for different interpretations of the objective and typically you should aim for a minimum of 5-7 depending on the size of the project. They are closely linked to the Business Case and can be used as a reference framework for creating detailed requirements, and defining the of scope for deliverables.

Ready for detailed planning

With these project planning fundamentals in place then hopefully you can see that you have everything in place to start the main planning activity on your project as part of the Project Initiation process.

It all starts with the Project Sponsor – they will define at a high level what the project is about. They will also tell you who the main Project Stakeholders are. The Sponsor will also tell you the main business drivers for the project – ie why we are doing the project.

When you know who the Stakeholders are, then you can talk to them to start to scope out the detail of the project in terms of the project requirements, deliverables and constraints. You can also then start to work out what the key project objectives are and agree a vision with the stakeholders and sponsor.

You are now ready to start the detailed planning.

For a much more in-depth walkthrough you can also try our FREE Training course that will take you step by step through the process of setting your project up for success.

Featured

We Are Agile So We Don’t Need Project Managers Any More

In this article I look at how Agile software development works with Project Management. I struggled with this for a long time during my gradual conversion to Agile ways of working so hopefully this article can help you to get a better understanding.

The subject came up in conversation recently when someone said to me “We are Agile, so we don’t need Project Managers anymore”.

So how does this work, is it true and what does it mean?

Well the answer to this very much depends on how mature Agile software delivery is in your organisation.

Agile delivery should need fewer Project Managers

If you are running Agile software delivery, then you should be aiming to reduce the need for Project Managers in your organisation. How far you can go with this will depend on a number of factors including:

  • How mature your Agile delivery organisation is
  • Size and complexity of projects being delivered
  • Types of projects and the product being delivered
  • How many customers, suppliers and stakeholders you need to work with

Agile software maturity

Mature Agile software teams and organisations have these characteristics:

  • Strong Product Management and Product Ownership for defining product strategy, direction and requirements
  • Software teams building to coordinated Product Roadmaps
  • Minimal barriers between teams
  • Technologies, toolsets, processes and practices aligned with Agile delivery
  • Long term stable teams which are able to re-organise and change shape with minimal impact to the overall product delivery
  • High degree of buy-in for Agile delivery across the organisation
  • Long term department level budgeting rather than project by project basis

Agile delivery is focussed on the team and the product

Agile software teams are focussed on building products for users defined by a business expert in the shape of the Product Owner. It’s all about getting a product into the hands of real users as quickly as possible and iterating from there.

The Scrum Master’s role is to facilitate effective delivery of the team. They are focussed on ensuring that the team have everything they need to perform at their best velocity.

They will ensure the Agile ceremonies and processes; stand-up, retrospectives, Kanban board etc. are run effectively. They will work closely with the team and Product Owner to plan ahead and remove obstacles in front of the team. They may well work closely with external customers too within the context of the product delivery itself.

Project Management more focussed on managing stakeholders

The Project Manager has more of a dual role – firstly working with project teams to deliver the products into the project but also a large part of the role is to manage, coordinate and communicate with the various groups involved in the project.

The main activities for a Project Manager would include the following:

  • Managing stakeholders, customers, suppliers and delivery teams
  • Communicating across all of the groups involved in the project
  • Running the project finances and budget
  • Forecasting and planning the project timelines
  • Managing and communicating risks and issues
  • Coordinating all of the different groups involved in the project and managing dependencies

All of this activity can be really time consuming and as the size of the project increases the more effort this takes.

Scrum Master can pick up some Project Management activities

In some smaller projects the Scrum Master and / or Product Manager can pick up some of the above Project Management activities. This works fine for many projects but as soon as the project reaches a certain size then this becomes unmanageable for them.

The key issue in this scenario is that the Scrum Master needs to focus on the software development team and the Agile delivery process. If they become too focussed on Project Management activities, then the software delivery will start to slip.

Project Managers needed when project size and complexity increases

In the projects and programmes that I run we will typically bring in a Project Manager when we have these types of projects to manage:

  • Larger projects where there are several teams and departments working on a project
  • Projects where there are a mix of external suppliers and internal delivery teams
  • Projects where there are multiple stakeholder groups and delivery teams
  • Projects that include a significant change to business processes or the way users will use a product eg. that might require significant training effort and coordination
  • Projects where delivery teams are running both Agile and waterfall project delivery

Essentially as soon as the amount of project management stuff to do becomes significant then someone needs to dedicate their time to running that.

Let’s look at some examples to highlight these points.

Example Scenario 1 – Project with large number of stakeholders to manage

In this common scenario you may have a project to deliver to an external customer. You have three internal Agile software teams delivering their product enhancements to the project. You also have two new suppliers delivering their products that integrate with the products delivered by the internal Agile software teams. You are delivering on behalf of your Sales team to the customer.

Project Manager needed to coordinate different groups

This project will need a Project Manager to work with all of the parties involved. There are numerous groups to coordinate, manage and communicate with including the customer, the sales team, the suppliers, and the software teams.

The Project Manager will need to work with the suppliers to agree the delivery scope, costs, plan and approach and get this agreed within the company and then manage them through the project. Contracts will also likely need to be written and agreed.

Agile teams also deliver into the project

In terms of Agile delivery on this project – the three software teams would be delivering their products into the project and the Project Manager would be working with the team Product Owner and Scrum Master to coordinate priorities, dependencies, timelines and communications to all stakeholders.

Example Scenario 2 – In house software project across multiple teams

In this scenario a company wants to deliver a significant new set of product features on its large web-based business application. There are three Agile software teams working in the same department delivering a set of products for the web-based application. They are also working with two other Agile delivery teams in the same company, but different departments.

Mature Agile software teams with Roadmaps and Product Management

All of the software teams are working to Product Roadmaps, have good Product Management and Agile Product Ownership in place and have permanent standing teams that are budgeted as part of operations rather than on a project basis.

In this scenario the project could be delivered as a Product Management driven initiative without the need for a Project Manager. Because of the structure and maturity of this organisation the Project Management activities in this example are far fewer and could be picked up by the Product Management team. Planning and coordinating activities are done between teams and put into the individual team product roadmaps.

Some Project Management activities disappear

Most of the other Project Management activity has been removed – there are no external suppliers, no contracts to worry about, no external customers and no budget to manage. The barriers between teams should be low and dependencies can easily be managed between the Scrum Masters of the teams based on prioritisation by the Product Management team.

This is a mature Agile software organisation and it takes time and dedication to build this level of capability, but it is worth it as the productivity advantages and business agility it offers are great.

We are Agile but we do sometimes need Project Managers

So, we can see that in really mature Agile delivery organisations we really can reduce the need for Project Managers. However as soon as there are elements of complexity thrown into the mix such as suppliers, customers and larger delivery projects then the coordination, planning and communications activities required means we need a Project Manager to take on all of these activities.

Featured

Why Small Projects Take Too Long

Small projects are easy right?

People tend to think that “small” projects equals “simple” projects – but in my experience small projects can be really frustrating to manage and consume a disproportionate amount of time to their size.

Project Managers often need to be quite tenacious and really exercise all of their skills and experience to get them finished. They will often be juggling multiple small projects at the same time or together with a larger project.

In this article I explore some of the constraints on small projects. I also outline some typical types of small project, how they come about, the associated challenges and some strategies for running them.

Note – it should be said, at this point, that size is relative and small in one organization doesn’t necessarily translate directly to small in another organization so you will need to adapt this information to your own organization.

Small project constraints are the same as any other project

All projects operate within a set of constraints in terms of the scope that can be delivered in some timescale to some agreed budget.

Small projects will typically have to deliver a limited scope, but they may have constraints on budget which could manifest itself as follows:

  • Project Management time available is small (say 1-2 days per week)
  • Resources or delivery team limitations such as time available or ability to increase team size or capacity

Limiting the time available on a small project can actually be beneficial as we will see later. This assumes that there are less constraints on budget and scope.

There are also other constraints that impact small projects.

Small projects are often “lower priority” projects

Small projects can often be lower priority projects for the delivery team. This may be fine if the project gradually works its way up the priority list and gets completed as planned. However, this can become problematic if it gets bumped down the priority list repeatedly.

The impact of this could be on other dependent activities and extended timelines for your project.

The Project Manager needs to address this with whoever manages the delivery team and also seek help to increase the priority via the Project Board.

Low priority extends timelines so use time as a project driver

A project with a low priority will mean that time constraints have been lowered, removed or become flexible. Whilst having unrealistic timelines in a project can be a bad thing, having a project with flexible or changing time constraints can also be a bad thing too.

Having a time driver can be really beneficial as a focus for getting a small project done and out of the way.

The Project Manager should do all they can to raise the issue with their Project Board for assistance and also negotiate with whoever prioritises the work in project delivery teams. 

Some typical small projects

There are a number of other types of projects that present challenges for the Project Manager. They are often associated with small projects.

The “unloved essential” project

This type of project may be seen as essential by the Project Sponsor but no-one else involved is bought into it or wants to do it. The Sponsor normally has a good business reason for doing the project but there is a disconnect between the technical delivery team and business viewpoints.

Sometimes you also get a disconnect between the people managing the delivery team and the sponsor.

What you have here is a disagreement in the priority level. This can be even harder if the disagreement is not explicit ie people are saying one thing and doing another – so they may appear to be supporting the project but in reality, they are not backing it. This rubs off on the delivery team and the result is slow delivery, lack of focus and often lots of moaning from the delivery team as they would rather be doing work that they see as higher priority (and so do their managers).

The Project Manager needs to get hold of this and try as many of these as possible:

  • Meet with the Sponsor, Key Stakeholders and Managers of the delivery team to discuss and clarify the priority of the project
  • Question the need to do the project and get it stopped if possible
  • Cut scope to the bare minimum
  • Push to get the project finished and out of the way
  • Communicate any agreements to all involved in the project

The “post-launch phase” project

This type of small project could be a mopping up phase, final phase or decommissioning phase of a much bigger project that has been running for a long time. Typically, the main launch has been completed but there is still a body of work to complete. Often these types of projects are handed over to more junior project managers to complete.

These can often be quite good projects to run but the problem here is that sometimes the urgency element has gone out of the project so getting traction can be difficult.

Another challenge with decommissioning type projects is that they can actually be quite complex and involved to unpick from a technical level.

Another challenge with these types of project is that they are often handed over mid-flight so this process can be a bit messy.

It is really important for the Project Manager to either setup the project properly from scratch or do a project audit to establish the real status of the project and set it up for success. I cover this later in the article.

The “must do but tricky” project

These types of project can be challenging because although the work required may appear to be small in fact it may be tricky, boring, time consuming or just really difficult to do. So, if it is also lower down the priority list too then project teams tend to put it off as long as possible in preference for other more straight forward work.

This can obviously delay the project.

The Project Manager needs to tackle this head on and urge the team to take on the challenge, support them as much as possible, make tea, offer cake or do whatever it takes to get the project done.

The small “nearly finished” project

I’ve been handed a few of these small projects in my time – the ones that I could run in my “spare time” – one of them took nearly 2 years to finish. The Project Manager is taking over an in-flight project, so they need to get a handle on it quickly.

The problem here is that someone has perceived the project as small and nearly finished. You need to go in with your eyes open and make your own assessment of what the true position is.

One really effective approach is to run a really quick project audit – I have outlined how to do this in a later section.

The “important low priority” project

These ones are always a challenge to run. Typically the organization really wants to do the project. They may even have to do the project to reduce business risk, comply with some regulations or some other important reason. However – the importance and priority never really quite makes it far enough up the priority list and so gets pushed back and back. Sometimes the project may have been started and some elements finished but has since sat on the shelf to come back to later.

The only real way to tackle these types of project is the same as the “unloved essential project” ie by trying as many of these as possible:

  • Meet with the Sponsor, Key Stakeholders and Managers of the delivery team to discuss and clarify the priority of the project
  • Question the need to do the project and get it stopped if possible
  • Cut scope to the bare minimum
  • Push to get the project finished and out of the way
  • Communicate any agreements to all involved in the project

How to tackle small projects

There are many ways to tackle small projects, but the key is to run them as you would any other project.

Light weight Project Management process

All projects benefit from using a repeatable Project Management framework or process. This is no different for small projects – it simply means that some of the processes and governance put in place will need to be simplified and pared back to a minimum, but still effective, level.

Starting a small project from scratch

Using a standard planning and startup process will really help the project. This should be documented. The project startup framework should cover the following:

  • Identifying the Project Sponsor and Key Stakeholders
  • Understanding the project requirements, scope and deliverables
  • Defining the project benefits and criteria for success
  • Identifying and establishing the project delivery teams and any suppliers
  • Agreeing the delivery approach, timelines and delivery schedule
  • Setting up a simple governance process

I covered this in a separate post How To Start Your Project Faster.

Once the project is planned and approved to start then the project needs to be managed closely but efficiently.

Taking over projects in mid-flight

Some of the small projects outlined above had the scenario where the project was handed over to someone else in mid-flight – this can be a bit messy but again the project needs to be established or re-established on a solid footing.

If you are taking over the project you need to understand where we are on the project. One method is to run through the Project startup framework and fill out a standard plan to understand the project in its entirety. This may be just for the benefit of the Project Manager’s understanding, but it is really effective for getting to grips on what the project is all about.

Project audit

Another method effective method is to run a project audit.

Asking lots of questions like these can help to understand the true picture:

  • What is the scope of the project?
  • What has been delivered?
  • What is there left to deliver?
  • When is this forecasted to be complete?
  • Do we think we are going to be able to deliver this?
  • Is the team on track to deliver?
  • Are there any issues, blockers or risks to the delivery timeline?
  • What is the project budget, how much has been used so far and is it enough to complete the project?

Simple project governance

On small projects it is essential to run a simple light weight governance process. This will help to tackle the challenges around project prioritization and keep everyone up to date on the challenges of the project.  The minimum governance I would run would be this:

  • Regular Project Report:
    • Weekly or fortnightly (but always done)
    • Issued to Sponsor and key Stakeholders via email
    • Includes Progress update against plan and summary of risks and issues
    • One-page summary should be the max required here
  • Project Board:
    • Monthly if possible
    • With Sponsor and key Stakeholders
    • Progress update against plan, and budget since last meeting
    • Summary of risks and issues and any help needed
    • Decisions to be made
    • A few simple slides should suffice for this

Small projects are fun

As we have seen running small projects has its challenges. However, if they are run in the same manner as any other project, but with a lighter weight set of processes, they can be run quite smoothly and effectively. They can also be quite fun to run as you can run a number of them together and you get the satisfaction of finishing things and moving onto the next project.

Featured

How To Start Your Project Faster

Getting your project started correctly is the foundation to the future success of the project. If you don’t start the project off properly you will find it challenging to get it back on track later on.

Avoid the temptation to just get going with the project

There is a temptation to just get going on the project without some of the key project fundamentals in place. Avoid this approach at all costs – you will pay for it later.

You may initially come flying out of the blocks, everything will go great for the first few weeks, even a few months, and then gradually you will get into a quagmire and everything will slow down to a crawl. At the start everyone was really excited to be working on something new – but things aren’t going quite so well now.  People are uncertain about what the project is about, where it is heading and who is doing what.

Get the project fundamentals in place

This is actually quite common with projects and even happens with some experienced Project Managers. Most often I have seen this happen when the project has not been setup properly from the start. Specifically – I mean that some of the project fundamentals are not in place. These are typically some, or all, of the following:

  • Unclear business owner (sponsor) for the project
  • Unclear reasons for doing the project
  • Unclear project objectives ie what the project is aiming to deliver
  • Unclear definition of what success looks like for the project
  • Unclear roles and responsibilities on the project ie who is responsible for what
  • Unclear understanding of who the project is for, how they are impacted and what influence they have in the decision making processes in the project

These are the fundamental aspects that need to be understood before you can even start to get deeper into the project planning to understand what the detailed requirements are, what will be delivered and then start to estimate timescales and costs on the project.

Document the key project elements in the Project Plan

Another key point to make is that this must be written down. It is remarkable the number of times that I have seen troubled projects in mid flight without these fundamentals in place, with only some vague or very out of date agreements in place. If it isn’t written down people then either forget some of the specifics about what the project is about, or purposefully change what the project is about along the way.

Changing the scope, direction and deliverables on a project is fine as long as everyone involved understands what the impact of the changes are and agrees to the changed approach. Often these changes are subtle and can appear to be small in nature but when added up they can have a major impact. If nothing is written down there is no reference point for making these decisions.

If you build the project on shaky foundations you are not setting the project up for success and as a minimum the project will not proceed as fast and smoothly as you want and at the other end of the scale can lead to disagreement and plenty of stress for everyone.

So how do we set up the project for success?

Create a comprehensive Project Plan

A Project Plan is more than just a timeline – lets clarify our terminology here – I will call the plan the “Project Plan” document. I have worked in many organisations and the name of this document can vary from place to place. It is also often called a “Project Initiation Document” or PID (a PRINCE methodology term) or sometimes it can be called a “Terms of reference” (ToR), if it is to be used as an external customer facing document it may be called a “Proposal” or even a “Statement of Work” (SoW). However essentially all of these documents have similar content. The purpose of the Project Plan is to outline the key elements of the project.

Project Plan sections

The Project Plan is the written down specification, or shared view of the project and it is used as the reference document on the project so that everyone involved agrees what the project is about and what it will deliver. It can be quite a lengthy document and should have the following sections:

  • Project Overview
  • Vision
  • Business case and benefits
  • Objectives
  • Sponsor and key stakeholders
  • Requirements summary
  • Deliverables and outcomes
  • Main activities
  • Organisation and delivery team
  • Project delivery approach
  • Timelines and schedules
  • Governance
  • Finances
  • Key Risks

Creating the Project Plan is time consuming but worth the effort

Creating (writing down) the Project Plan can be a time consuming and laborious task – this is one of the reasons why it is often done so poorly. It should be written before the project starts but is often written at the very start of the project.

The work, of course, is not just in documenting the plan but in gathering all the information together from everyone involved, then writing it down and then walking it through with everyone again to make sure what you have written down is in fact what they said. Then you have the process of negotiation between all the different stakeholders. Eventually, all being well you get agreement and get the Project Plan signed-off and you can officially start the project.

The process of documenting the plan helps clarify the project itself

There is often huge pressure to “get going with the project” rather than “messing around” writing things down at the start. However the mere process of writing the Project Plan down and getting the agreements in place enables everyone to get great clarity on the project. So it is all about the process of creating the Project Plan and the by-product is the document itself. This pays huge dividends later on in the project. If you don’t do it at the start, then you will end up doing it later on under even more stressful conditions when the project is going off track.

I liken not doing a Project Plan at the start to taking off in a plane with no clear idea on where you are going, how you are going to get there and if you have a enough fuel in the tanks – it might work out but there is a good chance that it won’t.

5 key questions to start your Project Plan

Before you can into the actual planning of the project in terms of deliverables, approach, timescales and cost you need to know 5 key things about the project:

  • Who wants the project?
  • What is the project about?
  • Why are we doing the project?
  • Who is impacted by the project?
  • What does success look like for the project

In order to answer these questions you need to identify the Project Sponsor and Key Stakeholders. They will then help you understand the project Business case and benefits and project Objectives.

These are the first few sections of the Project Plan and it makes good sense to “start at the start”. If you don’t have the first few sections confirmed you are going to have a lot of trouble getting the later sections of the Project Plan agreed and written down.

Understanding the Project Sponsor role

The Project Sponsor is the person who wants the project and is typically the person paying for, or funding, the project. It is preferable to have one sponsor as you have only one person to deal with. Projects with multiple sponsors require more project management time as there is the potential to have conflicting requirements and the potential for people to pull the project in different directions.

The Sponsor may also be one of the main stakeholders in the project (see next section) and they can be seen as the main customer and the key decision maker in the project. It is really important to be clear on who the Sponsor (not always as straightforward as it should be) is and the role they will play on the project. They will set the direction for the project and will help you outline the key objectives, requirements and deliverables for the project. They may have a senior role and therefore be busy and sometimes delegate their responsibilities to someone else in the project. Whatever the position this is a key role for the success of the project.

Identifying the Stakeholders

A Project Stakeholder is anyone impacted by the project. In any project there are likely to be multiple stakeholders. The project manager needs to

  • Identify all the stakeholders or groups of stakeholders
  • Identify which are the key stakeholders (normally the ones most impacted by the project)

The key stakeholders will help you define the project requirements and will help you define how the project will need to be approached. They will also provide you with some of the constraints that the project has to work within.

The Project Manager will work closely with the Key Stakeholders or the people that represent the main stakeholder groups.

Understanding the Business Case and benefits

The Sponsor should be able to articulate the business drivers, benefits and case for doing the project. Often there will be a detailed Business Case that is agreed before the project has authorisation to start (this is often dependent on the organisation or type of project).

The business case should be summarised in the Project Plan. This can then be used as a reference point throughout the project to ensure that what is being delivered matches with what the sponsor requires. If there is a request for change in requirements, deliverables etc. then this should be referenced against the Business Case and clarified with the Sponsor.

There could be many different business drivers for a project. Some of the typical ones are as follows:

  • Improve efficiencies and reduce operational running costs
  • Deliver a new product or service
  • Meet a set of legal requirements, standards or regulations

Where possible the business case should state the specific values such as time, cost saved, revenue expected etc.

Project objectives and defining success

I have found that writing down a really clear set of measurable objectives for a project can be really beneficial. It is then really clear to everyone what success will look like when the project is completed. If done well they should be cross-reference throughout the project to ensure what is being delivered is compliant with the objectives.

The objectives need to be agreed with Sponsor and validated with the Key Stakeholders. They should be stated unambiguously ie there is no room for different interpretations of the objective and typically you should aim for a minimum of 5-7 depending on the size of the project. They are closely linked to the Business case and benefits can be used as a reference framework for creating detailed requirements and definition of scope for deliverables and outcomes.

Next steps – planning the project delivery

With these project planning fundamentals in place then hopefully you can see that you have everything in place to start the main planning activity on your project. As stated if you aren’t clear on who wants the project (Sponsor) and who is impacted by the project (Stakeholders) then it is very difficult to have any meaningful discussions about project requirements and from there drive out what the project deliverables and outcomes will be. From there you can build out the rest of the Project Plan and start to plan timelines and costs.

Good luck with your Project Plan!

Chris Wilson

5 Project Team Blockers Making Your Project Late

What project team blockers are making your project late?

There are many reasons why projects become late but often project teams are operating under severe constraints. In this article I will be looking at the typical constraints, blockers and impediments for project teams. The key here is that understanding why the teams are blocked is the first step to working out what to do to fix it.

Quick definition of a project team

But before we start let me just clarify that when I talk about a “Project team” I mean a Delivery team, software team or some sort of Engineering team. However, many of the constraints mentioned here also apply to teams that are not working in a specific project context. For example, Agile software teams may, or may not, be working on projects but may be delivering software for product roadmaps etc. these constraints will often apply to these teams too.

So, what are the typical constraints?

Common project team delivery constraints

1. Mixing Operations and Project work

I have seen this one so many times that I would say that this happens on almost every project that I work on. This is the situation where, for example, an engineering team has an operational role to support an existing set of systems. In addition to this they are also given project work to upgrade, change, or enhance these systems. Often these teams are the resident experts in a particular domain, business area or technology and so are key to the organisation.

The challenges with these teams are as follows:

  • Operations work takes priority over project work
  • Users pressurise the Operations team to fix their issues asap
  • Even non-urgent critical Operations work gets prioritised above project work
  • Operational issues come in at random and so are very hard to forecast
  • Operations issues may involve significant analysis and fault finding to find the cause of the issue before it can be resolved
  • The size and volume of the issues is hard to predict and therefore plan for

The impact here is that the team members are taken off project work to work on operations issues. This will stop your project work dead in its tracks.

The only way to resolve this is to somehow separate out the project work and operations work – they are completely incompatible activities. Operations work will always take priority so if the team is also to do project work then part of the team needs to be dedicated to that work only.

2. Too many distractions and interruptions

A similar one to the previous point is that members of the project team (normally senior, experienced people) are continually interrupted. This can take the form of:

  • “Drop ins” or people walking by someone’s desk to ask a question or put in a request
  • People emailing or messaging for information from one key person
  • The expert(s) being pulled into meetings to share their knowledge or consult on issues or challenges in other areas

This is a “Hero” culture and very common. It is much easier, and quicker, to ask the expert rather than find out yourself or ask someone with slightly less knowledge or experience.

Assuming that the expert is a key part of your project team then this will delay or stop your project work getting completed. The challenges are the same as in point 1 – it’s really hard to forecast project work timescales due to the random nature of the interruptions.

There is also another issue here that the hero culture is perpetuated as the only people that get to work on the hard challenges is the expert, the rest of the team don’t get to learn, and this makes the dependency even worse.

In order to resolve this the hero culture needs to be tackled and that will take time. You may not have much time on your project so you will have to make some first steps in this direction. The first thing I would do is: gather the project team together and discuss the issue as a team. I would then work out some ideas for tackling this problem with the team and try them out. The flip side to this of course, is that as well as getting the team better managing their interruptions; then you will also need to talk through a plan for the people that are making the interruptions – if you don’t do this part nothing will change.

3. Poor planning ahead and hitting blockers

Good project teams deliver a steady flow of completed work. Inefficient teams, who don’t plan ahead, hit problems and blockers. Sometimes they can’t see why this is happening until it is pointed out to them.

The symptoms of this are:

  • Large number of items of work in-progress at the same time (I once had a team who had over 50 items of work in-progress – err no you haven’t – 45 of them are blocked!)
  • Lots of work items started but not much being finished ie no “flow” of finished items
  • Team often run into blockers and have to stop one piece of work and start something else until the blocker is removed
  • Team often waiting for other teams to complete tasks before they can start work

The impact of this is as follows:

  • Slow progress
  • Feeling of lack of achievement as lots of blockers and not much delivered
  • Reputation for poor delivery

This is about breaking down tasks into sufficient detail, dependency management and planning ahead. The way to tackle this is to work with the project team to plan ahead. You should run regular planning sessions – the next 2-4 weeks needs to have a fairly detailed plan with dependencies and potential blockers identified and action plan to resolve. Further out than 4 weeks needs a less detailed plan – but blockers or dependencies that are big or time consuming need planning well in advance.

The aim is to start finishing things and enable better forecasting – this will have a big impact on the team as they will have greater sense of achievement and not have to stop-start and revisit things.

4. Significant new learning required as part of the project

Project teams, by definition, build new things – however some projects are delivering completely new things that have never been done before by that team or organisation, whilst other project teams might be delivering something that is very similar to what they have delivered before.

So, if there is a significant “new” element to the project that the project team has not done before then this needs to be factored into planning and forecasting. In my experience this always takes much longer than everyone estimates. Typical “new” elements might be:

  • New or unfamiliar technologies
  • New or unfamiliar business domain
  • Undocumented legacy system requiring significant understanding and translation to new business and / or technologies

All of these scenarios require the project team to allocate significant learning time to understand the problem, only then can they come up with a design and understand what the potential solutions are. It is often difficult to estimate timescales on this.

There is no short cutting this challenge on a project. One option to consider is to allocate a specific Proof of Concept or Feasibility phase to this problem. This is essentially a mini project within itself to really get to the detail of the problem, understand the requirements, solution options and delivery plan.

5. New (project) teams take time to get established

  • Recruitment of senior leaders in the team
  • Recruitment of rest of the delivery team (probably by senior leaders above)
  • Build team baseline tools and processes for delivery

It always surprises me how long it takes to establish new teams. What I mean by that is: getting to the point where the team is really in flow and delivering at a strong pace. The challenge is that many projects have to form new teams as part of the project. Getting the team up and running takes time and impacts the project timelines. Setting up new teams can include some or all of the following:

Setting up a brand-new project team is a hugely time-consuming process and only once a team has been running for some time can you even start to consider planning and forecasting work items and project plans. If building a new team is part of the project then you need to discuss this with your project sponsor and stakeholders so that they are really clear that this will take time to setup.

Understanding team constraints is the first step to fixing blockers

So, in this article we have looked at some of the typical constraints, blockers and impediments for project teams. The key here is that understanding why the teams are blocked is the first step to working out what to do to fix it.

Chris Wilson

How To Write Better Project Status Reports

As a first-time Project Manager good communication is an essential skill that you need to learn quickly. All Project Managers need to be good communicators and to update their stakeholders with a regular status update in the form of a weekly project report.

Project Managers do not enjoy doing them, and they are often done quite badly, but they are an essential method of communication on projects and, if done properly, they can help the project run more smoothly.

What’s the problem with project reports?

There are a number of problems with project reports, I think.

From the Project Manager’s view point – they hate doing weekly project reports for these reasons:

  • They are time consuming to write
  • They find them difficult to write as they are trying to find something different or new to say about their project each week
  • The mere fact that they hate doing them makes them more of a chore
  • Finally – they also have a nagging suspicion that no-one actually reads them – so why put all that effort in?

From the audience viewpoint i.e. the people reading the report, I see a number of problems with weekly reports that I read every week as part of my role as a Programme Manager:

  • Report is too wordy, waffles too much, is too long and complicated to read
  • Report has too much technical jargon which is hard to penetrate or understand
  • It is hard to get to the really valuable information
  • Highlights information that is irrelevant to the audience
  • Doesn’t highlight important information or underplays its significance

So how do we improve weekly reports?

What’s the purpose of the project report?

Let’s start by looking at why we are doing the weekly project report. What purpose does it serve and what are we trying to achieve?

Communicating regularly to your project stakeholders and also keeping your project delivery team in the loop in terms of what is going on in the wider project, and what is being communicated to stakeholders is a good thing.

The weekly report is the opportunity to keep a wide group of people involved in the project up to date with what is going on in the project.

The audience for weekly report falls, broadly speaking, into three categories

  1. The business stakeholders – including management, customers and users
  2. The project governance team such as Project Management Office (PMO) or managers of the Project Manager – they are concerned with ensuring that the project is under control
  3. The Project delivery team – the team(s) working on the project day to day including suppliers. They will know quite a lot about the project progress but may not be across all the different areas of the project

I have also known Project Managers to send their weekly report to their project delivery team first for review before it is sent out to wider list of stakeholders – this is a great idea, I think.

What qualifies as good communication?

When writing the weekly project report, it is essential that you focus on what the audience want to get updated on. The content is covered in a later section but here are some guidelines:

  • Keep the information clear and to the point
  • Ensure the information is up to date and correct
  • Keep jargon to a minimum
  • Keep it brief, but not so brief that it is hard to understand – use sentences and good grammar
  • Ensure the information is relevant to the audience
  • Ensure important information is highlighted
  • Avoid repetition

How often should we do a project report?

Ideally you should be writing a project report every week. The more often the Project Manager writes it, the easier it should be to update. It is a lot to easier to remember what you did in the last week, whereas sometimes 2 weeks in a project seems like a long time to remember exactly what has been achieved. However, this is dependent on the project itself and also where you are in the project lifecycle.

Not every project is going flat out for the whole time. In some phases of the project there might not actually be much going on for a few weeks, so there might not be much to report. In this situation I would negotiate with your key stakeholders and request that you push the project report frequency out to every 2 weeks. You can always go back to weekly again when the project pace picks back up again.

In some organisations they do project reports once a month. I would question the value of that. The overhead for the Project Manager is high as this would take quite a long time to go back through the months’ worth of work to write the report. It would also be likely quite out of date.

My preference is for weekly project reporting to ensure the regular flow of information to the project stakeholders and also so that we can act quickly on any concerns, risks or issues.

How long should it take to write a project report?

I would argue that a Project Manager should be able to write a project update in 15-30 minutes. If it is taking longer than that they are spending too much time on this. There are occasions when you might need a bit longer to do an update and it will depend on the size of the project and on how busy and fast paced the project is, but I would still aim for the 15-30 minutes.

Report format and delivery method

My preference for weekly reports is a text document in MS Word, GoogleDocs or similar. This should be maximum 1-2 pages.

Sometimes a presentation type format such as MS PowerPoint or GoogleSlides is used – this is quite common particularly in projects which are part of a larger programme. The same content should be included as per next section.

Sometimes a simple email will suffice as long as it summarises the information as outlined in the next section.

My preference for distribution of the weekly report is via email – either with the file itself or a link to where the file can be found.

Don’t forget to date the files and email subject headings so that reports can be easily searched at a later date.

What should be communicated in the project report?

I have outlined a typical format for the project report below. The format may vary between organisations, but the content should be similar to that outlined below.

Weekly Report 
Project <Name>                      <Date>
What’s been achieved this week:
<approx. 3-5 bullet points>
 
What’s planned for next week:
<approx. 3-5 bullet points>
   
Main Issues:
Issue 1 – brief summary and action plan
Etc.
Key Milestones
Milestone 1, status (red, amber, green, done), and forecast date
Etc.  

Key Risks:
Risk 1 – brief summary and action plan Etc.    


When to distribute the weekly report

Reports are often issued by Project Managers at the end of the week, but this can also be dictated by what project meetings are scheduled for the week. So, the Project Report contents can be discussed in these meetings. So generally speaking, late Thursday, Friday or early Monday are the most common days I would say.

What not to communicate in a weekly project report

Clearly the weekly project report is used to communicate information about the project to a wide audience and highlight challenges, risks and issues. However, I would not use the project report to highlight new information to the audience as the first point of communication.

If you need to highlight project challenges, issues, risks, budget changes or changes to timelines I would use your regular project meetings, monthly Project Boards or one to one meetings with stakeholders to communicate this information before you put it on the weekly report.

People don’t tend to like surprises or feeling like they are the last to know about issues and challenges on the project. I have seen many mini stakeholder rebellions and extra project management calming work created because of one small sentence in a project report. The Project Manager’s role is to keep everything under control and running smoothly not create extra communications challenges – whether well intentioned or not.

Happy report writing

So you should have a set of useful tools and pointers which you can now use to produce your weekly reports more efficiently and effectively. Good luck.

Chris Wilson

How To Manage Project Risk

Find out how to manage project risk by identifying it early, communicating it clearly and managing it effectively.

Are you on top of your project risks? Do you struggle writing risk statements and communicating them effectively? Do you run a Project Risk Log but find it tedious to update? Does everyone understand what the really important risks are on your project? Do you have endless debates about what a risk is and what it isn’t?

You are not alone…..

Let’s face it: Project Risk Management is not exactly the sexiest subject is it?  I think every Project Manager struggles with Risk Management at some stage and even very experienced Project Managers find communicating risk effectively a challenge.

Common mistakes when communicating project risks

From my experience working with Project Managers everyday, the main issue seems to be around communicating risks, rather than the actual mitigation and management of the risks themselves.

These are the most common issues that I see with communicating project risks:

  • The risk statement is too vague or unclear
  • The impact of the risk is unclear
  • The likelihood of the risk happening, and the impact on the project if the risk happens are not really clear or missing completely
  • The risk statement will not be understood by the audience the risk is being communicated to, for example it may be explained in very technical terms for a non-technical audience
  • The risk stated is out of date, has changed or morphed into something else
  • The risk stated is irrelevant or pitched at the wrong level to the audience
  • The risk statement contains several risks bundled together
  • Important risks that need to be communicated are missed but less important risks are highlighted instead

So lets get back to basics…… and ask ourselves a question

What are we trying to achieve with Project Risk Management?

I believe a key part of Project Manager’s role is to manage risk on a day-to-day basis – it is not a “once a week” or “once a month” thing. What I mean by managing risk is this:

  • Identify risks
  • Understand the potential impact of the risks
  • Communicate risks at the correct level to the right people
  • Mitigate risks

So lets break this down in a bit more detail.

How to identify project risks

The answer is quite simple – by talking to people!

In most cases the people that will be able to identify the risks on the project are the people that are involved in it day to day.

I would advocate discussing risk as part of your everyday project activities rather than operating it as a separate risk analysis process. If it is baked into the project then it becomes easy to update the Risk Log as we go along. The key to success here is: little and often.

There are however a couple of times in the project where I would break this rule.  At the very start of the project I would gather all of the people involved in the project, such as the delivery team and as many stakeholders as possible and I would run a session to identify all the risks that anyone can think of for the project. I have often done this as part of a project kick off workshop and have found it to be extremely useful to understand people’s view of the risks from many different angles.

The other time I would spend specific time allocated to Risk on the project is when you are just about to enter a critical phase of the project for example if you are doing a big launch of a system. I would carve out some time to focus on the specifics around risks around the launch and also spend some time looking at how they can be mitigated.

Other than these two specific scenarios I would be working with the project delivery team and stakeholders on a daily basis to assess where we are, what risks we are working on and what we can see coming up. I would also expect everyone involved to flag any risks to me at the earliest opportunity.

How to write a good risk statement

The key to stating project risks properly is to make sure they are written in a way that is clearly understood by the audience reading the risk.

I like to phrase risks using this format:

“If <event X> happens then there is a risk that the project will be impacted in <Y way>”

For example:

  1. If the new servers are not delivered by 10th February, then there is a risk that the commissioning engineers will not be able to start on the 11th and so there could be a delay to the project timeline.

Broken down:  If [EVENT] the new servers are not delivered by 10th February, then there is a risk that the [IMPACT] commissioning engineers will not be able to start on the 11th and so there could be a [REAL IMPACT] delay to the project timeline

2. If the new HR software is not delivered by 1st May, then we may have to extend the contracts for the HR software testing team meaning there would be an increase in budget required.

Broken down:  If [EVENT] the new HR software is not delivered by 1st May, then we may have to [IMPACT] extend the contracts for the HR software testing team meaning there would be an [REAL IMPACT] increase in budget required.

Rate your risks with an overall risk score

Now we have a good statement of the risk it is useful to rate your risks as follows:

  • Rate the likelihood of the risk happening on a scale of 1 to 5 (1=low, 5= very high)
  • Rate the impact of the risk if it happens on a scale of 1 to 5
  • Multiply the two together to get an overall risk score in range 1-25

The overall risk score is really important as it allows us to then rank our risks highest first. Our main project management effort should be in mitigating our highest scoring risks; that is, the ones that are most likely to occur and will have the highest impact if they do occur.

Additional tips for writing risks:

  • State the risk in unambiguous terms
  • Keep risks “atomic” ie about one thing
  • Explain the risk in terms so that anyone reading the risk will understand it
  • If it is a technical subject attempt to summarize in layman’s terms

The Project Risk Log

Project risks should be documented in a Project Risk Log, which is normally maintained by the Project Manager. The easiest and most flexible tool to use for this is a spreadsheet.

The Risk log should have the following information for each risk identified:

  • Title of the Risk
  • Summary of the risk  – using the format outlined in previous section
  • Summary of the risk impact – using the format outlined in previous section
  • Likelihood of risk – scale 1-5
  • Impact of risk – scale 1-5
  • Overall risk rating – Likelihood x Impact
  • Mitigation plan – summary of actions being taken to mitigate the risk

It can also be useful to log the following information:

  • Risk identifier – eg. R001, R002 etc. so easier to use reference number rather than explaining the risk each time
  • Person who raised the risk – so you can refer back to them for clarity etc.
  • Risk owner – ie the person owning the mitigation actions
  • Proximity of risk – the date when the risk is likely to impact the project
  • Date raised
  • Forecast date for closing risk

Communicating risk at the right level for the audience

As I stated earlier the main focus for the Project Manager is on mitigating the highest-ranking risks. These are also the risks that should be communicated to the Project Sponsor and Key Stakeholders on the project through regular project reporting and/or project governance such as Project Steering Boards.

Keep your risks updated regularly and communicate often. Some risks may require assistance from the Sponsor and/or Stakeholders so get this help as early as possible.

Generally speaking I would try and keep the number of risks highlighted at these governance forums as low as possible – normally 4-7 risks is optimal. If you find that you have some risks that are very similar in nature – you may want to roll these up into summary level risks for communication purposes, but keep the detail in the Risk Log and cross reference the high level risks to the detailed ones so that nothing is lost and any confusions or repetition is avoided.

There is a fine balance to be had between communicating too much technical detail and not making the risks so high level that they are meaningless.

So now everyone is clear on what the risks are on your project. Now all you have to do is run your project and work hard to manage the risk away as soon as you can and keep everyone informed of your progress and get them involved to help you if needed.

The key in project risk management is to share good information, let people know what the challenges are and seek help. Good Luck!

Chris Wilson