From a Confused to a Happy Project Manager
June 21, 2012 | Author: PM Hut | Filed under: Project Management Best Practices
From a Confused to a Happy Project Manager
By The Grumpy Project Manager
The confused project manager
A new PM joints the organization. Some project management manuals and ‘how things are done here’ training are provided. Depending on the organizational culture the PM gets planned support from other project managers or various contradictory advice, or is left alone to ‘independently’ run projects. In any case the PM is confused; trying to learn how projects are run in this corporation, to follow how experienced project managers do things and to work with experienced project workers. The PM is managing projects but feels like an outsider. It is not clear whether the projects are running the PM or the PM the projects. Gradually the PM learns the standard practices and knows how much those are followed. The PM also learns that trying to be like the other project managers doesn’t work, but the PM has to find an own way to manage projects. Some project succeed, but many cannot keep their timetable and budget.
The grumpy project manager
Now the PM is familiar with project management practices in general and in this corporation. The PM has an own way to manage projects. This means an optimal combination of personal qualities and project management practices. The PM also knows that project groups are different and need different emphasis on management and leadership. The PM knows when it is possible to build good team spirit that takes projects forward and when it is necessary to rely strictly on detailed plans. The PM is now clearly inside the project, has good control of the project group and good routines that ensure professional project management. The PM is no longer confused. More projects succeed but many still cannot keep their timetable and budget even though the PM is in control, holding all the visible strings. This makes the PM grumpy. From inside the project everything seems to be in good order. The PM reads from various articles that most IT projects fail, so maybe this is just how it must be. The PM could just accept this and go with the flow but does not. Instead the PM becomes grumpy and tries to work harder and harder to succeed better.
The happy project manager
One day the grumpy PM starts to think if this makes any sense. The PM stops working harder and harder and takes a few steps back from the project. The PM is not outside the project like the confused PM was, or inside the project like the grumpy PM was. The PM is above the project, seeing not only the project but also the operating environment: a busy line organization, different department, possibly organizational silos etc. And also other projects; the project network the PM’s project belongs to. They are all competing about the same resources, attention, priority etc. The PM also realizes that projects are often dependent on persons who are not project work professionals. When the PM goes inside the project it seems like a one month project. When the PM goes above the project it starts to seem like a one year project. This may be for example because the production is very busy during the next few months and the subject matter experts won’t be able to support the project like planned. Or because another project with a higher priority has just been initiated and will take most of the attention. For a short while the PM may be distressed, but after the PM understands which things the PM can influence and which just needs to be taken into account the PM becomes a happy project manager. This does not mean that project management becomes easy or loose but more controlled with a good overall cause-effect understanding of the project network and the operating environment.
Similar phases can also be applied to project portfolio management organizations
The grumpy project portfolio management organization
A GPPMO struggles continuously with its projects. It works very hard to take projects forward but often fails. It initiates even more projects in order to feel and seem efficient. It reports the amount of active projects instead of ROI. It has ‘campaigns’ to improve project management practices: ‘now we put special effort on communication’, ‘now we embrace good team spirit’, ‘from now on everybody must fill this form’… It identifies a problem in one project and thinks that fixing that will improve all projects. It cannot keep timetables because there are just too many project that compete about resources and attention. It uses having too many projects as the reason for not being able to keep the timetables.
The happy project portfolio management organization
A HPPMO has taken a step back from the daily routines. It views continuously corporate strategic objectives, operating environment and the network of projects. It has a limited amount of projects and those support each other’s objectives. It defines clear priorities for projects so they don’t compete with each other. It has several happy project managers who don’t compete with other project managers. It offers planned support for both confused and grumpy project managers to make them happy. It offers transparent project management and reports ROI. Having a HPPMO does not mean that work becomes easy; the better projects are run the more is expected from them. A HPPMO is happy because it is like a well run business; it knows it is valuable and can prove that.
The Grumpy Project Manager is a program manager in an international corporation and has over ten years of experience in managing R&D, IT and business development projects. You can read more from the Grumpy PM on his (or her?) blog. S/he can be contacted by email at TheGrumpyProjectManager@gmail.com.
No comments yet.
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.











