A Simple Project Management Process

Here’s the simple process we use to manage projects at my company. You can use it to manage anything.

What’s a Project?

A project is an outcome we commit to achieving that requires our team’s effort and attention.

A project has one primary owner. The owner is accountable for completing the project, according to its acceptance criteria, by the due date.

Milestones

A milestone is a partial piece of a project. A milestone works like a project within a project, and managing a milestone works the same as managing a project. The project owner is accountable for completing each milestone, according to its acceptance criteria, by the due date.

Commissioning a New Project

New projects get started like this:

1. A project commissioner asks someone to own a project for them, and the owner agrees
2. The project commissioner, project owner, and potentially other project stakeholders define the project’s milestones, complete with due dates and acceptance criteria.
   This is also when budgets and resource allocations are defined, e.g. how much of other people’s time in the company the project owner is allowed to take.
3. From that point on, the project owner is a black box (from the perspective of this project-management framework) who has committed to get the milestones done, or else proactively raise exceptions

Exceptions

A project exception happens when it becomes known that any upcoming milestone will not be completed (to acceptable standard) by its due date. There are two types of exceptions:

• Proactive exception: The project owner raises the exception to the project manager well before the milestone’s due date — ideally with enough time for the project commissioner to (have the option to) take over the milestone management and make it still happen on time
• Reactive exception: The exception is discovered by the project manager on or after the milestone’s due date

The project owner is responsible for delivering each milestone on time to acceptable standards. But sometimes, for whatever reason, it’s not going to happen. In these cases, the project owner is responsible for raising a proactive exception: letting the project manager know which milestones are compromised and why. Then the exception will be handled.

Reactive exceptions should ideally never happen in the project management process. They indicate that the project owner isn’t capable in that role.

Delegating

The project owner’s job is to get milestones done on time, using whatever strategies they can think of, using whatever resources are at their disposal.

The project owner may explicitly delegate a specific milestone to another milestone owner, who then takes on the same kind of expectations of a project owner, but just for that milestone.

The project owner may also do various kinds of implicit delegation — that is, delegation that isn’t necessarily visible to the project manager, nor part of this project-management framework. For example:

• The project owner may be able to have the team of people they manage work on their project’s milestones
• The project owner may be able to commandeer time and resources from another part of the company
• The project owner may be able to outsource work to a third-party firm
• The project owner may be allowed to hire people to help with the project
• The project owner may be able to crowdsource some of the work on the internet
• The project owner may build clever software algorithms and other business processes to make the project easier to work on

Implicit delegation is extremely awesome and powerful because it allows the project owner to “work smart, not hard”. When done well, the project owner will get credit for accomplishing many milestones, without breaking a sweat.

Just note: Even when these kinds of implicit delegation are happening, it doesn’t change the fact that the project owner is still fully accountable for delivering their milestones. The project owner can’t make excuses and pass the buck down to the people they decided to work with.

Project Manager

In a company with multiple projects, it’s common to have a project manager who helps track and facilitate multiple projects at once. The project manager is responsible for:

• Making sure the status of the project is always tracked and communicated
• Spot checking to ensure that progress is consistent with the standards set out in milestone objectives
• Making sure exceptions are raised proactively

Handling a bump in the road

If the project hits a bump in the road, but the project owner is confident that all milestones will still be completed on time, then the situation might not be an exception. But it’s generally better for the project owner to err on the side of raising a tentative exception (communicating with the project manager and/or commissioner), rather than acting like the project is on track and risking a last-minute exception. Because, unfortunately, exceptions raised at the last minute are reactive exceptions.

Handling an exception

Handling an exception is done by the project commissioner — often it’s the project owner’s manager who has assigned them this project, but it could be anyone else who needs the project done.

In the simplest case, the exception can be handled without modifying any milestones. For example, the project owner’s manager can give the project owner some advice which makes the project owner realize that the original milestones are all achievable on time. Or more resources can be injected into the project (beyond what the project owner previously had approval for) which empower the project owner to achieve the original milestones on time.

But in many cases, handling the exception involves adjusting the project’s milestones, and possibly the milestone ownership. Since the project manager is responsible for recording any changes to milestones in the weekly project report (detailed below), exceptions that result in milestone changes will leave a record.

Once the exception is handled, the project is back in a normal state.

The Weekly Project Report

The Project Manager puts together a weekly report on each project. The report is completed by noon every Friday, and covers the 1-week period since the previous report.

Projects Report Format

[Project Owner] Project Title

Milestones

• [Due Date] Milestone Title
• Description of any non-obvious acceptance criteria, or links to such details
• Link(s) to deliverables completed or in progress
• [If necessary] Additional information about why we believe the milestone is on track

Updates from last week

• Describe incremental progress made
• Any misc details that are interesting to report to the project commissioner

Milestones

First, if the project existed last week, all milestone headings (title and due date) must be copied from the previous report, with any updates made explicit:

• If the due date of the milestone has changed, show that by crossing out the old due date and writing in the new one
• If the milestone has been replaced or merged into a different milestone, cross out the old milestone heading and write a bullet under it explaining the update.

Under each milestone, provide links to deliverables that the report reader can spot-check in order to confirm that the project looks to be on track (i.e. a good chunk of work has been done, and the quality is approaching the standards of the acceptance criteria).

If it’s not easy for the report reader to spot check and confirm that the milestone is on track, then the bullets under the milestone need to provide more insight about why we believe the project is on track. E.g. details about work that’s been done but not visible, or details about arrangements that have been made for a lot of work to happen soon.

Updates from last week

This section should be sufficient to answer: What actual work was done? What’s the meat? This section should provide enough detail to let the reader distinguish a scenario where no one did more than a few minutes of easy work in the last week, vs a scenario where two people each put in 10 hours of work.

This section is not the place to put cumulative stats about the project. Cumulative progress can be described under the milestone(s) it applies to.

This section can mention bumps in the road. But if the bumps in the road were exceptions that led to milestone shifts, their main impact would already be tracked in the milestones section.

Other report standards

Everything in the report, especially project and milestone titles, should be understandable to a reader who does not have preexisting context/understanding of the projects.

Advanced Techniques for Project Managers

Next milestone is more than a week away?

When a milestone is more than a week away, the risk of reactive exceptions becomes more costly because when they happen, it means a week of time gets lost. Because of this, milestones should usually be no more than 1 week apart.

If a milestone is listed as taking more than a week:

• If it’s a lower-priority project, and the actual amount of work needed is less than a week, then it’s fine. E.g. maybe the milestone is in one month, because the project owner will probably do nothing for 3 weeks and then works for a few hours on the 4th week, and that’s all it takes to hit the milestone
• If it’s an experienced project owner who has a strong track record of hitting milestones, especially on this or similar projects, then it’s probably okay
• Otherwise, it’s worth setting an incremental milestone that’s one week away or less

Project/milestone owner being unresponsive or difficult to work with?

Again: use smaller, more frequent milestones to make sure the project is on track.

If the project is high enough priority, then schedule multiple meetings and checkpoints during the week to make sure it’s staying on track.

Once you see a pattern that a certain project (or project owner) is consistently succeeding at hitting milestones, you can gradually increase how big and far apart their milestones are, if they want to do so.

That’s it! Let me know if this simple framework helps you get more stuff done with less wasted time.