Issue Management

If you think that your project has no issues, then you should be very worried, its not so much that you haven’t got issues, its that you don’t know what they are.

It is not showing weakness to get your project issues out in the open, its more a case of sticking your head in the sand until they cause you problems, and they almost certainly will.

So on to the topic in hand, Issue Management, well what is it?

Issue Management is the process of getting all of your know issues out in the open, documented, thought about and given to owners to either mitigate them or resolve them. This isn’t all on you, although as the project manager you want to own the risk register.

The risk register can be a simple excel spreadsheet with a list of all know issues, you can start by getting the risks out of your head into the spreadsheet and then draft in other project members to brainstorm the rest.

Once you have the issues down in the spreadsheet, you can work through them identifying in a similar way to a risk register which are the big ones with the most impact.

Your next task is to identify owners for each of the issues, it is the owners responsibility to either resolve the issue or mitigate its potential effect.

As the owner of the issues register, it is your responsibility to periodically call the issue owners to account and confirm the issue status. Once an issue is closed down, or resolved, it is marked as such, do not delete it as you will want the history to remain available for the end of project wash up or along the way if anyone raises the same issue.

If your project meetings are often enough, then the issues register can become an agenda item, not only will it remind the attendees to check on their issues, it will enable you to maintain an accurate status of the issues and their history. Depending on the type of project you are running, you may need to have an internal and external issue register as internal issues may not be appropriate for an external audience.

Jason Pope

Risk Management

Like it or not, every project has risks, some will be big some will be small, some will have catastrophic results others nobody will really notice. 

Without a risk management strategy you will be just winging it. Without being informed you may be concentrating on preventing the wrong risks. But why can’t you prevent all risks I hear you say, unfortunately in the real world there are so many risks that you are unlikely to account for all of them. 

So what do you do with them and how do you work out which are bad and which are really bad?

The first step, and this is crucial, is to actually get the risks down in a formal document, just the act of specifically thinking about the risks will greatly improve your chances of discovering the big ones and help you also think about how to prevent them from occurring (mitigating them). 

List all of the risks that you can think of related to the project no matter how big or small or how likely they are to occur. Just get them down in any order. 

Once you have them all down, against each one make a note of the effect of the risk actually happening.

Now it’s all about numbers, score each of the risks from 1-5 where 1 is an unlikely to happen and 5 is a highly likely to happen. Now, against each risk score the effect of the risk happening where 1 is limited impact and 5 is catastrophic impact. You may wish to use a matrix such as the one below. 

Risk Matrix

Once you have all of the scores it’s a simple task of adding the numbers together.

A risk that is unlikely to happen and has a low impact is the risk with the least overall score. A risk that is likely to happen and has a large impact has the greatest score. 

The higher the risk score the more effort or resources need to be used to mitigate those risks. The lower the risk score the less effort or resources are required to be used to mitigate those risks. 

Without employing this type of risk discovery and mitigation strategy it would be easy to either ignore potential risks or to use resources or time on mitigating the wrong risks. At best this results in wasted resources and time, worst case a catastrophic risk event could happen having a severe impact on the project.

This type of risk scoring is suitable for a large cross section of projects, it is simplistic but effective. Risk management is a very large subject all of its own, with lots of statistical tools and process, if you do nothing else but the simple risk matrix and have a formal risk register, then you are well on the way to controlling and mitigating the risks of your project.

Jason Pope

Managing the Matrix

Your organisation operates under a Matrix Management way of working, this is great if you request people for your team from the resource pools, but what if you are the one managing the people that are seconded, what should you be looking out for if you are Managing the Matrix.

First and foremost, your team, they need you more than ever if they are seconded elsewhere. You need to monitor how they are being treated, how they are being worked and check that they are getting everything they need.

You do not want any member of your team being over worked because the person they have been seconded to does not care or know how to manage real people. Best case they will under perform which could reflect on you, worst case they could end up burnt out or leave the business.

Be there for them if they need to vent over different ways of working, tight project timescales or if they are confused by how they are being asked to work. Just because they are not working on one of your projects does not mean that you are not responsible for their well being. At the first indication of an issue, start digging into it, it may be nothing, but you want to get all over it before it is a real issue.

Jason Pope

What is Matrix Management

Matrix Management is quite common where diverse teams are required to make projects work.

As the Project Manager you will often have to pull together the required people into a team to be able to deliver the project. This could and is quite likely to be quite a diverse team.

If the project were to be ongoing for a number of years and you needed all of the team members 100% of the time, then you could probably justify employing a full time team, if this is not the case, then you could end up being in a matrix managed situation.

If you are pulling together a temporary team then it is unlikely that you will be given line management responsibility for those members, so even though you will probably be tasking them (managing) for the duration of the project, you will not have full line management responsibility for them, this is Matrix Management.

Scope Creep the budget killer

Do not fall foul of scope creep; So you have your project under way, everything is going nicely, then at the next meeting with the customer that drop in a small addition that they would like to add in.

No problem you say, so you add it into the plan, its only a small thing so shouldn’t be a drama. The next meeting the customer requests another slightly larger item to be added.

Before you know where you are the project is at risk of over run and over budget, why is it going over your customer says, the same question comes from other stake holders.

The reason is scope creep!

When you agreed the project scope (you did that didn’t you), you set out what was and wasn’t included in the project, this then dictated the required resources and the time it would take. By agreeing to the additional scope, the project scope has increased.

Often commercially you will be happy to take the additional scope as a value added part of the project, this is absolutely fine, but at this point you will want to add it to the scope document as and addition.

In adding it to the scope document, you are formalising it, and keeping a record for later in the project. You may need to explain to your customer or stakeholder why the project has over run. As you add the additional scope to the document, you may decide that either on its own or with the other items it is a chargeable addition, which will help with the bottom line.

Either of these scenarios are fine, however if you didn’t agree the scope of the project prior to starting then you could quite easily start falling foul of scope creep, the additional costs will mount and could in the worst case push the project into a negative position. Always agree the scope of the project before you start it.

Jason Pope

The Scope of Work (SOW)

Whether you are a seasoned project manager or an accidental project manager, one of the first things that you need to tie down on taking over a project is the scope of work (SOW).

Without knowing the scope of work, how can you know if you are achieving it?

Another very good reason to get the scope of work tied down straight away is a thing call scope creep, more of that later, but needless to say it can and will kill your budget.

The Association of Project Managers’ definition is; “Scope management is the process whereby outputs, outcomes and benefits are identified, defined and controlled.”

So, put simply, the scope of work is what is included in the project to be completed. Now initially you may think that this is obvious, however your view of whats included may be wildly different to that of the project sponsor or stakeholder. If you get this wrong then your project will more than likely over run in either time or money or both.

The scope of work should be a formal document, it should be agreed at the outset with the project sponsor/stakeholder/customer.

Depending on the complexity of the project this could be a multi page in depth document, or a simple one page word document. It may take several iterations of the project scope of work before both you and the project sponsor agree.

As the project progresses there may be a requirement to change the scope, this is fine and often expected, however document these changes after agreeing them with your project sponsor, make sure they are aware of the impact on time money, or project outcome. What they see as a simple feature add may have a massive impact on completion date that they are not aware of.

Always Always Always, have a Scope of Work for any project, without it you have no idea how you are progressing, whether you are achieving what your project sponsor requires, or if you are blowing your budget.

Jason Pope