Some days ago, I had an interesting chat with a client. He told me that the project managers in his company would deviate from the defined processes, over and over again, because the processes would not work well. But what is the best solution, follow the processes come what may or deviate where necessary? And who would decide this?
Projectina has her own point of view about it. Let’s see if Gurufix agrees…
Processes, procedures and systems do not take the nasty daily hiccups into account. It’s in the nature of things. But, should the project manager deviate from them for the sake of a quick success or not? Who’s right, the experienced Gurufix or Projectina who would love to quickly get the task done before the weekend and prefers to do lazy Dontsellus’ job?
Do I need systems, processes and procedures at all?
The question seams legitimate. After all, I know how to manage a project. And as every project is different, it makes sense to adapt flexibly, isn’t it?
The answer to this is quite simple. Once, systems and processes are defined, they facilitate a project manager’s job enormously. And for the company, they assure an always equal outcome, no matter who is working on it and how he feels at that very moment.
Imagine, McDonald’s had no systems for roasting Hamburger meat. Each time you order a hamburger it would look and taste different. Sometimes, you would get one with cheese, sometimes without, sometimes the meat would be well-done, and sometimes blue. Do you think, they would be as successful as they are? Unlikely.
Sure, a project is something different than roasting a hamburger. Anyhow, turn it over in your mind. For one project, a risk analysis has been made, for the other project not. For one project, the management wants to see the overall budget only, for the other project the management asks for detailed one-on-one budgets. Us poor project managers would spend our time reinventing the wheel again and again and doing things in new and different ways for each project. The project results would by no means be predictable.
The 5 excuses why we deviate from systems… and why we should not do it
It is quite obvious in a production. The operations always run the same way. Everybody accepts this and keeps with the rules. Why is it that it’s so difficult for us brain and creativity workers? Here are the 5 most frequent excuses why we do not stick with the systems.
1.) Each project is different
Clear enough, each project is different. Different team, different project manager, different customer, different requirements and so on and so forth.
But let’s be honest, the subtasks inside the project and all the internal running stuff, this is quite the same, or could be quite the same. Even the composition of the project team is quite similar. Different people, sure, but you always need to cover the same fields of responsibility.
So, to look at things in the bright working light, there are more similarities than differences.
2.) Team member X is incompetent, reluctant, … I rather do it myself
Yes, we all know someone like this. And it’s fabulous how often we get someone like this in our project team, isn’t it? Sure, if I had only X types (Theory X and Theory Y) in my team, I could be tempted to rather do things myself so that at least they get done.
This is not only spineless and lazy but it is dangerous too.
Why spineless? You as project manager also have a role as a leader. So, you have a reluctant team member? And just to avoid conflicts, you cave in and do the job for him? What does this say about you?
Why lazy? Yeah, interesting question as you are about doing the work for him… Well, if there’s an incompetent team member, this means he does not have the competences needed to do the job right. What does that say about you? Answer: You have not done your job to develop and train him so that he can do the job right.
Why dangerous? First, you as a project manager, you have your tasks. If you spend time doing other people’s tasks, there’s a risk that you neglect your tasks. Second, you might not be qualified enough for those tasks and therefore you can’t guarantee the quality of the outcome needed for the project’s success.
I always got on well and therefore stick to these immortal words: “… You cannot help people permanently by doing for them, what they could and should do for themselves.” (erroneously attributed to Abraham Lincoln, but actually by William J. H. Boetcker)
3.) The system does not match with my individual working style
Ok, you like doing things different. Believe me, I understand. For example, the filing system for project documents as it is defined in the processes, that thing just makes no sense to you. I know what you mean. 😉
See, me too, those things that’s just not me. But how would my successor or any other team member find any document if I would file them after my fancy?
Another example: I prefer driving on the right side of the road. That’s the same when I’m in England. Driving on the left, this goes so across the grain for me, I don’t feel comfortable with it. But would it be a good idea to drive on the right side even in England just because it would feel better?
So, what can I tell you. You better get used to it. Because, when everyone, you too!, works according to the established system, a great deal of errors and problems will be avoided. Just imagine, you must replace a sick colleague on short call. If he is one who sticks to the defined filing system, you will easily find all documents you need. That’s worth the effort, don’t you think?
4.) After careful reflection, I’ve made up my own system which is much better than the standard system
I plead guilty. Yes, this is my preferred excuse. I’m an efficiency freak, always pursuing the ideal proceeding. And I tend to implement it immediately once I think I’ve found it. At Cactus Competence, this is not a problem, as I am the master of the systems and everything is at my command. With one restriction: I need to convince my wife and partner in business. 😉
In a large organisation, such an approach would be problematic, because as a result nobody would know how projects actually run.
Only when you work with system, you can optimise
I would even go further and say: When you have a system, only then you will have enough data and repeats so that you can find ways to optimise your proceeding.
So, if I want to improve and make the project’s success predictable, then I need data. Measurable and comparable data, I only get from procedures that always run the same way.
And only when I can measure and compare data, I can ask the question, what needs to be modified to make process XYZ more accurate, faster or more reliable. Therefore, it makes sense to work with a systems approach. To make the performance measurable and comparable and to optimise the system.
In the end, this benefits all, you too. Because, you can benefit from the ideas of your colleagues this way.
What can I do when the system just does not work?
Excellent question. Let’s imagine, you’re working for a company which project management systems have not been updated for years. That’s why every project manager has developed his own workaround. The systems only exist on paper as kind of parallel documentation for audits. But the reality is different.
How could that happen at all? That’s all simple. Because of the uncontrolled going round the processes, nobody ever realised that they do not work any more. And those who realised were perhaps not in the position or too busy or too lazy to attack the topic.
And, the process performance data and audits were not able to detect the problem, because on the surface, everything looked all right.
The result? Some day in the near of far future, there will be a big bang. Depending on how big the bang, the entire company can fall apart, inclusive your job! Not a nice scenario, isn’t it?
But there is a way out!
Process optimisation via change request
This might sound a bit strange at first sight. Change requests, I only do when the product needs to be modified. Thought that too in the past, but this is not true.
In a project, a change request is also done when, for example, a team member resigns, or unplanned equipment is needed, or the team discovers an error or suggests an optimisation. So, one reason for a change request could also be that you as project manager discover a possibility to optimise processes in the project or when a process fails.
Then, the change request goes his normal way and will be examined by all concerned persons. This usually also involves the project management office (PMO) which takes care of all processes round the project management.
Now, 2 things can happen. Either, the change request is accepted. Then, you can use your optimised process and, if the same problem occurs in different projects, the PMO will implement the process change. Or, the change request is refused. Then, at least, you have documented that there is a problem. You will continue working according to the non-working processes and the results are what they are.
But, and this is very important for you and for the organisation, you have documented the problem in the project. This protects you and in a later analysis of the project, the problem can be re-assessed and serve as suggestion for improvement.
Now its your turn!
How is it going in your project? Do you really use the systems and processes as they are defined in you company? And if not, how did you handle the deviations up to now?
Observe yourself. Do you stick with given processes, or do you rather deviate? If you deviate, why? Have an honest look at it, have you been successful with your proceeding? Or was it more trouble in the end than the short advantage you had occasionally?
TASK FOR YOU:
Identify 3 deviations and improvements in your project and document them in the form of change requests. Please, report to me how things went on. I’m quite sure you will be positively surprised.