Avoiding ‘Spirit-Killing’ Project Management

by Cinda Voegtli, originally published on ProjectConnections

Someone once asked me, “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 of the results we want.

My first experience with spirit-killing PM was as a line manager in charge of a hardware engineering department in a start-up. We were bought by another company, and right away we were sent our very own project manager! But rather than feeling a sense of help and support, I remember feeling a sense of immediately being weighed 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 to formal project management. “No value added” 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. The reception can be chilly 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 totally 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, I remember 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, and 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 and 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 was 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 launched 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 guidelines for small sets of deliverables, less formality in some cases, small teams, etc. 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-added 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 he did, and operated from that outlook. He was wrong, and it severely 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 each group and their different types of projects. The attitude shifted to more openness just because someone raised the questions, 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 their spirits by applying what we’ve learned — in class or elsewhere — without asking how best to make it work for the situation at hand and the people and culture we’ve got. We should feel free to make those changes; not that we’ve been handed some rigid approaches that have to be done exactly in 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.