7 Ways to mitigate risk
In his book, Project Management for Musicians Jonathan Feist talks about several ways to mitigate risk, and they aren’t the ‘avoid, mitigate, reduce, transfer’ approaches that you are used to. Those are good, but they are approaches, they aren’t actual measures that you can take to mitigate a risk. Here are the 7 ways that Feist suggests you can reduce the likelihood that something will become a project issue.
1. Good project management
Yep, following good project management principles is top of the list. Of course, having a lovely Gantt chart and an up-to-date risk register won’t guarantee project success but it does give you the best chance of putting in place plans to mitigate that risk.
Make sure your risk management processes are up to scratch and that you are able to easily follow through on mitigation actions. Good project management also helps manage against risks of going over budget or missing milestones, because you’ll naturally be doing the things to stop these becoming a massive problem.
2. Written agreements
While you always have to factor in how someone else will interpret your written communications, putting things in writing can limit misunderstandings. It also gives you a sense of formality when it comes to contracts and agreements. Getting it all down on paper increases the chance that nothing is being missed.
I love checklists and I use them all the time. As Feist says, “Checklists help you remember important details: procedures, gear items, points for conversations, people who need certain information, and more. Checklists are among the most effective tools used to reduce risk.” I have recently written a peer review checklist for my team – one of the many ways you can use checklists on a project to look at potential areas of concern and do something about them.
This means calculating data in several directions to confirm that it’s correct. You add rows as well as columns on your spreadsheet, or check the data in a dashboard as well as a tabular report. Find different ways to double-check your maths or working, even if this is as simple as having someone else check for you.
5. Empowering competent people
If something does go wrong, you want your project team to be able to act appropriately and make decisions quickly, not sit around wringing their hands until you come in to the office to sort it all out. If you have competent people on your project team (and I hope you do) instil a culture where they can make their own decisions. Set levels to their decision-making power as appropriate so that they aren’t deciding to spending another million dollars on the project without anyone else approving it, but give them the freedom they need to do the right thing.
Feist says that the higher the risk, the more you want to make sure that if you are delegating tasks they go to someone who is a safe pair of hands. This isn’t the time to be delegating work to a junior colleague as a ‘learning opportunity’!
6. Developing emergency plans
Having a Plan B is important, and a traditional risk management technique that you are probably familiar with. Sometimes just having a back up plan is enough to make sure that the risk doesn’t happen. However, in case you do need another approach to dealing with a problem, it is useful to have already thought through what you will need to do in the emergency. Get everyone involved so that they can swing into action if and when they are required.
7. Written instructions
Like checklists, these are a great help if you need to distribute detailed instructions or have tasks that need to be done over and over again. Written instructions can also help clarify expectations. For example, on an IT project with a testing element, written instructions for the testers will help get standardised results and ensure consistency across several testers.
Have you used any of these methods on your projects? Let us know in the comments.
In this book, Bonnie Biafore aims to share the basics of project management and how to achieve what you want to do in Microsoft Project 2013. That’s quite an ask for one book. Part 1 is a primer on project management and I was surprised that there was so much about this including project selection. It’s written as if it is aimed at a complete beginner – at least, the early bits are; the book gets technical pretty quickly – and there are nice boxes called ‘reality check’ scattered throughout. They tell it how it really is, like this one (which you probably can’t read) titled ‘When Stakeholders Aren’t Supportive’.
Chartering the project
As part of the ‘how to do project management’ stuff, Biafore describes a project charter as a press release. This appeals to me as someone who writes press releases and I'd not thought about it like this before. She writes:
The project manager needs some publicity, too. Your authority comes from your project and its sponsor, not your position in the organisation, so people need to know how far your authority goes. The project charter is like a project's press release – it announces the project itself, as well as your responsibilities and authority as its manager.
There’s lots of practical advice like this, including the handy tip of not getting the most senior manager to send out the charter unless they actually know something about the project. You need authority, but you also need credibility, so choose someone who can give that to you, not any old senior manager in a suit.
"Like the pop-fly ball that drops to the ground as the third baseman and shortstop stare at each other, project work can fall between the cracks," she writes, whatever that means.
Getting technical: MS Project 2013
It's not until Part 2 that the book starts talking about MS Project. The biggest news since the product’s last release is that Project is now part of the Office 365 suite and there are easier to digest reports (which frankly wouldn’t be hard). In fact, there's a lot on reports which leads me to believe that getting them to look how you want could be tricky.
The book only covers the Standard and Professional editions, not Project Server. Some of the 365 suite features are covered but that software is evolving and the book is likely to get out of date quickly (and Biafore acknowledges that).
There are usability tips like collapsing the ribbon so you can see more of your plan on the screen and keyboard shortcuts. Biafore uses an example to create a basic project and then goes on to use another example to create a 'proper' schedule in a lot more detail.
She also includes tips on using other Microsoft products alongside Project, such as how to create a RACI matrix in Excel and importing resource names from your Outlook contacts.
The book is full of tips like how to create a resource and assign it to tasks at the same time, which are all aimed at getting you operational faster. I like the idea of downloadable worksheets for things like capital budget planning from the book's website and also links to MS templates online, which this book provides. They make the book more useful (and give it a longer shelf life) and the added resources will help you get your project on track more quickly. Having said that, I haven't downloaded any to try them out.
Check your schedule
There’s a lot about how calendars control resource and task scheduling with plenty of detail and screenshots about how to set up the correct variations of working time for your project.
As well as detailed walkthroughs and how to information, there is also practical advice for making the best possible schedule. For example, Biafore says you should be on the look out for these 8 things as you refine your schedule:
You can do some really advanced stuff, like setting work contours within an individual task to reflect how work is actually done – after all, resources don't work at the same pace for the entire duration of a task, especially if it lasts over several days. You could get really whizzy with your resource management using the advice in this book, but many of the features described will be far too much detail for the average project. While it's good to know what Project can do, it would be useful to have some sort of signpost in the book to say 'you can do without this feature if your project environment is not that mature or is relatively straightforward’. This would help new project managers work out which features they should use (like dependencies and baselines) and which ones they can leave and learn about another day (like creating an Excel form to display task information from Project and use it to get task updates from team members).
At over 800 pages the book covers a lot of ground. Much of that is screenshots, which are good and helpful. What surprised me was the breadth of the book, which covers everything from ‘what is a project’ to crunching some serious project calculations using data cubes. I don’t think you could read this knowing nothing about project management and turn into an expert by page 800, but if you need a detailed knowledge of MS Project 2013 then you certainly will get it from this informative and practical book.
When do you really know the cost of a project?
When do you really know how much a project will cost? At the beginning, when you work out the business case? During the project start up phase, where you prepare your budget and establish the processes to track spending? While you are using Earned Value Management and can forecast forward predicted spend? After you have spent your contingency budget? When you do the close out report?
There are so many moments where you can calculate your project’s cost. Michael Cavanagh, in his book Second Order Project Management (Gower, 2012), argues that none of the points I have mentioned are right.
He believes that you don’t find out how much your project is going to cost until after the project is complete – a long time after.
“Although it has been said often that the only time you know the cost and duration of a project is when it has been delivered, in truth, you don’t,” he writes. “Post-delivery costs including fault correction, maintenance, support and disposal are all subject to the vagaries of implementation in the real world and should be addressed and included in the estimation process.”
In other words, you’ll never know during the project implementation what the overall cost of your project will be. This is perhaps less of a problem for the project manager. I think you can justifiably say that we are only responsible for managing the budget up until the point the project is closed. That’s what we plan for and budget for, and manage towards. Any costs that are incurred after this are not part of the project and therefore Not Our Problem. Project managers manage project costs, and as soon as it stops being a project cost it is hard to consider it our responsibility.
However, this is a problem for the contracting process. You can’t have a project that enters into a contract where the contract is only fit for the project stage. Unless your contract is with a vendor who will only be around during the project implementation, like a hired-help contractor. If you are buying software or a service, or equipment, you want the contract to include maintenance and support. Those are after-the-project costs.
So while you might not know how much your project will cost overall, you can do something about helping the operational team who come after you to manage their costs. Get them involved in the contracting. Ask them how they manage ongoing costs and how you should be factoring this in. What is the lifespan of the product or equipment you are buying? What decommissioning costs should you factor in? Ideally get the project sponsor or the operational team representative to represent themselves during the contract discussions. You’ll get a better result, even if it does mean sitting in the room with lawyers for several days.
Do operational teams get involved with preparing the cost predictions for projects in your company? And when do you think the responsibility of the project manager ends when it comes to managing the budget?
Overcoming Imposter Syndrome: a new ebook
Imposter Syndrome is not a medical condition. It is a convenient term for the feeling you have when you believe that you do not really know what you are doing. You attend a meeting where the discussion goes over your head and you suddenly feel like an idiot. You believe that you are in completely the wrong job and the wrong company and you are in no way worthy of holding your current position. Surely it is only a matter of time before someone notices that you are not up to the job and fires you?
In reality, lots of people feel that they don't measure up. I’ve spoken to men and women who have said they occasionally (or regularly) feel like a fraud at work. At one conference I spoke at earlier this year, when I asked if anyone had ever felt like they didn’t really know what they were doing in their job, nearly every hand in the room went up. Lots of people feel like this, but we don’t talk about it much. Why is that?
When you take on something new – a new project, a new responsibility – you might be surrounded with people who are subject matter experts or who have been in a similar role as yours for years. It feels as if they know everything, and you don't know anything at all. Who wants to confess that they don’t feel they fit in when everyone around you looks like they have always belonged here?
That's how Imposter Syndrome manifests itself: it undermines your self-confidence. It can hit anyone, at any time. And the truth is that nearly everyone feels like this at some point – some people are just better at hiding it than others!
Ring any bells? If it does, my new ebook could help. Overcoming Imposter Syndrome: Ten Strategies to Stop Feeling Like a Fraud at Workdiscusses how you can feel more confident at work. It explains what Imposter Syndrome is, why we feel like we aren’t measuring up, and shares practical strategies that have been proven to work addressing the feelings of Imposter Syndrome.
You can get your copy at www.OvercomingImposterSyndrome.com or on Amazon Kindle. May 2012 be the year that you feel better about your abilities at work!
Book review: Value Management: Translating Aspirations into Performance
Value Management: Translating Aspirations into Performance is a new book by Roger H. Davies and Adam J. Davies (Gower, 2011). It’s heavy going, but if you are into getting the best value out of the change programmes you are delivering, then it makes useful reading.
There is a fair amount of theory, but there are techniques in here that you can apply to your programmes straight away. I’d say that it is aimed at people in a pure programme management, portfolio office or senior executive role, as there is not much here that project managers will be able to put into practice without senior support.
The authors define value as:
Or, to describe it less financially:
I would argue that value means different things to different people, but I understand that you need a common ground on which to base the rest of the book.
Asking the right questions
The book starts with a really nice feature that I’ve never seen before: executive questions. Here’s an example:
Q: How does Value Management address the challenge of delivering greater value from change programmes?
A: Value Management provides the means to deliver more benefit for less cost and risk. Value Management targets, times and aligns initiatives to maximise overall value. This is achieved by linking programmes explicitly to attributable benefits. This requires precise quantification of cause and effect relationships between programme deliverables, the drivers of business performance and consequential stakeholder benefits.
Reference: See Chapter 7 (Programming Value) and Chapter 8 (Aligning Value)
This is a neat way of explaining to people picking up the book the kind of questions that will be answered by reading it, and forms a kind of annotated table of contents so you can flick to the section that most interests you first.
Is it a good read?
Value Management is not an easy read, but perhaps I’m just not in a role where I can act effectively on the information in here. There is also a good glossary and lots and lots of graphs, figures and tables, so the authors make it as easy as possible to understand the concepts discussed. They also draw on real life examples and their own anecdotes, including examples from the movies, so they have tried to make the theory as accessible as possible.
One of the authors was obviously very taken with neuro-linguistic programming (NLP) and there are a number of references to how powerful this can be. The authors write: “The ability most relelvant to Value Management is to produce radical shifts in performance by re-programming limiting perceptions and ... enable clients to release latent potential through change.” They call this a value breakthrough, but this was one of the weaker points of the book for me. I’m sure you could achieve similar results with cultural change without having to ‘NLP’ your entire organisation.
If you are looking to drive savings and ensure that your change programmes and portfolio of projects delivers the best possible value for your company – and you work in an organisation with a high level of maturity when it comes to PMO practices and project thinking – then you could get a lot from this book. If your company doesn’t have a mature approach to programme management, you could struggle to get any of this implemented, but at least understanding the concepts will help you assess which are likely to be the best programmes for your business, and how to get the last drop of value out of them.