The Money Files

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.

3. Checklists

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.

4. Cross-footing

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:

1. Task dependencies that shouldn’t be there or should be a different type.
2. Tasks with inflexible date constraints that they shouldn’t have.
3. Manually scheduled tasks that should instead be auto-scheduled.
4. Work or duration values that see too low or too high.
5. Work packages/tasks without assigned resources.
6. Summary tasks with assigned resources.
7. Overallocated resources.
8. Resource calendars that don’t represent people’s actual availability.

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.

At Synergy, the annual UK PMI project management event in London which was held earlier this month, Mark Langley, PMI President and CEO, spoke about what he sees as the future development of the project management role.

He started by setting the scene for the evolution of projects in the workplace: 88% of organisations think that strategy implementation is important and yet only 62% of projects meet their original business goals. This is 10% less than 5 years ago so businesses are seeing less success when it comes to implementing strategy.

“Value for money, doing more with less – that’s what organisations are dealing with,” he said, “but it is also about strategy.” Working with organisational leaders is an area where PMI are very active as they try to push the agenda that strategic delivery is about projects, programmes and portfolios, which is a link that many businesses seem to have missed.

The challenge, he said, was that when you look round the boardroom table there isn’t anyone accountable for strategy implementation. It’s usually dispersed. “They don’t connect strategy with projects and programmes and too often connect it with something tactical.”

Why don’t executives get it?

“Language influences behaviour,” Mark said. “We define projects in technical terms – budget, scope, performance indices. This sounds great but to the executive – they don’t understand anything you just said.” The board, he explained, talks a different language. “We have to change that language when we go up to organisational leaders when they’re deciding what to invest in project and programme management.”

If we don’t invest in projects and make ourselves understood, we put more resources at risk. A high performing organisation (in project management terms) risks 14 times less money than other organisations, simply through being better at implementing strategic and tactical projects.

So where is project management going?

Mark believes that there will be a role of Project Executive at some point, although I imagine some companies have this now. It will be a board level position responsible for strategy implementation through projects and programmes. The problem is that we don’t have the people with the right skills to fill these roles.

“Technical skills are no longer enough,” he said. “They are the easy to teach but hard to find – it’s a career path issue; a university issue. People don’t come out of university with the technical project management skills that are necessary.”

So, we have two issues: a lack of pre-trained project managers with technical skills and a lack of people who could step up and take board level roles as project executives. Businesses, Mark said, do realise that they need to invest in project management. They recognise that they’re developing project leaders but they don’t recognise that they’re developing business leaders, he explained. The competences you need to be a good project leader are the same as those for being a good C-suite executive in any position: financial acumen, leadership, communication skills and so on.

Despite these challenges, Mark was clear that where project management should be going is to the boardroom. “Strategy development and strategy implementation are part of the same whole and that’s what organisations are starting to realise,” he said. Businesses are moving from having project managers to project leaders and eventually to project executives. Project professionals are moving out of projects into business areas and executive positions.

I think this shift is already starting to happen – it will be interesting to see how far we get in 10 years and whether the statistics for the importance of strategy implementation remain high, only to be matched by an organisation’s ability to deliver to that strategy.

Project status reports include financial information, but also a whole host of other things related to the project’s progress. But are yours actually getting read? And do your stakeholders make decisions or act on the information in there?

This is a common problem for project managers, that and the fact that they are time-consuming and a bit boring to produce anyway. My new online course and ebook, Better Project Status Reports, aims to change all that. It even includes an option where I’ll review one of your status reports and help you make it better.

You can find out more about it here.

And it’s got a money back guarantee if you change your mind at any point or decide it isn’t for you.

Drop me a line if you need more information or have any questions!