Peter Taylor (Rugby) is the head of a Project Management Office for Siemens PLM Software, a company specialising in Product Lifecycle Management. Despite his title of ‘The Lazy Project Manager’ Peter Taylor is in fact a dynamic and commercially astute professional who has achieved notable success in project management. He is an accomplished communicator and leader and is the author of ‘The Lazy Project Manager’.
Josh: Thank you so much for sharing your background and experience with the pmStudent community Peter! How did you get your start in Project Management?
Peter: Like many project managers of my generation I suspect, by accident. I worked on a team implementing an MRP system and then became a manufacturing consultant in a software house. By means of not messing up any project I worked on I eventually became a ?project manager?. It was actually 5 years after I had that title that I ever went on a PM training course and 10 years before I took any form of certification. I am pleased these days that we have a generation of business managers coming through that are trained in project management as a core skill.
Josh: Who do you look up to and have learned a lot from in relation to project management?
Peter: There have been many people I have learned from in my years but I would say the best learning experiences have come from some of the toughest projects I have worked on and from the openness of the project team members I have worked with. These days I always advocate a retrospective at the end of the project as this allows everyone, but particularly you the project manager, to learn so much more about what occurred during the project. The project close reports has all the ?hard? facts ? delivery versus original scope plus changes ? but the retrospective open up the understanding of the ?soft? facts. Norman L Kerth?s book on retrospectives is a great read.
Josh: How do you stay focussed on the MACRO project goals, and not get drawn into the MICRO?
Peter:? It is all about discipline, once you understand the consequences of being dragged in to the detail then you can appreciate the importance of staying up at the macro level on a project. Using an extract from my website and book ? The Lazy Project Manager ? www.thelazyprojectmanager.com ? may best demonstrate what I mean:
[PT] The Pareto principle (also known as the 80/20 rule) states that for many phenomena 80% of consequences stem from 20% of the causes. The idea has rule-of-thumb application in many places, but it’s also commonly misused, for example, it is a misuse to state that a solution to a problem ?fits the 80-20 rule? just because it fits 80% of the cases; it must be implied that this solution requires only 20% of the resources needed to solve all cases.
The principle was in fact suggested by management thinker Joseph M. Juran and it was named after the Italian economist Vilfredo Pareto, who observed that 80% of property in Italy was owned by 20% of the Italian population. The assumption is that most of the results in any situation are determined by a small number of causes.
So ?20% of clients may be responsible for 80% of sales volume?. This can be evaluated and is likely to be roughly right, and can be helpful in future decision making. The Pareto Principle also applies to a variety of more mundane matters: one might guess approximately that we wear our 20% most favoured clothes about 80% of the time, perhaps we spend 80% of the time with 20% of our acquaintances and so on.
The Pareto Principle or 80/20 rule can and should be used by every smart but lazy person in their daily life. The value of the Pareto Principle for a project manager is that it reminds you to focus on the 20 percent that matters.
Woody Allen once said ?80% of success is showing up?, I?m not so sure about that, I have seen projects where there was a physical project manager around but you would never have believed that looking at the project progress, or lack of progress.
No, better I believe to appreciate that of the things you do during your day, only 20 percent really matter.
Those 20 percent produce 80 percent of your results.
So, you should identify and focus on those things during your working day.
Do this well and you will enjoy the world of ?Productive Laziness?.
Josh: How do you handle scope creep?
Peter: It is not malicious and it is not planned but the Project Creep is out there and will attempt to, at the very least, confuse your project. The creep may be one person or many, they may have influence and authority or they may not; they may be in your project team or outside the team, they may be your ally and they may not. But what they will try and draw in to the project, that you have so carefully planned, is change.
Project Creep (as in functionality-creep, feature-creep, mission-creep and scope-creep) is a problem where the objectives of the project are put at risk by a gradual increase in overall objectives as the project progresses. So the Project Creep needs to be carefully managed, controlled, anticipated and dealt with. Change however, is good and the one thing you can be sure on any project is that change will occur. So it is not change itself that we should fear but change in an uncontrolled manner and without thorough consideration for all impact and consequences.
The best advice I would say is ?start as you mean to go on? ? you should have a change control process, so at the very first instance of a change being raised then use that process firmly and completely but also, educate your project team and sponsor on that process. Use that first example to demonstrate what you expect, why you need discipline for such changes, and the consequences of not following the rule.
So beware the Project Creep, as a wise man once said many years ago ? ?Keep your project team close and the project creep closer?. Well actually what he really said was ?Keep your friends close, and your enemies closer? and the ‘he’ was Sun-Tzu, a Chinese general & military strategist ~400 BC and he said it in his book ‘The Art of War’, but you see what I am saying I?m sure.