The term project management (PM) is used by many people in totally different ways. I also call myself a project manager because in 2016 I had a training course on “practical knowledge for project management” and I am responsible for several IT-projects. In the recent past it became anoying to me reading articles about PM in the web or trying things out that have different baselines.

A Brief Background

On the one hand I noticed that it is fancy to do everything the agile way, especially in the domain of software projects. SCRUM or Kanban promote an interesting mindset and provide comprehensive rules. So should we stop thinking about the recommendations of classic management now? In that case a project manager would ignore important phases or processes, where an agile appoach has no answer for.

On the other hand there is the classic PM. The Project Management Institute or PMI is the biggest organization of its kind and created a ‘standard’ in a certain way. The PMI defines and describes every tiny detail you could ever imagine. So I decided to dive into the Project Management Body of Knowledge alias PMBOK®. Of course there are also other paradigms, but I have choosen that one - get over it!

The five process groups do not represent a chronological sequence.

graph LR A[Initiating] --> B[Planning] B --> C[Executing] C --> D[Monitoring & Controlling] D --> E[Closing]
graph TB A[Initiating] --> B[Planning] B --> C[Executing] C --> D[Monitoring & Controlling] D --> E[Closing]

The PMBOK-Guide structures the whole thing into five process groups. Please note that these are not applied in a chronological sequence. These five groups contain 49 processes in total to cover every situation a project manager might face. It is up to the project manager to implement the provided processes in an appropriate way. So when it makes sence to not apply a certain process or to iterate others - which is a hard rule in some places - it is absolutely in accordance to PMI.

At this point I learned that the classic PM has applied agile methods long before it was popular. The term PMI uses is called rolling wave planning, which means you plan, execute and monitor & control in an iterative way - sounds pretty agile!

Common Mistakes

Okay so the following thoughts are just what I have learned from my daily life. I am curious to find out what your experiences are, so leave me a comment.

  1. One of the first problems is that unexperienced project leaders might think that management tasks are too costly or needless, which results in leaving important stuff out. It is often forgotten that project management is about defining how things should be done in your project and making things measurable. When you don’t define success parameters in your project, how could you measure it or even become successful?
  2. As project manager it is probably the most important job to communicate to your stakeholders. So not knowing them clearly or ignoring some of their requirements is fatal.
  3. Facing risks or uncertainity is the daily job of the project manager. The worst thing you could do is to slow down the decision process. Don’t forget that you are not responsible for problems - only for the way how to deal with it. As a project leader you always have the choice to decide on your own or to escalate the decision. It is not a weakness delegating decisions, it is your power to decide how the things should be resolved.
Never Stop Learning

In order to unite all the fragments of PM knowledge I had and to build that on top of a solid ground, I started a training course for the Project Management Professional (PMP). To be honest, the theory is seriously hard and I am not sure if I will be successful but the training-time is worth it. Maybe someone will find my preliminary insight usefull.

So here are some good axioms I learned:
  • Every project management costs, but it never costs more when it is done right.
  • It is impossible not to decide. Even making no decision is a decision (often the worse).
  • Define how you do the things. It is okay to skip some aspects of PM when you can justify it.
  • It is impossible not to communicate.
  • Ask yourself: Is 'it' appropriate for my project and does 'it' support my objectives? - It could be every decision or process you apply.
Conclusion

I started calling myself a project manager when I became responsible for the success of ‘my’ projects. In my opinion it is important to learn the ground truth from world leading professionals. Joining courses for PM is always a good choice compared to half-true stories from the web - not like mine. My choice was the PMP - a very comprehensive theory. Additionally, I apply agile methods and DevOpp-toolings in a sensible way within the project execution.

Finally, I strongly recommend not to see classic PM and agile methods as divided or incompatible. Apply whatever is appropriate for your project.

Writing this post was powered with music from Tool - Sober.
Have a nice day!
See also
Share this
Leave a comment