Approaching projects - Part 3

- 12 min read - Text Only

Do you have a project, a skill, a goal you'd like to complete or progress? Are you on your own, lacking leadership and structure, or could use more of it for yourself and your team? Here's what I've discovered works for me as a solo software developer and later as an engineering manager. This is a series of posts, the next post part 4 on preparing for a plan comes next.

In the last post Approaching projects - Part 2, I described exploring the requirements of a story, matching requirements to a theoretical solution, finding dependencies, uncover surprises, and finally on ensuring a solution is feasible. This post will focus on laying out a project's milestones, objectives, and considering risk for each milestone.

Throughout this series of posts I will be using this user story: As a person with money, I want a custom computer desk to fit in a weird spot in my home. With the chosen solution: Build the desk myself.

Milestones and Objectives

The thing about projects is that they involve many tasks. Some tasks are specifically to assemble the deliverables of prior tasks. This of course creates dependencies. No horse carriage without a horse and carriage, right?

Start from the end goal and work backwards, then forwards again with more detail. When a project requires nesting (a project within a project), set bounds on its resources including time and document its acceptance criteria. After the high level plan has been completed, then dive into the nested projects. This approach can be repeated for nested projects. Note that in Approaching projects - Part 1, I do recommend against nested projects. However nested projects are necessary when addressing risk such as We think we can use jointing to solve a large desk surface but we've never done it before. So that's where prototypal projects are involved, to learn and gain confidence about the feasibility and method that should enable a deliverable.

glassy-tears
But, do avoid the temptation to use something new and exciting directly in a production deliverable. Otherwise you're left with a hard to maintain experiment that's hard to replace. Unfortunately this was one of my first mistakes as a manager on an internal product.
We tried a bunch of lambdas, step functions, and a half baked schema in dynamo to solve a complex problem. The developer left and the new developer on another team took four months to fix a single ticket on it. Prototypes are not meant to be extended, they are meant to be learned from.
yelling-at-cloud

Let's return to the table example. The objective is to make a table that fits in a specific unique space. Some projects can have multiple objectives. When negotiating for changes, usually the objective remains the same. Each milestone is tied to at least one objective.

There are a few considerations for the final deliverable.

  • It must fit in the install location
  • It cannot be cut, glued, painted, etc. at the install location
  • It can be assembled at the install location
  • I cannot move a fully assembled desk myself up stairs with two 90 degree bends

This informs me that the final step of this project will be to assemble the components of the desk without any mess. Screwing in some bolts is acceptable. So the final milestone is:

The desk has been assembled and installed at the desired location.
blank-sign
Note that with bolts is not included in the description. While that is what I did, this implementation detail is not important to a stakeholder. Keep milestones free from the detail clutter for stakeholders and sponsors of a project.

An inset bolt holding the table surface to the frame

Now to recap the requirements:

  1. A large flat level surface being 26 inches deep, 72 inches wide and suspended about 30 inches from the floor.
  2. Space to add monitor arm mounts with clamps 4 to 5 inches in depth.
  3. No support beam bars on the very front below the surface
  4. Any support structures should be easy to forget

Let's consider the tangible deliverables that come from the above requirements as it relates to a desk.

  • A Desk surface meeting the required criteria
  • Framing that meets the required criteria
  • An interface to bond the desk surface and the support framing

Going back to the night stand, I used inset machine screws (which are not exactly bolts) and an embedded threaded insert. This will satisfy the interface deliverable without making a mess and can be disassembled later for moving, cleaning, whatever.

For your privacy, this youtube video was not automatically loaded.
Click this area to load an embedded youtube video.

Another milestone will therefore be:

The bonding interface between desk surface and framing is applied and verified prior to installation.

Next, I needed a frame.

This comes with two dependent milestones

The frame has been built and assembled.

Assembled desk frame with banana for scale

The frame has been designed and verified to meet the measurements required.

CAD design of table support structure

notes
Are you noticing a pattern with these milestones? They're written in past-tense where each milestone states its acceptance criteria. Also, they are free from detail clutter, nothing about the exact mechanism. Those details can be changed and negotiated before and during the project, it isn't useful to have mutating criteria in the roadmap.

Lastly, let's talk about the surface.

During my research in Approaching projects - Part 2, I found that I could not use solid core desks like Amazon. I had to negotiate (with myself) an alternative desk surface. But the milestone for this deliverable had not changed.

The desk surface is prepared, it is suitable for use as a computer desk.

Now that's interesting, what makes desk surface suitable for use as a computer desk? Besides holding things on it, it shouldn't get warped over time, it shouldn't give slivers, and so on.

The desk in particular faces a lot of challenges that I'll cover in the next part. But for now suffice it to say creating milestones may be a probe that discovers more requirements.

Jointed desk surface on frame

In particular the desk surface became a nested project with the following requirements:

  • A large flat level surface being 26 inches deep, 72 inches wide
  • It should be sealed so that it does not get warped by moisture
  • It should be beveled along the edges so that it does not cut at the wrists
  • It should look nice

So with all the milestones created and reversed we see the project looks like

  1. The desk surface is prepared, it is suitable for use as a computer desk.
  2. The frame has been designed and verified to meet the measurements required.
  3. The frame has been built and assembled.
  4. The bonding interface between desk surface and framing is applied and verified prior to installation.
  5. The desk has been assembled and installed at the desired location.

As far as risk, the desk surface involves a nested project so that milestone presents the most risk. The other milestones are low risk and predictable.

Assuming this was a commission for someone else (a stakeholder), I can communicate the health of this project as milestones are completed and retain their confidence in my execution of this project. Further, when communicating milestones, include risk in confidence and resources. You may need to negotiate for more resources or for less requirements.

The main takeaways of this post are:

  • Milestones contain high level acceptance criteria.
  • Milestones are tied to tangible deliverables.
  • Some projects can have multiple objectives, milestones are linked to objectives.
  • Work backwards from the end deliverable to create milestones.
  • New requirements may appear when creating milestones, they may become a nested project.
  • Milestones are used to communicate to stakeholders and sponsors the health of a project.

This post is the third of the series, part 4 on preparing for a plan comes next.

excited
You can succeed! Focus on the objective and break down at a high level what it takes to achieve them. Be open to details changing, surprises often come. Plan your ideas around the concepts and deliverables rather than detailed properties of each deliverable. Milestones are tests to build confidence in delivering, each stone crossed is worth celebrating!