Wow. What impudence! giving advice to project managers. well alright yes, let’s dare. Just some reflections on how to handle certain aspects of your project. These reflections come as much from my experience in the matter, and also from what I am (my personality), so they won’t apply to everyone.

The first thing to know how to do is manage priorities. In the list of actions to accomplish for the project you must know with a certain precision, or a certain intuition, in what order the actions should be arranged. I’m not going to give examples you all have in mind the issues of arrangement and dependencies whether technical or organizational, to understand this. As a project manager your ability to properly order, to properly “prioritize” the tasks will be crucial. With tasks being linked to each other, the teams assigned to tasks, the sum of errors (which are inevitable) can prove fatal to your productivity. You need a certain vision (global) on the project, a certain experience, an understanding of the different challenges: a mental map of the project that brings together a bit all its axes (technical, functional, schedule, client relations, team availability, etc etc etc). Above all don’t have the “MS Project grid” completely embedded in memory, a project is a thing that evolves constantly -unlike your initial schedule/breakdown- and therefore it doesn’t work that way. Especially since good priorities are also linked to your client’s rhythm, to their way of approaching the project. In any case:

1. Don’t hesitate but base your choices on logical reasoning: I trigger this because of this this and this (=> your “mental map of the project”).
2. Everyone can be wrong, know how to go back if needed, or stop a task in progress as soon as the first “feedback” shows that it wasn’t the right choice (or because another criterion has changed the game).
3. Be ready to say yes, no at any moment. Especially “no” actually, because you need to avoid starting tasks that will be better understood later in the project. Keep on hand some “buffer” tasks, not complex, incompressible (that will have to be completed no matter what), that don’t need to be performed by a particular profile, and that have no dependencies, this in order to give yourself a bit of time for reflection if needed.

Ahh that’s hard, isn’t it. How many times have you told yourself: “okay fine, if I do it it will take 30 minutes, if I give it to them, hmm… 4 hours”. So you do it… I see two big mistakes: first, gone is the priority management mentioned above since you’re launching into an unexpected task that becomes priority 1 (for very bad reasons) and prevents you from keeping enough distance and enough time to continue managing the project well.

Secondly, you’re making a very bad bet for the future. This choice indicates that you don’t trust your team members. Perhaps rightly so, but the minimum is to give them their chance one or several times. If indeed you can’t trust some of your team members you have to say it and make a decision about it (I’ll come back to this). But you need to base it on concrete facts and hold people accountable. Assign tasks. In many cases this will prove rewarding: people will progress, you’ll trust them, you’ll be able to delegate more and more often, they’ll be happy about it (even proud).

Same scenario: I start the task so it gets off to “a good start” then I delegate it. Same problem. Know how to judge after the fact: this judgment will be based on facts! (that’s still essential isn’t it?)

I’m bouncing off the previous paragraph. We judge people on facts. So A) no a priori judgment. The work is going badly: too much delay, no quality, etc. We say it. We don’t pass judgment, we say things. We’re behind. Why? let’s discuss. let’s know why. This isn’t necessarily related to the person naturally: they weren’t trained, the specs or requirements are terrible, an unexpected problem arose, etc etc. It’s really related to the person (they’re not motivated, make no effort, have personal problems that make them cantankerous, etc.): we tell them. I’m not satisfied for such and such reason. I expect from you this this and this. Can you make an effort on these points. thank you. If the problems recur regularly and are destined not to evolve I recommend removing the person from the project. This rarely happens if at regular intervals we say things. Saying things is the first way to establish a certain trust or at minimum a certain contract. What’s more unjust than getting kicked off a project without having seen the bullet coming? What’s more normal than being warned when someone is not satisfied with your work? What’s more exhilarating than watching yourself progress? (I refer you on the same subject to this post)

I see too many project managers who don’t say things because they feel that their judgment is final and global. If I tell X that they did this task poorly it’s as if I’m telling them they’re bad. Nothing could be more false! Repeat it as many times as necessary to your collaborators, but be convinced yourself: yes there are good ones, yes there are bad ones, but each can change categories depending on projects, with time (in both directions), depending on interlocutors, depending on context etc. It’s not for you to have a judgment: it’s for you to give them the opportunity to prove themselves. I come back to the previous point: not saying things when they happen but later, too late, only accentuates this feeling and confusion that the judgment is global. If you say things punctually in direct connection with a present event this avoids a lot of misunderstanding.