Project Management Lessons: Handling “Less Than Ideal” Behavior
Admit it: every project has issues. Some of those issues are due to people not, let’s say, behaving their best. None of us “behave our best” all the time. I welcome comments from those of you who are perfect. I’m training to qualify for the Boston Marathon but I have a serious weakness for milk chocolate. And Reeses Cups. Reeses Cups are not allowed in my house.
One of the many benefits of project management experience is that over the years you collect ideas, learn from others, see how different industries work (or don’t), etc. You get to try all kinds of ideas and learn from the failures and successes. One of the many PM lessons I’ve learned is how to sometimes mitigate the “not behaving our best” issue: try shining a figurative spotlight on the behavior.
Here’s an example. We all know what “scope creep” is. Sometimes the stakeholders will add scope as a collective decision — this isn’t what I’m referring to. I mean the one or two small bug fixes that someone wants to sneak in since, for example, “you’re in there fixing the code anyway.” Or reorganizing something since it would fit right into what we’re already on the hook to do. Retiring technical debt is a common issue that’s addressed like this. The person suggesting the add is often a senior person and feels that they can intimidate us into agreeing. Yea go ahead, I dare you to say “no” to a VP. How do we deal with this? Do the right thing. Follow the standard scope change management process: write it up, assess the impact (time, staff, cost, etc.), and present it to all the stakeholders for review and approval. Show it to everyone. Shine a light on it. If it is actually something someone wants to “sneak in” they’ll often times back off. Or they’ll insist that we don’t need to follow the change process. Stand firm and stick to the process. If you’re going to get fired then get fired for doing the right thing. I finally learned that lesson a few years ago.
Another example is managing accountability. Someone is on the hook to do something and they don’t do it. We as project managers almost never have direct line authority (we’re not the “boss”), so not delivering isn’t perceived as carrying much risk. Could we raise the issue to management? That’s what sounds like a solution but it rarely is. Management knows about performance issues already. They haven’t dealt with it before so what makes you think they’ll deal with it this time? Besides, we’re supposed to be problem solvers. Here’s a better idea: shine a subtle light on it. Not glaring. Subtle. In a daily standup, let the person repeat day after day, in front of all their peers, that they’re still working on the same thing. Day after day. Have each team member demo their work during the iteration/sprint review (what used to be called the sprint demo). The person who doesn’t have much to show will stand out for the wrong reason. I’ve had people call in sick on the review day. They had the “I didn’t get my work done” flu. Nobody wants to be seen in this light.
What do we do as project managers to try to keep things on track, keep it positive, etc.? We think. We innovate. We never try to embarrass someone. Never. Period. We help the person wanting to add “one more thing” to the project any and every way we can think of. Assess the change honestly and be the advocate if it makes sense. Fight for it. Help out!! We help the person who’s not getting things done any and every way we can think of. Meet on the side, get them some training, dig into root causes like too many distractions and try to screen those off, etc. Help them!!
We as project managers are responsible for delivering projects successfully. We are problem solvers. It’s on us to be creative. To be innovative. Sitting back and blaming others for issues isn’t acceptable. Trying to hand off issues to senior management to solve isn’t acceptable. The buck stops with us. This is another lesson I’ve learned. Experience and mistakes are excellent teachers.
