PM Articles > Executive View > Avoiding "Spirit-Killing" Project Management

Avoiding "Spirit-Killing" Project Management

by Cinda Voegtli

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.

Related Links
If your teams are skeptical of project management in general, or certain processes in particular, check out this case study of how one organization convinced their process-skeptical teams to adapt and actually use PM and development processes. For specific examples of how different teams have tailored PM to different types of projects, along with examples of how they communicated the flexibility and "permission" to adapt things, check out our guideline on Adapting Processes for Different Projects. Looking for a concise way to convey that flexibility, along with a sense of the parts that are truly necessary, and why? Our Project Process Philosophy Chart might help. Once you've made a change to your process, make sure it actually worked, by tracking and measuring the effects.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

I'm getting a page not found error on all the related links?

Editor: This has been corrected, Thank you!

"...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..." - looks like miscommunication on both ends. He probably thought you don't need much explanation.

Daniel, very true. After all, he'd been given that job, a "standard process" he was supposed to use with all teams, etc. Nothing to talk about, nothing to explain, right?...And I took offense - but didn't speak up. Why? Probably for the same reason - thought there was nothing to really talk about! I knew he'd been mandated to do that stuff, and I was just some mid-20 yr old whose company had just been acquired and I wasn't in control anymore. Didn't even occur to me to communicate back that I'd like to know why and might question whether we needed those tools.

So part of being sensitive as we go use our project management techniques and tools with teams should be to encourage that two-way communication - make SURE they're telling us if they're not buying it, are questioning the value, and/or just want to understand what all this stuff is. We DO want to know and they should know that and feel free to speak up.

Thanks for writing... Cinda

So you experienced 1st hand what happens in a project when the communication has not been planned and executed. Any PM should now how much communication is important in a change process ... this PM was bringing a change and should have used it's own change process tools and plans. Always interesting to see how IT applies its own process and methodology on itself! Great experience!

Touche'! Great point. Even obvious no-brainer gotta-do-it stuff must be dealt with explicitly if it involves a change for others.

I don't believe in micro management styles regardless of process and methodology being used; no-brainer should be addressed only if there is a difference not a change!

I agree with don't kill the spirit; it's hard enough to have everyone on board working together; communication is very important but not unnecessary communication.

Buying and selling is a waste of time (of changes), I think this 1st experience was really the approach of a hand over; the latter examples are typical approaches of paradigm shifting techniques, typical in the IT world of management.

Great article, Cinda. To me it shows two key things:
- It is very important for the PM to be able to "sell" his approach and show why it is benefitial to team and other stakeholders. PMs often neglect selling skills.
- Project Management should not be overdone. My rule of thumb is: use the least possible techniqes that will do the work and focus on soft skills.
I remember a joke saying:"If everything else fails try (Project) Management"

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.