Book review: Project Workflow Management

“Project management is indeed a very exciting and rewarding profession, but at the same time, it is one of the most difficult jobs, often misunderstood by project team members and management alike,” write Dan Epstein and Rich Maltzman in their book, Project Workflow Management: A Business Process Approach. I agree; it can be a challenge to get anything done as a project manager, and Epstein and Maltzman explain why:

“The project manager will never win a popularity contest, because even though he or she is not usually a personnel manager of team members, he or she nevertheless sets work deadlines, demanding status reporting and requests adherence to the project work rules and schedules. These demands – coming from someone who is not technically their supervisor – won’t necessarily win you any favours with team contributors.”

The concept behind this book is that it is a full project management workflow, covering the whole project lifecycle. The authors define ‘workflow’ as ‘a means to identify and diagram procedural steps and logic used to achieve a specific goal.’

They say that this step-by-step sequence is different from the process models in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and other project standards because it gives you the detail of how to do each step. That’s why the book is so chunky.

Running a project with the workflow

You can use the book to execute projects with very little formal project management training, but I think you’d find it easier to put the concepts here into practice with some understanding of projects. It’s very detailed and there are numerous tables, templates and diagrams.

It would help to have access to the flow diagrams while reading the process descriptions and steps, and that’s hard to do on an iPad. You could print out the diagrams and have them with you if you wanted to get this book on an e-reader.

The explanations are comprehensive and there are worked examples where necessary to help you. For instance, there’s a step-by-step worked example of cost benefit analysis. Getting into this steps you out of the process so it’s a bit of a diversion from the flow of that section but the idea behind it is to ensure that you know how to do each step.

Useful pointers for project processes

The book includes a whole chapter on estimating and has a useful checklist for requirements. There’s a good section on earned value and another good chunk about training. Another thing I particularly liked is that the authors recognise that you don’t just work on projects during a normal day in the office – and even if you do, the chances are that poor planning makes you ineffective some of the time. They write:

“Delivery team members spend around 20% of their time on phone conversations…ad hoc meetings, conversations, coffee breaks etc…The efficiency of resource utilisation depends on the project manager’s planning skills. A skilled PM may reach 90% resource utilisation at best. In other words, 10% or more of resource time is often not productive due to inefficiencies in resource utilisation.”

They also recognise ‘project management time’ as an overhead. In other words, you have to ‘do’ the project management and this takes, they say, between 10% and 20% of the total project effort, so make sure you are adding that on to your task estimates.

A downside of this book is that I found it very technical and difficult to read in parts. There are also lots of acronyms, and if you miss the explanation not all of them are obvious, so you have to go back and check earlier in the text to find out what they mean.

Should you share your plans?

The authors advise project managers not to share their project schedule with the client “to avoid clients’ attempts to micromanage the project or request reporting the completion of every scheduled task.” They go on to write:

“If you admit them into this level of project detail, they may interfere with the project management processes, even asking to remove some quality or risk related tasks in order to save their costs. The second reason is that you cannot show the client some of the project tasks, like internal project reviews and meetings or tasks related to the containment of some negative elements related to the client in the project risk assessment. If the client is aware of those meetings, you cannot stop them from sending their representative.”

I don’t agree with this advice. I don’t think there is any reason not to share the plan with the project customer. If they don’t have the maturity and project management knowledge to know what the tasks are, then it’s your job to explain it.

Of course there are discussions you have with your team that you wouldn’t have in front of them (mostly about how awkward they are being changing the requirements or how they are keen to push blame for delays on you when it’s really them causing the hold up). But you can have these discussions outside of the formal risk meetings. And surely if you are having these discussions about them it’s best to find a way to discuss it with them as well.

Overall, Project Management Workflow is a new approach to project execution. The supporting diagrams and tables make it possible for you to adopt this approach on your projects, and it would also be useful at a corporate level, especially for companies looking to formalize project management processes and methods within their teams.

It is a comprehensive resource that walks you through the processes with detailed flow diagrams and clear guidance for making your projects a success – although like all project management processes and approaches, you can ultimately decide for yourself which bits to follow to the letter and which to adapt for yourself.

Buy on Amazon.co.uk