Approaching projects - Part 2

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, part 3 on milestones and objectives comes next.

In the last post Approaching projects - Part 1, I introduced a way to classify what your project is and some guidance on rejecting scope creep. This post will focus on identifying the properties that satisfy a solution to a problem, and verifying if the solution is a good fit to the story.

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.

Discovery and Feasibility

First, if you're leading a project, don't choose a high level solution like build it yourself and hand it off to someone else to get from start to finish. Take the time to understand what the solution entails. Some solutions may not be feasible. It's best to catch poor solutions before sinking significant resources into them. Another thing, if you're doing the project by yourself then you're also leading the project. Ensuring the solution fits the story and is feasible is your responsibility.

High level project handoff is reserved for C*Os or generals. Their job is to provide vision and focus across their reports. Another responsibility in that position is to be open for feedback and negotiation! Delegation comes with handing negotiating power to those delegated to.

If the CTO comes to you and says do this thing, ask for the story, find the why upfront. You may want to negotiate a better solution. I've been burned by not finding out the story until requesting the effort be cancelled. The solution requested was not feasible with our resources. It left a bad mark on the engineer tasked with the project. Thankfully an opportune moment came to redeem their standing.

Start top down with the needs of the story, determine its elements, dependencies, and so on. Consider these as requirements against the proposed solution. For my computer desk story, these elements were as follows:

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

For the first part the desk surface, I first considered a door. Yes a door. I heard that amazon did this back in the day.

Amazon News

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

From Scrappy DIY Desk to Amazon Icon | Amazon News Monday, Jan 9, 2023

So I went to the hardware store and looked at all the doors! Hollow doors are the thing these days apparently, with unsuitable cut-to-size properties. The least hollow doors were all 3D patterned and so no doors were feasible as a desk surface.

Feasibility research is a thing. It isn't free, account for it in your project timelines.

I considered this, so I backtracked to what I did for night stand. The night stand was a model to learn what makes a desk, specifically it included support structures and using edge joining to create a solid continuous surface. However the night stand used smaller planks and I used a cheap sander to get things closer for joining. Then to join the planks, I used wood glue and pocket holes to keep it together as the glue cured. Unfortunately I could not repeat merely sanding with confidence on larger planks so I invested in some new equipment: a jointer.

At this point I had discovered a dependency I needed to satisfy to make this project feasible. In order to join planks of sufficient size to make a table, I needed a jointer.

With several youtube videos in hand and the right equipment ordered, I felt I was prepared for the first requirement. Therefore that aspect was marked as feasible and I moved on.

The next requirement! Well it wasn't all that hard. I just had to account for it in the design as I made the support structures. I kept note of it when I did the design.

The third one, first why I didn't want any support structure in the front: because sometimes my chair and legs will be so close to the desk that I didn't want them brushing or hitting the table. Now onto the next part: are support beam bars in the middle acceptable? Given my knees are always angled down, yes I won't hit the desk if there's beams in the middle, assuming they are shallow.

As I did the design, I made sure that the frame would not wobble by using angled cross supports. Further, I kept it simple by only using 2x4 (nominally 1.5x3.5 inches) wood segments less than 8 ft. (I couldn't fit longer into my vehicle.)

This was performed in CAD with measurements accounted for.

While I made this in AutoDesk Fusion360, when it was still freely licensed for hobbyists to use for non commercial projects, I tried to also make it parameterized in case I wished to make other frames in the future. Don't try this on a final product for the first time... Stick to what you already know and save experimenting for later. Reverting weirdness encountered after shifting parameters around (and breaking the model entirely) was distressing.

The next requirement, support structures should be easy to forget. What's easily missed in the shadows under a desk? Black.

So my last requirement was satisfied with the darkest matte black paint I could get at the hardware store.

I goofed this up a little by not finding a matte clear coat, so it came out a bit shiny. Oh well, I learned!

The main takeaways of this post are:

• Collect the fine requirements that satisfy the story. These will be used to verify feasibility of a solution.
• Address each requirement and discover any dependencies that are present in the solution. Account for these dependencies.
• Some requirements may be bundled into the same step as another in the solution. Make note of this as detailed stories are made.
• Question the solution and make sure that it fulfills the story with the resources you can provide.

This post is the second of the series, part 3 on milestones and objectives comes next.

You can succeed! Take the time to simulate the solution, consider the details in each component that fulfills a requirement. Some will introduce dependencies, these should be documented and assessed. If you can't afford something (in any resource and that includes time) then begin negotiating with solution.