Approaching projects - Part 3
- 12 min read - Text OnlyDo 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.
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.
Now to recap the requirements:
- A large flat level surface being 26 inches deep, 72 inches wide and suspended about 30 inches from the floor.
- Space to add monitor arm mounts with clamps 4 to 5 inches in depth.
- No support beam bars on the very front below the surface
- 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.
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.
The frame has been designed and verified to meet the measurements required.
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.
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
- The desk surface is prepared, it is suitable for use as a computer desk.
- The frame has been designed and verified to meet the measurements required.
- The frame has been built and assembled.
- The bonding interface between desk surface and framing is applied and verified prior to installation.
- 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.