Approaching projects - Part 9- 13 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 10 on retrospectives comes next.
In the last post Approaching projects - Part 8, I described what to do while the project is being developed and implemented, how to cultivate and curate the plan and respond to changes. This post will focus on applying the last touches and a few clerical tasks.
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.
It's done, it's out, it's being used, it's in production and the stakeholders are optimistic. There's no requests to shut down, revert, or back out. The project appears to have been a success. Let's wrap this up.
There's a chance that a few rough edges will be smoothed, but largely all significant commitments are delivered and few resources and little interest remains in doing more. What are your rough edges? What are the end user's rough edges? What are the consequences of not doing anything more? What's the burden of smoothing each rough edge?
If you are emotionally attached to the project's longevity, this is your last chance to convince the sponsor some final touches are needed. This part occurs after you can be pulled off a project and sent elsewhere and the stakeholder still be satisfied.
At this point, consider everything left in the backlog optional, not guaranteed, and likely to be forgotten. In fact, you (even as a project manager) may be pressured into closing the tasks as WON'T FIX or INVALID.
With one mile left in your budget, where will you make a difference?
Assuming you do want to do that last touch, here's what I recommend as an approach. Check over each deliverable and come up with some means to measure some things about it, consider using the ICE Scoring Model. With one choice, what will you choose? Will you have the opportunity to improve a workaround?
|Issue or Desire
|Router mistake left a gauge in the table
|Power module makes high pitched noise
|Better cable routing options
These scores are of course subjective, both to you as a developer and to the stakeholder. To me, a high pitched noise would deter me from a physical location. Addressing this by removing it is both easy and impactful. I as the stakeholder for this desk am also reasonably confident a replacement (a power strip or a battery backup) will not have a high pitched noise.
Recall in the last post, I described workarounds. The choices you make here will feel like workarounds but with a lifetime that lasts as long as the deliverable. Make your choice count.
This final change, removing the power module, improved my satisfaction with the deliverable.
Take a moment to record expenses, be it time, money, whatever. The numbers below are based on current prices, I don't have the receipts anymore
|Line Item Cost
|Red Oak Planks
|Pine 2x4 at 8'
|Machine Screw pack
|Threaded Wood Insert
|Sanding Pads pack
|Pocket Hole Screws Pack
|Pneumatic Nail Gun with some nails
|Plunge Circular Saw with guide rail
Some of these line items are reusable (e.g. the nail gun, plunge saw, jointer) but until they are re-used, the cost of this table is impressive. I have no idea how many hours I put into it.
The last thing to do really is to take that backlog and make a summary. Do a final observation of the deliverables and make note of the things working well and what’s not working well. This can probably fit in a paragraph or two. This isn’t a retrospective, it’s about capturing the current perspective before you switch away to newer things and forget.
So, what’s my backlog for the table? Scroll up to the ICE table above to see. There’s a gauge I could repair with some wood filler and epoxy, I could add some hooks and holes for more cable routing.
But rather than focus on solutions, instead document stories that focus on the problem. There’s a gauge on the side and it is ugly to me. Cables get tangled and look messy. The negatives sound like whining, this is okay. These stories are about encoding both the content and perception of the problem to the stakeholder.
Then the positives! The curve on the table surface is comfortable. The reflective look on top is delightful. The space behind to mount monitor stands was perfect. And the neutrals: The frame only coincidentally fit a filing cabinet below, that could have been considered in the design. The bonding interface works and it isn't in the way.
Document these findings, they may be useful in directing a retrospective and prompt future additions to a delivered project.
|Curve on table surface is comfortable
|The reflective coating is nice
|Monitor stand mounting worked
|Filing cabinet wasn't planned for but fits
|Bonding interface works
|A gauge is on the side and it is ugly
|Cables get tangled and look messy
The main takeaways of this post are:
- Once delivered, the project may only have room for one last impactful change
- Use a scoring technique like the ICE scoring model to prioritize final changes
- The backlog for this project may be indefinitely suspended
- Account for resources consumed in this project
- Document sentiments and areas of concern on the deliverable
This post is the ninth of the series, part 10 on retrospectives comes next.