Avoiding spirit-killing project management

Someone asked me recently “How do I know whether I’m using ‘just enough’ project management on my project?”

My thoughts went immediately to the environments I’ve witnessed or experienced on projects – because the use of too much or too little project management typically shows up in the emotional state of the team. I refer to the use of “too much” project management as spirit-killing project management.   Wow, sounds horrible, doesn’t it?  Well it really should, since in the end it can produce the exact opposite results of what we want.

My first experience with spirit-killing PM was when I was a line manager in charge of a hardware engineering department in a start-up, and we were bought by another company.   Right away, we were sent our very own project manager!  But what I remember, rather than feeling a sense of help and support, was feeling instead a sense of immediately being WEIGHTED DOWN – by all the pieces of paper that were suddenly thrown at me as “must-dos”.   I frankly didn’t see the need.  We had managed just fine before this.   It just seemed like a lot of busy work for someone else’s benefit, not something that would help me and the team.

Not an auspicious introduction for me to formal project management.   “No value add” is the initial impression I had.  And it did deflate me energy-wise.  Now on top of everything else I had to get done, I had to do some useless paperwork for someone else. 

I’ve hit this again and again in environments where people are diligently and with the best of intentions trying to bring more project management discipline to the company’s work – and yet the reception can be chillly at best!   Although sometimes that resistance is unreasonable, sometimes it may have to do with how  well we’re attempting to apply techniques to specific projects.   I’ve also seen spirit-killing PM attempts totaly turn around due to someone recognizing the counterproductive nature of what was happening, and engaging the team to come up with something that would work. 

For example, a game development company whose founder absolutely needed status info to keep his team on track to making milestones (which were tied to payments from the game publisher, which were funding payroll!)   Trying to get what he needed, he switched from written status reports…to getting status by walking around… to posting key areas of the game on a huge whiteboard and letting the developers check off their work as they got done.   Before, they were torqued about having to write something formal;   even with the walking around approach they were disgruntled about being interrupted and questioned. But then a team member suggested the whiteboard approach, the founder agreed, and they all loved it.  It actually helped them see where they were and where their colleagues were,  get a great sense of progress with a glance, AND no one had to interrupt them to get information.

Another example – a data communications company that early on developed a product development lifecycle, because the executives came from larger companies where the need for discipline was understood.  From the beginning, the hardware engineering and manufacturing side used the process and its deliverables, because their value was accepted.  This wa s a high-volume manufacturing operation and any mistakes could be costly.   HOWEVER – the software folks took one look at the big process binder and turned away,  ignoring good techniques and deliverables that could apply to them,  because overall the process did not look applicable.  The company eventually recognized the issue, and launced a methodology update project with ample software representation, to update the process to include the way the software teams got their work done, AND to define a set of minimum deliverables for different types of projects.  Iterative release projects…. demos…. 2 week feature enhancement projects… as well as larger complex software releases.  They built in guideliens for small sets of deliverables, less formality in some cases, small teams.  They melded the best practice items that would deliver value, with enough flexibility and informality to not slow down projects or kill spirits with non-value-add work.

Now looking back to my original experience with the new project manager and his paperwork – Of course I wasn’t totally right either – there were some valuable techniques in that new PM’s toolkit, which I discovered later.   But this emphasizes another key learning –  his PM approach killed my spirit initially because there was no explanation, indeed no “sell” associated with it.  He walked in, assumed I’d value it as much as him, and operated from that outlook.  It was wrong, and it severly impacted my initial acceptance of him and his role.  In the other examples mentioned above, a great deal of positive energy resulted from the companies’ specific attention to making PM work for the groups and their different types of projects.  The attitude shifted to more openness just because someone raised the questions of what isn’t working and how can we make it work better for you?

So  – as we all bring project management techniques to our teams, I think it’s important to avoid killing our teams’ spirits by applying what we’ve learned in class or elsewhere, without asking how to best make it work for the situation at hand and the people and culture we’ve got.   We should feel free to do so, not feel that we’ve been handed some rigid approaches that have to be done exactly a certain way.    Some of the best advice I ever got was to make the process work for the people, not the other way around.

If any of you are facing challenges in this area, happy to answer any questions.  I’ve dealt with this in a number of different environments, including software and biotech and medical devices and small projects of different kinds, and have examples of how different teams have tailored PM to different projects if that would be helpful.  Including how they went about expressing to their teams and PMs the flexibility the teams should assume to make it work for them, how they documented minimum deliverables sets and simple management guidelines for different types of projects.