Project Management vs. Practical Management (Part 1)

Thoughts on how to apply PM concepts to everyday management and leadership

Before I dive into this topic, I want to put down my credentials in this area (though I covered some in my introductory post):

• Practicing Project Manager (PM) since 2000 (earlier if you count what I did as an Army officer which the Army now does as I've seen officers with PMP credential)

• Project Management Professional (PMP) since 2004

• Performed roles formally and informally at all levels: project, program, and portfolio management

• Collegiate level instructor on topic for more than a decade

• Either worked full-time or consulted in associated roles at all levels across multiple industries (tech, telecommunications, healthcare, energy, fintech, etc.) for almost 25 years

• CIO on two stints as well as CEO of small software firm

• Have run projects domestically and internationally

Okay, enough with the resume. I'll bring some experiences up directly as I continue to post on this substack. In this and the next couple of posts, I want to focus on project vs. practical management. In other words, what you learn as a PMP versus what is reality when you apply to the real world. For those who don't know, the PMP is a certification given by the Project Management Institute (PMI) that requires a certain level of existing project experience, training, and culminating with an exam. After being awarded the PMP, you must also demonstrate continued practice in the field and obtain some Continuing Education Units in order to maintain it. Much like CPA is for accountants.

When I first got my PMP, my organization at the time sent a bunch of us to structured training. Though it was supposed to be about project management it was more a "how to pass the PMP exam" course. Don't think I retained much or used much from this course in practice but the first thing the instructor said to us always stuck and is still relevant to this day. He asked "how many of you are currently already in or have been PMs?". Of the 20 people probably a half a dozen of us raised our hands. He then responded: "the rest of you are fine, for you few you need to unlearn what you've learned". Meaning the things you've learned in real-world practice are not necessarily or likely to be the same as the "standard" of project management that PMI wants (and will be on the exam).

Its this distinction I plan to focus on in my next few posts. The first area I want to focus on are the steps of team development. As defined by PMI, those are: forming, storming, norming, performing, and adjourning. Those sound GREAT.... they even rhyme and everything!!! Now, the PMI standard was developed out of the construction arena before it was later applied to other industries. Maybe there those steps are accurate but in reality (and in my experience) its a little different. In particular:

• Forming: Whether a project, operations team, or some other organizational unit, I have only been able to "select" my team on a couple of occasions and even then a couple of members were thrust upon me. So in reality "forming" really is about figuring out what you have and how best to use them. You may get the opportunity to modify the team but likely, you get what you get (at least to start).

• Storming: This should be about discussing the opportunity (project, ops work, etc.) tasked to the team but as noted above, it now also includes figuring out what the strengths and weaknesses of the team members are, what holes you have, and how to address those. That's on top of the work you need to get done.

• Norming: This phase should be about outlining how the team is going to work and organize best to get the work done. In reality, you are tied to many constructs of the parent organization and you need to figure how to operate best within that environment.

• Performing: While this is probably the phase where the standard and reality are closest, its not without its issues. The biggest problems revolve around expectations from the greater organization and the strain put on resources due to other projects or work.

• Adjourning: This one was always my favorite. In this phase, the standard calls for a nice clean review of lessons learned that are discussed and documented and then the team is formally "released" to go on to the next project or work. Odds are they were already working on the next thing and have no time for this. Thus "lessons learned" are not captured or are subject to "proximity" (e.g. only document the most recent things) or other biases that make it almost useless.

Okay, I know what you are thinking: "thanks Jefe, you just dumped on everything so why should we even bother?". I get it and sorry for the dose of reality but it was necessary to get you to where you are looking for answers to these problems and I'm happy to provide some thoughts. Keep in mind that in my opinion, none of these phases is static but rather happen throughout:

• Forming: Believe it or not, most people want to do a good job. Whether its the novice who is clearly in over their head or the experienced person who has lost their passion. Your job is to bring them both to some equilibrium. One of my methods is the following phrase (give or take): "you all are professionals... you wouldn't be here otherwise. I will treat you that way unless you give me reason not to". This asks all team members to step it up. However, you have to be capable of making changes. I've not been above canning a more experienced person for a more eager, inexperienced person if its better for the team. Similarly I would take experienced people and talk to them one-on-one as to what it will take to get the best out of them.

• Storming: This is going to depend on the size of the team. If small, take advantage and get all inputs. If you've never done it, some variation of the sticky note method is great. For a larger team, you need to take the lead and even if your knowledge is limited, develop a framework for others to comment on. The key is to get through the initial iteration of this phase quickly as the plan will change many, many times. If anyone has ever gotten through a project or plan based on the first iteration, go play the lottery --- you're a unicorn!

• Norming: Two phrases I've always banned: 1) That's the way we've always done it; and 2) this is how the last _____ was done. Especially in the case if you are taking over an existing project or operation. My usual response is "if those were working, I wouldn't be here". The goal here is to get the team to think of their unique situation. Odds are it doesn't fit with any previous examples if the organization is doing things right or you just require a project coordinator (e.g. someone to take notes). Act like your the new coach of a team, would you want to be held to the previous person's method? Not a chance!

• Performing: Of course, this is the most important phase but understand, it will always be changing. The three "phases" noted previously will change (which is why that is in quotes as I don’t think it’s an adequate description) and it will change your performance. Team members will come and go, rules will change, and other items will affect performance. Focus on the key (critical path items -- even if those change and they will) and learn to beg, borrow, and steal. Take some time from an inconsequential task to complete a big one. If the ball is moving, the organization usually stays happy. Make sure not to over commit though. That is key!

• Adjourning: There is only one way to make this work; document along the way. Put in some checkpoints where you capture what's happened up to that point. If you wait until the end, don't even bother. However, doing along the way, you might discover some issues you can address that makes the rest of the work go better.

So what do you think? What do you agree with? Where do you think I'm full of BS? I'm not above learning from others. Let's discuss.

Otherwise, until the next time, goodbye from the desk of:

El Jefe

Jefe SMC