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 has one primary owner. The owner is accountable for completing the project, according to its acceptance criteria, by the due date.


Commissioning a New Project

  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


  • 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.


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

  • 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

Handling an exception

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

Projects Report Format


  • [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


  • 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 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

Advanced Techniques for Project Managers

Next milestone is more than a week away?

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?

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.

Founder/CEO of Relationship Hero