Software developers wax lyrical about “full stack” all day long, what it means, what they use, what parts go with what other parts.

Funny how we never hear project managers doing the same.

Most people view a “No” as a negative (obviously), but I view it as a positive.

More positive in fact than a “yes.”

When you are managing a project and you say “yes” you over-commit, you over-promise, you cut the wrong things, you add too many features, you drive your team to work overtime.

“No” is positive because it’s powerful.

“No, I won’t add those request features until we’ve run the numbers.”

“No, I won’t drive my team to work the weekend just to hit a launch date that was brought forward by two weeks.”

No.

It’s not so negative when you think about it.

So a man calls up a random doctor he’s never talked to before and says “Doctor, I have this mysterious rash breaking out on random parts of my body, what do you think it could be?”

And the doctor replies “Well, without examining you and running some tests, it would be very difficult to say.”

And the man immediately responds “I thought you were supposed to be a medical expert.”

Why do we expect a project manager to instantly diagnose all of the problems with a multi-million-dollar 2-yr old project experiencing certain difficulties after just a free five minute phone consultation?

As a project manager, if you do more talking in a meeting than listening, you’re doing it wrong.

In any project management scenario you should always favour observable data over gut instinct.

If you have data, go with what the data says. If you don’t have data, get some.

And if you cannot get any data, then it is time to go with your gut.

But data trumps guts, every time.

Whether our gut instinct turns out to be right or wrong, we rarely, if ever, can say why the outcome happened the way it did.

“I had a misgiving.”

“Something felt off.”

“Everything feels good today.”

If you have to go with your gut, start listing out, on a whiteboard or notepad, all your misgivings, and all of your positive feelings.

The act of documenting and making concrete your “gut instinct” is the beginnings of observable data, and also gives you several starting points of what observable data needs to be collected.

The five “whys” of process failure are a powerful tool that should not be used to shame someone.

I have observed that a highly experienced and cohesive team that has worked together before can work with an inexperienced project manager, though the team is a mediocre team at best.

Good project managers are multipliers of team effectiveness.

2x. 3x. 4x more effective teams.

Bad project managers… well, they are still multipliers.

But unfortunately the number being multiplied by is often less than 1x.

When the stakeholder doesn’t want to use a project management/task tracking system because it will slow down development.

When the engineers don’t want a project manage/task tracking system because they believe they don’t need it.

That is the very point when I have decided you will not be my client and I cannot fix your project or your company.

Writing has a process. I write in draft. Then later I go back and edit. And then I go back and polish. And then I hit publish. Distinct phases. Kept separate. So that the inner critic doesn’t paralyse me. In project management, I tend to do the same thing with problems that arrive during development. Stand-up meetings give everybody information and alert people to problems. But those stand-up meetings shouldn’t be used to find solutions. Save the solution finding for later, a different meeting, a different part of the process. Distinct phases. Kept separate. To prevent the devil’s advocates and the critics from paralyzing the team.

The development tool (issue tracking, task tracking, version control, code editor) your technical lead selected for the project may be free, but it comes at a significant cost.

If your team is making decisions about which development tools to use simply because the tool is free, your team is optimizing for the wrong metric.

And if you are the one selecting the development tool because it is free, the wrong person is making the wrong decisions for the wrong people.

Delegate they say.

Without ever really explaining how.

There is an art *AND* a science to delegation.

The art is knowing who to delegate particular tasks too.

Whether the task requires extensive project management oversight.

Or whether the person working on the task does.

Whether the task can be handled autonomously.

Or whether the person working on the task is.

The science of delegation is matching requirement to skill set.

How to divide up a larger task in to smaller tasks.

Whether the task can be parallelised.

Or must execute serially with dependencies.

And  then how to track the task and the measurable objectives.

On every project I have ever lead my second job has always been to identify the variables that introduce risk to the project, and then aggressively minimize as many of those variables as I can.

When other people in the project prevent you from properly identifying the variables, won’t let you minimize them (measurement of processes and work and anything else you can measure), and keep introducing new variables, then you have a project that has uncontrollable risk.

A regular team meeting should be regularly scheduled.

Same day, same time, same location.

And it always starts on time.

And if you need to reschedule your regular meeting to later in the day?

Don’t.

Just cancel it and wait for the next one.

Okay, you can reschedule it, but reschedule at least  24 hours later.

I always insist that when I work on a project it is considered a temporary undertaking.

My project might form part of a larger whole that lasts indefinitely.

My project might last a very long time.

My project might start and stop at varying intervals due to circumstance.

But the one defining characteristic I insist on for a project is that it is time-bounded.

Without that very definite idea of a fixed timeframe, you end on projects that become an interminable death march for all involved.

“It broke” is not a bug report.

“Settings page looks wrong on my phone.” was the bug report.

“Can you give me the repro steps for this bug?” I asked politely.

“No, I stated the bug, you should be able to figure it out.” came the terse response.

The bug report read “When I look at the settings screen on my friend’s phone, it shows his account details instead of mine, even though I am holding the phone.”

Repro steps…

Have friend open app on their phone.
Go to settings screen.
Verify that account details belong to friend.
Have friend close app on their phone.
Take phone from friend.
Open app without logging out.
Navigate to account details.
Account details still show as friend’s account rather than mine.

I’m not sure what they expected.

The bug report read “No audio can be heard when PC does not have a sound card plugged in.”

There we no repro steps.

The bug report read “CD-ROM drive refuses to read DVD-ROM disc.”

I’m not sure what they expected.

The problem with agile methods applied to some projects is that we (often) cannot neatly compartmentalise pieces of work by asking “so what do you want to see next?”

The problem is frequently that we ask our stakeholders “what do you want” at each iteration when what we should be asking is “what do you need?”