The real roles and responsibilities across a project or programme

A project or programme contains a number of roles.  This can be confusing, especially to someone new to project management.  This post explains a number of the key project roles and how they all interact.

The diagram below illustrates a typical programme governance structure.  You will see the PMO is providing support and guidance at all levels.

Diagram showing project roles and responsibilities

Steering Committee (SteerCo)

This should consist of senior management members who are empowered to prioritise and make decisions.  An effective SteerCo should be able to resolve and remove barriers to delivery that cannot be addressed by the programme.

Programme Sponsor

A programme sponsor is accountable for the successful delivery of a programme in line with the signed-off business case and the realisation of associated benefits.  Think of the business case as being a contract between the Programme Sponsor and the organisation i.e. “give me £100 and I will deliver you £200 in savings”.

It is very important to note that, while a Programme Sponsor can delegate the delivery to a Programme Manager, they cannot delegate accountability for the business case.  Therefore, it is important that they ensure that they are comfortable that a suitable Programme Manager is appointed.

A good Programme Sponsor must take an active interest in how the programme is progressing so as to ensure it is being delivered to plan and within agreed budget.

A good Sponsor will also provide the required level of support to make the Programme Manager successful.  This makes complete sense as the success of the Sponsor and Programme Manager are linked.

In summary, the Programme Sponsor must be “passionate” about the business case to give the best chance to succeed.

Programme Manager

Responsible for the complete end-to-end delivery of the programme so as to deliver the business case on behalf of the Sponsor.

This means accountable for all aspects of Business, IT and 3rd party deliverables.  It is no good if the Programme Manager does not feel accountable or have control of all aspects, it will result in challenges and potentially project failure.

It is a bad idea to have 2 programme managers, one responsible for Business the other for IT.  This allows for accountability to fall down the “cracks in the pavement”.  When problems occur, there may be unnecessary time spent debating who was responsible.

By all means appoint a programme manager for Business and one for IT if the programme is large and complex.  However, have a very clearly defined programme structure showing that there is one clear programme manager responsible to the Programme Sponsor.

It should also make it clear that the IT and / or Business programme manager is reporting to the overall programme manager NOT the IT or Business function.

If you get the structure right at the beginning with clear communication, you will be on a solid foundation for success.

Project Team

This is where the work takes place to complete the work packages that make up the deliverables of the programme.  Sometimes known as the “doer’s”.

The team should be structured in a way that each team member knows what they are responsible for, what they need to deliver and by when.

Where possible co-locate the team members.  Not only does it make for a more efficient way of working.  It greatly improves communication and most important of all, makes everyone feel part of one team.

Project / Programme Management Office

The PMO acts as the glue that brings all of the different aspects of the project together.  It is the custodian of the tools and standards used to execute the project.  This ensures consistency.

A very important part of the role is providing visibility and transparency of progress through robust status reporting.  Acting as the central point for all participants to gain updates of progress.

A pro-active PMO will challenge progress and facilitate communication across the project.  This ensures that the different participants get the information they require in a timely manner.


There will usually be a number of stakeholders in the organisation who either have a vested interest, impacted or need to be consulted.  Not all Stakeholders are made equal.  Therefore, it is highly recommended that you conduct a Stakeholder Analysis and management plan.

The PMO is ideally placed to help the information flow to and from Stakeholders and help ease the way of the programme.  Many issues actually occur because people do not feel included or opinion sort.  Good communication goes a long way to address this potential issue.


While this post does not cover the normal basics of the roles and responsibilities, it more importantly provides the context of how the different ‘players’ need to interact and what is really important.  The PMO plays a pivotal role in ensuring transparency and visibility of progress and facilitating the communication of information.

Project management tools – dependency management

Dependency management is a very important discipline for a project manager.  It is the “D” in RAIDs management.

What is a dependency?

gantt showing project dependenciesIn simple terms, a dependency is where a task, milestone or activity is dependent on another task or milestone being completed before it can start or be completed.

It is possible for a project to have intra-dependencies. This is where tasks, milestones, etc within the same project are dependent on each other. The other type of dependency is external. This is where the dependency is on a different project, programme or even business as usual.

A project manager must be aware of all of the dependencies for their project.  The reason is simple, if a dependency is not met, the successful delivery of the project may be threatened.

A smart project manager should call on the services of the  PMO, a good, value adding PMO will be able to facilitate and manage external dependencies as a project manager should have the empowerment and oversight to manage intradependencies.

Dependency tools

In a similar way to the management of risks, issues and assumptions, the simple method of recording and monitoring dependencies is by using a dependency register. This should typically capture:

  • Unique Reference – used to identify dependency
  • Description – used to briefly describe the dependency
  • Enabling Programme / Project – who must deliver the task, milestone, etc (sometimes known as the ‘giver’)
  • Task / Milestone Description – details of the exact milestone / Task that must be delivered
  • Dependent Programme – who needs the task, milestone to be delivered (sometimes known as the ‘receiver’)
  • Dependent Task / Milestone – details of milestone / task that needs the delivery
  • Delivery Date – date dependency must be delivered by to not cause a delay in dependent project
  • Probability – probability that dependency will not be met in required timeline
  • Impact – impact of dependency not being delivered in required timeline
  • Status – open, closed, etc
  • Owner – who owns the dependency
  • Date Raised – date dependency was raised

Other fields can be added to indicate if dependency is on the critical path, etc. However, the above fields should allow for the management of external dependencies.

How to capture dependencies

You will see lots of articles and diagrams that show wonderful process flows for managing dependencies. However, the real skill is identifying what are the dependencies that need to be worried about. This is not an exact science and difficult to fully document. However, the following to be a good approach.

1. Awareness sessions

Get all of the projects and programmes into a workshop, ideally no more than 2 hours. Ahead of the meeting get each project to prepare a one page slide using a standard format. This should provide:

  • Project name
  • Sponsor
  • Project Manager
  • Start / end dates
  • Current status
  • Business area / function
  • Overview of the project
  • Business process being changed
  • Platforms being implemented / changed
  • Key milestones
  • Key issues / risks

In the actual meeting, the PMO lead should set the scene by stating the purpose of the session is to identify any dependencies between projects.  Each sponsor / project manager will then briefly discus their project.  This will allow other project managers to ask questions and identify potential dependencies i.e. where 2 different projects are trying to change the same system at the same time.

At the end of the session you should have:

  • List of potential dependencies
  • Possible dependencies with clear actions for the appropriate project managers to discus after meeting

The PMO can then spend time reviewing and cleansing the list.  Working out the exact milestones where the dependency exists and then play this back to the project managers to agree

2. Agree dependencies

When all of the dependencies have been captured, it is then necessary to work with the project managers on either side of a dependency to confirm and agree that the dates are realistic and achievable.  If not, one of the projects will probably need to re-plan.  The aim is to have all parties in agreement on the delivery date.

3. Monitor and control

The now should be a clear view of dependencies and the associated milestones in the different plans.  The PMO should track progress against these critical milestones as part of the regular meetings and reporting.  When a milestone looks like it is slipping, they can quickly explore if it will be missed and then start the dialogue with the receiving project so as to assess impact and mitigating actions.

However, it is important that each project manager monitors the dependencies that are important for their project.  The same way risks and issues should be reviewed, the project manager and / or the project team should check to make sure that all deliveries on which they are dependent, are on track.


Dependency management can be a very complicated, time consuming activity.  Therefore, think about how many dependencies need to be managed, the ability of the projects to communicate effectively and the impact of dates not being met.  This will then allow you to decide how much time, effort and process you wish / need to commit to dependency management.  However, running a session like the one described above will help open the channels of communication, flush out dependencies and allow for monitoring as part of the normal reporting cycle.

Project risk, issue and assumption management

project risk management processFor any project it is important for the project manager to capture and manage all of the risk, assumptions, issues and dependencies (known as RAID management) for the project they are running. If they do not then they are not doing their job properly.

At this point it is worth clarifying the difference between an Issue and a Risk (it is surprising how many people do not understand the difference). Very simply a risk is something that may impact the successful delivery of a project, an Issue is something that has impacted a project. A project manager who can successfully manage Risks so as to stop them from becoming Issues is worth their salary.  Managing risks so they do not become issues should result in a higher probability of the project outcome being achieved.

In order to manage RAID’s, the project manager should use a structured approach.  If the organisation has a project methodology, the project management office (PMO) should have guidelines and tools. This will normally take the form of:

  • Template to capture Risk, Assumptions, Issues and Dependencies
  • Guide to what and how RAID’s should be captured

There may also eve be additional tools to cover Risk Mitigation Planning.  This is the predefined approach to how a risk will be dealt with.

The template should include:

  • Unique ID
  • Project Name
  • Sub workstream if applicable
  • Risk, Assumption or Issue Name
  • Description
  • Impact
  • For Risks – probability (1 – 5, High, Medium, Low, etc)
  • For all – impact (1 – 5, High, Medium, Low, etc)
  • Identified by
  • Action owner
  • Mitigation plan
  • Target resolution date
  • Status (Open, Closed)

Others may be added depending on project. However, the above will allow for successful management.

The actual approach to resolving Risks, Assumptions and Issues are slightly different.

Assumption Management

Assumptions are usually captured during the planning phases of the project. They are used where information is required to make an informed decision. For example an IT project may make assumptions about disc storage and work out a price for the number and size of discs based on the assumption.

However, what is important is that there is a plan to prove if an Assumption is true or false. Without this, a project may continue assuming disc usage, go into production only to find disc storage requirements are 10 times bigger than the Assumption so the system is not fit for purpose.

In some cases, it may not be possible to prove an Assumption or it may be prohibitive. In this case this is where Risk management comes into play.

Risk Management

The project manager should aim to capture all Risks that may impact a project at the start of a project. These should be assessed (usually by a group of appropriately skilled people) to gain a view on probability and impact.

The project manager must then make a decision on what Risks to worry about (usually those with High probability and or High impact). For these, the project manager (and / or project team), should capture mitigating actions. This will enable the project manager to recommend to senior management where mitigating action should be taken to insure against the Risk. This needs to be considered carefully as taken mitigating action usually costs more money and the Risk may not happen – a tricky balancing act.

Issue Management

When a Risk does happen, then it becomes an Issue – something that needs to be managed. The Issue should be closed on the Risk register and transferred to the Issue register. It is possible for an Issue appear that was not captured on the Risk register – every project manager’s nightmare “the unknown, unknown”.

A course of action needs to be developed in order to resolve the Issue. If the project manager has completed a Risk Mitigation Plan, this will be the starting point.

For Risks, Issues and Assumptions, this is an ongoing exercise for the project manager, it is not just a point in time exercise. Unfortunately, many project managers create a Risk, Assumption and Issue log and then never look at it again. A good project manager should be ensuring the registers are constantly being updated and then they should review with the project team on a regular basis.

Managing risks, issues and assumptions is a really important activity.  The project manager must make sure the appropriate attention is given to the activity.  Using good tools and templates will help the process and reduce the chance that items will be missed and / or not managed.

5 things you need on a project status report

Discussing project status reportA good project manager knows that the project status report is a great tool to communicate to senior stakeholders.  Given the benefit, it is important that the project manager maximises the impact.

You organisation may or may not have a standard format for the report.  Either way, there are 5 things that you must communicate.

RAG Status

The most widely used mechanism for reporting project status is RAG.  This stands for Red, Amber, Green, with Green being on track and Red not on track.  RAGs can be applied to the status of the overall project and the different dimensions i.e. budget, scope and schedule.

Typically the top of the report should contain a section to give the snapshot of status.  To be even more helpful, include the change since the last reporting period as this then allows the audience to understand if the project has improved, deteriorated or remained unchanged.

Executive Summary

Every report must have a form of executive summary.  This may also be termed Key Updates, Elevator Speech, etc.  The purpose is to present the key messages for the update.

A good way to refine and target the update is to think, “if you only had 30 seconds to update your sponsor, what would you say?”  Using this method should help focus your thinking to decide on the top 2 – 3 points you need to convey.

Do not try to squeeze every update for the project into the summary.  This will only serve as information overload and risks the main messages being diluted.

Remember, senior sponsors typically have limited time.  So if they only read the summary, make sure they go away with the top 2 – 3 points.


This is different to the executive summary.  This is used to provide more detail on what has been achieved since the last reporting cycle.  While it may contain more detail, keep the update concise and try to use words that convey the benefits.

The achievements should support the executive summary.

Items Missed

This is where items that should have been delivered in the period have not been delivered.  It is important to communicate these to manage expectations.  The update should include the impact and what action is being taken to address, ideally with a date it will be resolved.

Risks / Issues

This may also go under the heading challenges, barriers, etc.  The purpose is to convey what may or is impacting progress for the project.  This is important as it may be that there are circumstances outside of the projects control that need to be addressed to get the project back on track.  For example, where there is a resource dependency and senior management need to reprioritise a resource to work on the project.

It is also important to communicate the significant risks.  Senior sponsors do not like surprises.  Making sure they are aware of risks,, it means they are aware and then if they become issues, it is not a surprise.  There may even be mitigating actions that the project manager recommends to be taken.

Additional Items

The 5 items listed above will form the basis of a good project status report.  Additional information could be:

  • Details of milestones
  • Dependencies
  • Resources
  • Budget
  • Benefits

The project status report is powerful.  If you make sure that you focus on concise updates against these 5 areas, you will be able to communicate the key messages to your senior stakeholders.

Remember, less is more, especially when you need the audience to take action.  When you review your report, aim to remove any words that are not really saying anything.  This will ensure that the message is direct and to the point.

Why the project status report is a powerful tool

If you ask a number of project managers on their thoughts about project status reports, while a number will be very supportive and see the value, there will be a high number who do not!  Those who do not will probably describe status reporting as:

  • Waste of time
  • Takes focus from valuable delivery work
  • Form filling exercise

Example of project status reportsThere will be many more.  For some reason, status reporting is seen as a administrative function that is not high value that is demanded by a project management office.  For this reason, the report is often completed by a junior member of staff and more often then not is not that useful.  This only goes to reinforce the position that the report is a “form filling exercise” that needs to be done to tick a box.

However, a good project manager understands the power of a good, well written project status report.


The process of producing a status report is a great opportunity for the project manager to reflect on:

  • What has been achieved
  • What has not been completed
  • What barriers are stopping progress
  • What needs to be completed in the next period

The simple process of thinking about the project against these headings allows the project manager to take stock.  By setting aside 30 – 60 minutes each week, the project manager can pause and truly reflect on the status of the project.  This discipline is very useful when the project is busy.

The process should help the project manager identify emerging themes that may impact the project.  The earlier they are identified, the more chance that action can be taken to get the project back on track.


The project status report is a very good tool for the project manager to communicate to key stakeholders.  This is very important if the project manager does not have the opportunity to engage with all stakeholders.

As the project manager is responsible for writing the report, it means that they have the opportunity to present the key messages.  This is extremely useful for communicating the successes of the project.  Word of caution, the status report must be an accurate record.  Do not over embellish what is going well as may lead to the credibility of future reports to be questioned.

The report should be used to advise where there are challenges and what is not going well.  This should be done in a way that does not result in unhelpful re-action.  It is advisable to speak to the sponsor before the report is submitted so they are not caught unaware.

General Tips

  • When writing the report, aim to use language that can be understood even by those who are not close to the project.  Remember, you may not be there to explain points when the report is being reviewed.
  • Avoid using unnecessary words or adding unimportant updates.  The review time for a report will typically be brief so make sure all of the points are worth reading.
  • Peer review.  Get a member of the team to review the report to make sure it makes sense and is of suitable quality.  It is surprising how many mistakes are missed when you review your own report.
  • Where possible, review and agree with the sponsor before submitting.  That will allow any adjustments to be made in the message and keep the sponsor happy.

The project status report is a powerful tool and, used properly, will help the project manager.

Benefit of project template standardisation

Project standardsOver time, a project manager will typically have worked on a number of projects, probably for many different organisations.  During this time the project manager will have developed and / or gained exposure to many different ways that organisations deliver projects.  It is fair to say that there will be some instances that went very well, some that went very badly and the majority in between.

Delivering projects successfully is a challenge.  If it was not, there would be no need for project managers.  Therefore, it is in the interest of a project manager to take action to help improve the odds of succesful delivery.

This is where standardisation to the project delivery can be a great benefit.  The use of standards means that a project should be executed using tools and processes based that are designed to achieve succesful delivery.

By using standard tools and processes, it should mean that all of the project routines like planning, risk & issue management, change control, dependency management, status reporting etc are completed to the appropriate standard.  This means that the information can be captured and managed to help avert situations that will impact delivery.

In fact, just having standards greatly reduces the risk that something will be missed.  Having a set approach should mean that important project routine tasks are not missed, such as reviewing risks and issues on a regular basis.  This is important as when a project team is in the middle of delivery with a lot of activity, without established routines, there is a risk something will be missed.

Many organisations recognise the benefit of having an established approach to delivering a project.  It is for this reason that they have invested in building and training their teams on using standard tools and processes.  Having standards also helps when it comes to consolidating information from many projects so that consolidated reports can be used across and organisation.

The use of standards, especially in the form of project templates, will greatly help a project manager.  Instead of them having to design and build their own approach, they can simply follow the defined standards.  This presents a great time saving.  It also means that they can focus on the project and not the tools.

If you are a project manager starting at a new organisation or a new project manager, make sure you check to see what standards (tools and processes) are available and seek the help to use them on your project.  If there are not any, then look to re-use what has worked for you before.  If you do not have any readily available, there is always the option to buy established templates, a great time saver as opposed to developing your own.

In closing, the use of standards will greatly increase the chance of successful delivery of your project.

Don’t be a tick box project manager

project tick listThe project manager has to perform a number of duties in their role.  One of them is making sure that all the tasks and activities within the plan are completed at the appropriate time.  This is important as, if they are not completed according to plan, the project will be delayed.

However, while it is important to “check” all of the tasks on the plan, it is important that the project manager does not become tunnel visioned and, fall into the trap that just because the items are being “ticked-off” that all is well!

This opens up an important point, just because an item has been checked and closed, it may not mean that the project will deliver what is required.  I have seen project managers become very focused on showing progress that when they receive an update that a task is complete, they want it to be true.  As, if it is true they can continue to report positive progress to senior management.

Also at play is that many people write “to do” lists – I know that my notebooks are full of them.  They are a great way to collect and organise what needs to be done.  While very useful, it also helps re-inforce the “tick box” mind set.  Primarily due to the fact that many people gain huge satisfaction from physically drawing a line through or placing a tick against the items on the list.  It presents a visual cue to our brain that something has been done.  It is also good to be able to review at the end of the day and see all the items that you wanted to get done has been achieved.

Now before anyone starts jumping to the conclusion that “to do” lists and check lists are bad – of course they are not.  The point I am making is that you must ensure that the drive to “tick-off” the items does not cloud the judgement if the task has truely been completed to deliver the required outcome.  The “Outcome” is the reason for doing something – if there is no “outcome” why do it?

So, how to avoid becoming a “tick box” project manager?

The first step should be covered by reading the above – awareness.  Knowing that there is a tendancy to want items to close should result in less inclination to take an item as closed without further investigation.

This is the second step, each item put forward as closed must be tested.  In reality, project managers are generalist so do not know the content of a project in depth.  However, a project manager must develop the skills to be able to ask probing questions, review documents, etc so as to reach a level of confidence that an item has been closed.   Where verification requires expert knowledge, you can arrange for peer review by resources with the necessary skills.

To close, understanding that there is a natural desire to want to “tick-off” items should help us all to remember the need to evidence that an item is closed.




The $99 project – new project managers beware!

New Project ManagerYou made your career choice – project manager <tick>.  So being the professional you are, you invested time and probably money learning the trade, studying and passing your PMP exam.  A good feeling, I have training, showed I know what is involved by passing an exam so ready to go.

You walk into your managers office, congratulates you and then (with a twinkle in the eye), gives you your first project.  Then goes on to give you the background and says “don’t worry you have my full support”.

Your manager duly issues the e-mail welcoming you onboard and letting everyone know you are now the project manager of the “$99 project”.  You are keen, you are excited and ready to go.

You start reaching out to your stakeholders, colleagues and you soon realise that the $99 project” = mission impossible.  It is a project that has not been defined, has no support, no funding other than the token $99, no credibility and, in all honesty, you would have more chance delivering world peace.

In all seriousness, most project managers encounter the “$100 project” at some point and the trick is not to let it set back your career.

So how to avoid getting tainted?

Ideally it is to identify that the project can not be delivered before it is formally taken on.  When your manager is trying to appoint you, make sure you probe further to understand the full background, especially how many times it has been tried before and the reasons for failure.

If you can’t duck taking it on, agree an initial review period with your manager.  Offer that you will conduct a 2 week review to assess viability, etc and that you will come back with a proposal.  This means that you will have a check point that gives you an exit plan before you are seen as being responsible.

When you have completed the review, you can go back with your assessment and then a list of what is needed to progress the project.  This gives you a chance to set it up on sound footing.  For instance, you may propose the next step is funding to develop a business case or proof on concept.  This give you the opportunity to secure funding and resources to review and research properly to develop a credible plan (or conclude the project can not be delivered).

While this may not lead to the correct answer that the sponsor is looking for, it will allow for the correct level of research to allow for an informed decision.  If that is that it does not “stack-up”, then your manager has the data to push for the project to be cancelled.  This helps the organisation as no more time or money will be wasted.

There is also the scenario that your research will reveal a credible and cost vaible approach – one that would have not been found without the correct research.  This will make the sponsor and your manager happy so you will be the super star project manager.  Very good for the career.

The First $20 Million is the Hardest DVDIn case you are wondering why I chose the “$99 project” for this illustration, it is a play on the “$99 laptop” that for so many years was an impossible dream.  In fact there was a very funny film based on this, “The first $20 million is always the hardest”, cheesy but delivers the point very well on how newbies are so keen to impress they will sign-up to anything.

However, as we now have seen, the $99 laptop is close to being a reality and they are being shipped to locations in desparate need to access computers… there is hope for all projects.  Maybe someone would like to take another look at project “world peace”.



Project Management – a new chapter

project management blog new startOver the past 5 years this website has strived to provide thoughtful and insightful project management articles from leading practioner’s in their field, such as Elizabeth Harrin of A Girl’s Guide to Project Management.  Now the time has come to start a new chapter still following the ethos of providing project management articles that provide benefit and value to project management professionals of all levels.

Project management has continued to develop and mature in all areas – innovative approach, agile delivery, lean, tools and processes.  Some ideas and concepts genuinely move forward the art of project management, others are more appropriate for the class room and academic study.

Since the global recession of 2008, every organisation is looking to do more with less.  Return on investment has become a key indicator.  Not just the classic “pitch high and forget” in order to secure project funding.  Now sponsors are being held accountable for delivering the benefits within their business case to ensure the benefits are realised and the ROI achieved.

This drive to ensure that projects are delivered and benefits realised has meant that many organisations have taken the decision to build project management offices (PMO’s).  The rationale being that the PMO will provide robust governance, tools and processes to ensure that the correct projects are selected, mobilised quickly, executed with rigour and the benefits realised.

These are exciting times for change professionals but only those who are prepared to adapt to the changing environment.  Therefore, it is important for every project manager to constantly be on a journey of continuous improvement and not just see the 3 year renewal cycles of Project Development Unit’s (PDU’s) as a tick box exercise (choose training that will add and expand your skills).

So against this backdrop, this blog will provide regular updates over the coming months and years.  If you would like to contribute an article that would benefit the community, please visit the Contribute page.

Wishing you success in your project management endeavors.