It’s one thing to imagine being in charge of a project. It’s another to find yourself the person responsible for getting everybody on the team to get the work done.
Some of us are lucky enough to have mentors to help us to get up to speed on a new role in our lives. It helps a lot to have a trusted confidante to listen to our frustrations, and to give advice about the right way to approach a new-to-us situation.
That’s particularly valuable when our expertise is tactical (“doing the work,” whatever it is) and we’re given team leadership in which we need to learn to get others to get the work done. Someone with experience can explain where the bodies are buried. “Sure,” my mentor told me. “That sounds good at first blush. But you aren’t taking this into account.”
But not everybody has a mentor to learn from. As a result, you make those painful mistakes on your own – and I have too many t-shirts that say, “Oh no, not another ‘learning experience’!”
So – with the help of some experienced project managers – I collected a few snippets of wisdom that may help you in your quest for project management sanity. You might as well learn from our experiences rather than repeat them yourself, eh?
Even if I can do a task better, I must let the junior people do it.
This was my own “hardest thing to learn.” Intellectually I understood that good management is doing things by indirection, and that being in charge is enabling others to do the work… not doing it myself.
But gosh, it’s just so easy to grab the keyboard and take care of this personally. We need this task to be done, and it’s important to get it done right. And it’ll take me only five minutes while I know the less-experienced team member hasn’t done it before so it’ll take her an hour.
The reasons to delegate are obvious, I think, starting with the fact that while I can probably do their jobs better I cannot scale myself infinitely. And if I don’t let my junior people learn how to do it now, they won’t know it later, either. Right, I know this. But I would think, Just this time….
One danger in this, for project management newbies, is that we’re drawn to do the things in which we feel competent. You probably came up the ranks towards project lead because you were good at doing the hands-on work, which means you probably feel good about your ability to pull rabbits out of that hat. If you’re new to project management you don’t feel nearly as confident because, duh, it’s new. So it’s easy to put your attention on the things you feel good about, and to procrastinate on training, mentoring, or just plain trusting in the people who report to you.
I did eventually learn this lesson, though it took deliberate effort on my part, including – quite literally – sitting on my own hands. It was the only way to refrain from grabbing the keyboard.
When to fight for more time and budget
It’s an old adage that every project manager and consultant learns: “On time. On budget. What they asked for. Pick any two.”
The problem isn’t so much recognizing that there is a battle among creativity, quality, and real-world schedules. You probably do that already, based on the tactical side of projects with which you’ve been involved. What makes this a difficult lesson – once you’re in charge – is understanding that the “pick two” choices you would make aren’t the same choices made by your clients, management, or the people who work for you. And somehow you have to live with those choices, or decide to fight for the “right” one.
Several lessons fall out of this one. Since all the stakeholders have their own notion of what’s important, a project manager has to judge whether the missing item in that triumvirate is acceptable. For example, When is “good enough” good enough? When isn’t it? And in which circumstances should you fight for more time and budget because the outcome is worth it?
Worse: We all make assumptions. If you take for granted that “on time” is paramount, you take due dates seriously and you expect others to do the same. Someone whose baseline is “It has to be perfect!” may cheerfully let a deadline slip because his attention is on a different metric – and you aren’t prepared for that because you believe(d) that he had bought into the project goals.
The takeaway here is assume nothing. Even if you are sure everybody shares the same goals, ensure they use the same yardstick for measuring progress towards those goals.
Identifying the essentials and the distractions
You’re trained to look for the critical path. What must be done to prevent the project from slipping? No matter which project management tool you use, you’re told to look for the critical path tasks – but that assumes you know what items to track.
In other words, learn to keep yourself on the real critical path, and avoid being diverted by other things. One of which is the “I’ll just do that myself” tendency I mentioned earlier, which for managers is entirely too tempting. (Not that I speak personally, or anything.)
When I was new at this, I persisted in getting stupidly detailed about the wrong things. As a result, I often was sidetracked by nonessentials, and didn’t notice the things that did matter. Or at least I didn’t notice them until they had become a problem, which was the same thing.
For example, back when I owned a computer store, I had a $60,000 order to deliver to a customer 100 miles away. One $60 cable was back-ordered. Because it was a major transition for the customer (half the organization was getting its first PCs), I had to make a single delivery. A missing $60 cable held me up for two weeks. Could I have recognized the problem and found another supplier? Yes, but not when I was so new to projects of this scale.
Learning to identify the truly critical items also teaches you to budget for “slack time” in a project schedule. If you’re ahead on one task, it doesn’t give the team permission to get lazy. “There’s a trap that we fall into where we think that we’re being successful in a project if we meet most of the task target dates,” says experienced project manager Harwell Thrasher. “In fact, unless slack time is planned carefully (especially along the critical path), then a project will be late if we meet most of the task target dates. Projects have to be managed in such a way that some tasks along the critical path are completed early, in order to make up for the tasks along the critical path that will be completed late despite best efforts.”
There are a lot of other hard lessons for new project managers to learn; in fact, I had to cull these from a rather long list. But these gave me the most trouble when I was just getting started.
What was the hardest thing you had to learn about managing projects effectively?
Comments on this article are closed.