Matt Blair

Matt Blair

I read that you learn more from a poor example than from a correct one. I don't believe this but that means my site will be a success.

3-Minute Read

Incident Review

Note: This is a series of project planning talks I gave my team.

So you’ve got yourself a project

A project (and a ticket) is a placeholder for a conversation. No matter if a ticket is super detailed or vague on what it wants, the best way to do good work is to figure out a few things about the work you’ve been given.

Get Comfortable

Pre-planning for any project should begin FAR before the actual work.

  1. If you’re working on maintaining/updating an unfamiliar code base, take some time to get familiar
  2. Set up a local environment to test and try things out
  3. You won’t be effective if you don’t understand the current system

Identity your stakeholders

You’ll most likely need to talk to your stakeholders to figure out the true nature of the work you’ve been assigned.

Your stakeholder could be someone on the team. Your project could have several stakeholders, and not all of them will be involved in every detail of the project. Project stakeholders include

  • the end-users of the product
  • the company and its leaders
  • the team working directly on the project

What’s the goal you’re trying to accomplish?

If your project or goal is clear, great! Sometimes though, a big project is hidden inside of a small task.

Sometimes tickets don’t describe the problem they’re trying to solve or the feature they want, instead they describe a series of steps to accomplish something.

When you have a ticket that is prescriptive in how to solve something but the problem is vague, it is smart to ask your stakeholders what they’re trying to accomplish. Sometimes what the ticket describes and what should be built are two entirely different things, and only a conversation will figure that out.

Once you figure out what the real problem is, look to solve that. Don’t just follow a list of prescriptive steps that don’t make sense.

What’s the scope of the project?

Once you know the project goals, you should define ​the scope. By defining the scope, you can begin to show what the project’s goal or finished product will look like at the end. If the scope isn’t defined, it can get expanded throughout the project and lead to overruns, missed deadlines, and frustrated stakeholders.

It’s important as requirements come in to figure out what you’re going to tackle and what is not part of the project scope. Defining the scope can get the entire team on the same page at the onset.

What are the milestones for the project?

The key achievements for a project are called milestones. They represent the big components of work on a project.

Once you understand who your stakeholders are and what the scope of the project is, you should start dividing your project into small deliverable milestones.

Having a clear roadmap of your milestones can be a great help when things get unorganized or new requests / features / changes come in.

Recent Posts



This theme was developed for Hugo.