5 Simple Reasons Why Processes Don’t Work
I bet you have plenty of project management processes, don’t you? One for risk, one for escalations, one for changes, issues, new project kick-off, closure, logging dependencies… the list goes on and on.
We couldn’t work without them. But they don’t always work.
The bottom line is this: having processes doesn’t guarantee that your project will be any better than if you didn’t have them.
That sounds a bit controversial; perhaps it is. But I’m a big believer in making sure everything is fit for purpose and processes are included in that. They have to work effectively and do what you need them to do. If they hinder you or don’t work at all then they are as good as having no processes – and sometimes the result is worse than having no processes!
The reasons why processes don’t work are actually pretty simple. Let’s look at 5 common reasons why processes fail to serve you when managing projects and what you can do about them.
1. Processes are too informal
“Oh, sometimes we do it like this, but it doesn’t really matter.”
“There’s no strict way of doing it but…”
Informal processes cause you lots of problems. Do you follow them? Do you not? Who cares if you do it either way?
Then you find out that a colleague is working in a slightly different way to you and your stakeholders are confused about who is “right” or what format they need to provide updates in.
Equally, if you aren’t following a process at all you could end up with project quality issues. An informal attitude might tumble over into a, “I didn’t think it mattered” attitude and suddenly no one remembers why you spent £100k on something as nothing was documented about who signed it off.
(This is why I organize a notebook for work and then transfer all the important decisions to a decision log.)
Fix by: Standardize, standardize, standardize. You can do this with templated processes and have different routes through the process depending on the type of project.
A large project might necessarily have different obligations than a smaller one. Everyone needs to know what is required from them so they can work to the right level of structure.
Read next: 5 golden rules for writing project documentation
2. Processes are too bureaucratic
There is a chance that processes lean too far in the other direction too. If your processes are heavily bureaucratic, with lots of winding paths and detailed steps to complete, then no one will be able to get anything through them.
The risk there is that people make up their own processes to work around the edges of the formal policy, skipping steps because they are focused on keeping the momentum going on their project. And in this situation, I would argue that’s probably the right thing to do.
There’s no point in supporting processes that add complexity for complexity’s sake.
This situation can happen when teams merge, or processes haven’t been reviewed over a long period of time. The steps that you used to do to support a particular business requirement aren’t needed anymore but no one has had the foresight to take them out. So you still do them, pointlessly and with bad grace.
Fix by: Work with the PMO to review the processes. Be explicit about issues where you see them not working and challenge the status quo.
Never be afraid to ask why you are required to do something and don’t take ‘that’s the way we do it round here’ as an answer!
3. Lack of understanding
Let’s say that you have great, fit-for-purpose processes. If your team doesn’t know how to use them then they will simply be a burden around your neck.
The people doing the process need to know why they are doing it and what purpose it serves. If they don’t realise they have to use the room booking process for sorting out meeting rooms, they will continue to circumnavigate the process and go directly to the office manager: causing problems on both sides, I expect.
People need training on processes. That could be as easy as an email explaining what screen is changing in the software tools you use or a full-on classroom course. But you shouldn’t expect people to simply know what to do.
Fix by: Train your staff. Tell them why processes are required. Show them where to find the templates. Explain how to use the process and what to do if they need more help.
4. Process risk isn’t understood
There is an element of risk in most business things, and processes are no different. If there is a risk that the process doesn’t work as expected you should be monitoring that (it’s most likely a task for your PMO) and ensuring that any subsequent issues with the process are captured and dealt with.
Process risk isn’t something we think about often because we like to believe all our processes are designed from best practices and tried-and-tested methodologies. But… then you introduce humans and complex work situations and suddenly those flow diagrams don’t look quite so robust any longer.
Process risk is things like:
- People circumventing the process
- Steps not being carried out as expected or with the results you expect
- Processes not fitting a particular type of project.
Fix by: When you implement new processes, or even as the user of an existing process, be alert for points where it might fail you. You could even include these in your project risk register.
For example, there could be a risk that the budget sign-off process takes so long that even if your project sponsor is totally on top of it, the start date is delayed, with the subsequent impact on achieving the business case benefits that would bring.
5. Poor project management
Finally, poor project management can cause your processes to fail – and this time it’s going to be caused by the project manager, not by an inherent problem in the process itself.
You shouldn’t try to apply the issue identification process to an issue that has already been resolved. You shouldn’t try to use the escalation process formally to flag a problem that doesn’t require escalating. There’s little point in assigning tasks to resources when the work has already been completed.
It will look like those processes are letting you down but really it’s because an inexperienced project manager is trying to use them in a way they weren’t designed for.
Fix by: This is all about applying processes intelligently and using them as appropriate. That means using them at the right time for the right purpose. More experience, a mentor, and substantive training will help project managers have the confidence to apply the processes correctly in the right situations.
Processes are there to support you as you manage your project. They underpin how we get work done. But they are only as good as the steps in them and the people using them.
Apply some common sense to your project management processes. Big complex projects need big, complex structures to support them with all the governance, oversight, and process that implies. Smaller projects can follow the same path with a leaner approach.
Whatever your methodology, whatever your ways of working, applying them intelligently will avoid some of the pitfalls described here and keep your processes in good working order.
Action summary
- Standardize your processes. It’s OK to have different paths through a process to suit different situations e.g. big and small projects.
- Review your current processes and look for areas where they aren’t working. Address these as a team to make improvements.
- Train the team in how to use processes effectively – and remember to cover the ‘why’ of the process as well.
- Document process risk on your risk log.
- Build confidence in using processes so you feel comfortable tailoring where necessary.
An older version of this article first appeared on the 2080 blog in 2017.
Pin for later reading
