Approaching projects - Part 9

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.

Wrapping up

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.

You know that meme where developers have double-digits in side projects, and they start looking at a new one before finishing the current one?

It's not just you. Businesses exhibit this too. Here's an example. It starts with a developer giving one day's notice.

Of course, one day to hand off a project they started a month ago is not enough, in addition to their contributions to a home grown ORM and caching system that still has problems today four years later. This project allowed me to be creative, to stretch and learn, to find out what does and does not work, and to make something I've been proud of.

The first thing I did was throw out this developer's code. That code was experimental and did not meet expectations. Then I tried this fancy thing called serverless with lambdas and the like. Suddenly dynamo rate limits hit and wow this kinda doesn't make sense anymore. The experience I gained on this project has shaped and influenced micro service and out-of-monolith development since.

We not only launch on time, we launch before anyone else does in this space. The product's usage grows. It becomes 20-35% of the company's revenue in months. It's so wildly successful that I want to make it better.

But instead, I have to work on PCI compliance. Then the next fire. This cycle repeats.

Only two years later after internal drift resulted in enough errors and lost enough projected revenue did my present employer finally decide to allocate someone to it again.

Wait, so they had more revenue coming through this one thing than another revenue source relying upon two full time engineers and had no one allocated to maintain my work for literally years?

Yes. And I have many opinions on this. I think my interests would have been considered had I done what I propose below.

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?

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.

See that little black circle there with USB ports? That power module's embedded USB transformer was poorly made. It is gone now.

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

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.

I really learned a lot from this project a year ago. Sure, there were wasted materials too and none of this includes the cost of experiments (which were trivial in resource consumption). I've since used what I learned on other projects, such as bookshelves for manga.

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.

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.

You can succeed! You can deliver great things. Your last chance to up-sell the project is upon delivery. Capturing this final summary can help you sell yourself for the next great thing you do! And maybe there will be a to be continued...