I’ve seen so many projects fail because they were outside of the capabilities (technical, structure, team composition, knowledge, manpower) of the executing team.

Far too often project managers (if they had any say in the bidding process) failed to determine whether the specification was within the capabilities of the team.

Determining beforehand if the team on-hand and any projected new hires matches up with the requirements and specification goes a long way to knowing whether to not bid or stop your bid on the project and shutting down any proposal effort being expended.

In common parlance, if you don’t think you can pull it off, don’t bid on it.

Being parsimonious (frugal) on a technical project when it comes to project expenditure is always wise right up until you are investing in tools that aid or speed up development.

Frugality of expenditure on tools is never a smart move.

Your optimism as a project manager should be applied towards your team, not your scheduling.

The worst assumptions to make on any project are when you start contemplating macro-level variables.

You cannot control macro-level variables in any meaningful way, and often they fall in to the extreme quadrants of predictability and changeability.

Two of the biggest red flags to watch out for is when someone is trying to predict a macro-level variable – the future value of the stock market or a change to the law.

Or when someone is trying to change a macro-level variable – the direction the Earth spins or the time that the sun rises in the East.

The sole purpose of a daily stand-up meeting should be to collect information, not find a solution.

Stand-up meetings should be used to alert people to problems, not pontificate on possible solutions.

I’d only ever have a roll-up-their-sleeves technical project manager on a very small project.

Otherwise you have a serious conflict of interest.

And someone taking their eyes off the ball.

Once you progress beyond two people on a project, project management is effectively a full-time job.

As a member of technical staff or creative staff, if you view your project manager as overhead or unnecessary, then they are neither, what they are is a bad project manager.

It can be frustrating to be a highly capable individual contributor to a project, only to be suddenly thrust, usually unceremoniously, in to a project management role, and then to realise, we can no longer spend as much time contributing in ways we find familiar.

Trust is the currency that project managers deal in.

Their stakeholders have to trust them.

Their team has to trust them.

A meeting with more than two people scheduled less than a day in advance is somebody’s addled reasoning to disrupt everybody else’s workday.

I’ve noticed a preponderance with many smaller projects is that whilst most of the fundamentals of the project management are sound, quite frequently the measurable objectives are missing or terribly fuzzy.

You cannot declare done, nor success or failure, if your objectives are not concrete.

I love the hopeless optimism of project managers working on their first software project.

That gleam in their eye that says “I am confident that I have accounted for every detail and nothing will go wrong. You developer chaps just need to write the code given in the spec and we’ll ship this product on time and on budget.”

Watching their spirit get crushed and the light in their eyes go out as the project enters its six month of death march is always a sight to behold.

And a valuable teaching moment.

I have always found it hard to teach software engineers that “measure twice, cut once” is a good rule to live by.

If you don’t trust someone enough to create extraordinary work, why are you expecting them to create it?

Came to the realization that many artisans of their craft use phrases such as “It needs more love” or “Let’s put this in there because it really pops when photographed” or “Add a twist of this to give it some mouth feel.”

This is shorthand for people they work with to know “Go back over the level and add some fine detail” or “Use this red tea towel next to the food” or “Add some lime juice.”

Unfortunately a lot of people pick up on these phrases and then just throw them around to mask the fact that they don’t actually know what they are talking about or what they want.

So we become skeptical and wary and then have to listen to the project manager explain that “We need to give that dinosaur more love and see if we cannot jankify it up at the same time” and still be able to look him in the eye in the hallway as we go to lunch.

There are certain types of work that always expands to fill the time available.

There are always managers that want their project to fill the time available.

And there are most definitely software developers who believe that any task should fill the time available.

It is rare to encounter a complete self-starter on your team.

Just about everyone will stand around waiting for direction.

When you find yourself with a self-starter it can be a challenge to get them going in the right direction if you aren’t ready to have them start.

How I’ve handled self-starters in the past is to promote them positions where their willingness to start something directly moves the project planning forward.

If they are technical, you can assign tasks for prototyping and researching interesting new technologies.

If they are creative, get them brainstorming new user interactions and use cases.

If they are organisational, get them to help with the project management.

It is not the failure of the self-starter to move in the proper direction, it is the failure of the project manager to utilise them effectively.