3 PM mistakes that put software projects on death march

How to fail a software project as discovered by a Junior Software Engineer.

Software Engineering students at the University of Ottawa are required to complete a capstone project. The capstone project is an 8 month software project that ends with the delivery of software to a client.

During the progress of my final year capstone project, I made several lethal mistakes that a more experienced project manager could have avoided.

The following are 3 core mistakes made that doomed projects for failure.

(Do not) Promise more features.

Instead, manage expectations.

Undoubtedly, you and the client will brainstorm together.

You’ll mention some crazy feature.

You’ll share a laugh with the client.

There will be a pause of silence.

The client will ask, innocently: “is that possible?”.

As an engineer, the question poses a challenge.

Is it possible? Yes, anything is possible!

So you tell the client, “yes”.

In the wise words of Dj Khaled, you just played yourself.

Software development projects are notoriously hard to estimate.

By accepting more work, that initial estimate you made at the start of the project is now even more inaccurate.

At the end of the project you will find yourself miserable for having worked more than expected, with an unhappy client who is settling for a project below their expectations.


It’s ok to tell the customer no. It’s better to negotiate with the customer and find a common middle ground.

(Do not) Perfect your code base.

Instead, focus development efforts on high roi tasks.

When writing code, you may find yourself inside a jungle.

Variables with labels that don’t make sense.

Duplicate code.

Inefficient algorithms.

You’ll think, I’ll just fix the one class while developing the feature.

You just spent an hour extra cleaning up the code base, but now the class is a work of art!

Keep your code editor open so you can admire your work while sending the client an email letting them know their project will be late.

Optimize only when it’s important. If the client doesn’t care about loading the table data 0.3 seconds faster, than neither should you.


Working code is perfect code.

(Do not) Measure success with arbitrary metrics.

Instead, choose metrics that the client also values.

The first thing I do after a hard week of work is open up Github insights.

How many commits did I contribute?

How many lines of code?

Now go tell the client that and see how much they care!

Adding 10,000 lines of code in a sprint doesn’t mean you added any value. Lines of code as a metric is known to be a poor choice (but I bet you take a peek at it often anyway, I do!).

Alternatively, sprint velocity can capture value added during a sprint much more accurately.


If you pay attention to the wrong metrics, you will focus your effort in the wrong spot.

Action Items

  1. Only commit to complete work that you have a strong understanding of. Manage expectations.
  2. Write great code the first time… And then let it do the job. Write working code.
  3. Measure what is important to the success of the project. Choose metrics that track value delivery to the client.

Let me know your thoughts, Chris