7 Books to Improve Your Projects
Looking for something to read over the summer? I’ve picked six of my top choices from this blog and one bonus review so that you can choose the right book to improve your projects over the summer holidays.
Most of them are available as ebooks so you don’t need to worry about weighing your suitcase down!
Roger H. Davies and Adam J. Davies
This book will help you answer questions from the executive group about how projects are adding value to the bottom line. They define value as ‘outcomes minus inputs’ so it’s a broad-ranging approach to working out how you are contributing, and applicable whatever ‘value’ means to you and your stakeholders.
It’s not an easy read but there are plenty of anecdotes, tables and graphs that explain the core concepts and help you get the most out of every project and programme that you do.
Business Case Essentials: A Guide to Structure and Content
Marty J. Schmidt
This is another of my favourites (I know, I have a lot!) because it is so practical. If you are preparing a project business case for the first time then this will really help you get your ideas clear and your figures in order.
Math for Grown-Ups
I read this a long time ago but it’s still one of my all-time favourite books. I did OK at Maths (as we call it over here) at school but only because I really worked at it. It never came naturally to me.
As project managers we need to be confident dealing with numbers because they are everywhere: estimates, schedule variances, earned value, the budget, risk assessments – lots of project management techniques involve processing data and crunching it until the numbers look right. This book will help build your confidence and learn what ‘looks right’ and how to handle things if they don’t.
Tame, Messy and Wicked Risk Leadership
Hancock explains that the equation risk = likelihood x consequence only works when the risk is as a result of a knowledge gap and you can easily plug it. That isn’t the case in real life, where most risks are complex and you can’t easily control exactly what the outcome will be, even if you work meticulously through your risk management plan.
If you work on large or complex projects this will help you take risk management to the next level.
Make Every Second Count:Time Management Tips and Techniques for More Success with Less Stress
Robert R. Bly
Struggling to fit everything in to your working day? The strategies in here will help you get a grip on the time available and deal with your To Do list in a more productive way.
Essentially, he asks: “Do you want to be productive?” If you do, then get on and do the work. As a professional project manager you might not find any brand new tools in here, but you will get a dose of motivation to not complain that you can’t get anything done when in reality you surf the internet for a few hours a day.
Get-It-Done Guy’s 9 Steps to Work Less and Do More
This is another great book about time management (and if I had to choose between the previous book and this one, I’d go for this one although they both have their merits). In fact, I still get the email updates I subscribed to when I first read this book, and I unsubscribe from a lot of things.
I like the style of this book so if you are looking for something that isn’t dry reading and that still offers you practical tips for eking out a few more hours in the day, this is it.
If I remember rightly, there might even be zombies.
The Power of Project Leadership
Finally, here’s a book about soft skills that is not at all soft in nature. This leadership primer from Susanne Madsen will have you reaching for a notebook and pen to make copious lists about what you can be doing differently to drive success on your projects.
I think many guides about leadership talk about it in an abstract way. This is a concrete look at what ‘doing leadership’ actually means, with exercises and tools to help you on the way – things you can implement tomorrow, if you wanted.
What will you be packing or reading over the summer? Let us know in the comments.
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 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?