Approaching projects - Part 1- 10 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, part 2 on discovery and feasibility comes next.
What are you working with?
First it is important to classify what you're doing. Are you developing a skill to be used again later? Do you have a deliverable in mind? Is it a product to be used by someone else? What kind of lifetime will it have?
These questions apply to more than just delivering software. Here's some real examples I've gone through, start with a user story.
As a person with money, I want a custom computer desk to fit in a weird spot in my home.
While chasing to satisfy one story, more may spawn.
As a hobbyist wood worker, I want more outlets in my garage so I can avoid extension cables which I tripped on.
Consider these as later projects and avoid recursing into solving rough edges. Don't be the engineer who gets distracted fixing nested dependencies. This is different from shifting priorities because of a bigger problem.
But let's get back to the the custom computer desk. This is a physical deliverable for myself with a long lifetime.
So the desk story could have been solved in a few ways.
- Commission a custom desk from somewhere
- Build the desk myself
- Use the weird spot for a different purpose
There's several parallels here in the software business, likely others too.
- Do you go with a Software-as-a-Service to solve the problem?
- Do you aquire a technology from a company or buy the whole company?
- Do you outsource it to a contractor but own the technology?
- Do you invest in your own team to build the technology?
- Do you prioritize other things and shelve the problem?
Anyway, I chose to build the desk myself, this forced me to invest in my own skillset to satisfy the story. Thus an acceptable but blocking user story is born:
As an unskilled person, I need to gain the skills to build an acceptable table.
This is an intangible deliverable for myself with a long lifetime.
Intangible deliverables are different. How is such a thing delivered, considered done, accepted and satisfied? Think back to school, public education, whatever you went through. You took tests. Each test is a tangible deliverable.
So let's consider, what are tests for? In my eyes, tests are a controlled simulation of a later and greater tangible deliverable. That's a bit wordy, let's think of an example. The greater tangible deliverable is a computer desk. What properties does a computer desk have? It's got dimensions friendly for a screen, keyboard, mouse, speakers, cups, and snake figurines. Lots of things. What about a useful prototype? It needs to be a level surface that things can be put on at an accessible height. Now what's a useful object that matches this abstract description? A night stand!
With a tangible test in mind for developing a skillset to make a computer desk, we now have another user story:
As a person learning a skill, I need to make a night stand which is considered disposable
Disposable? That's right, a learning prototype isn't production worthy, and that's okay. This expectation must be clear before and after completion. The night stand I made looks okay, but I may not keep it if I move.
This is a physical deliverable for myself with a short lifetime.
Further, this test was a milestone for an intangible deliverable. In a way it was like but not exactly a milestone for the tangible deliverable of making a computer desk. However because it does not directly contribute to tangibly delivering the computer desk, it can only be used to assert confidence in the dependent story of making the computer desk.
Here's the takeaways from what I described above:
- Projects can depend on other projects. To a stakeholder, nested projects may be an instrument to gauge confidence on the delivery of the primary project.
- Projects with the goal to develop a skill should be considered an investment. To measure the progress of that project, tests should be performed with tangible results.
- The deliverable may be intangible, include tangible tests to verify satisfaction.
- Consider the lifetime of a product's deliverable. Short term deliverables exist to set up confidence in long term deliverables.
- Identity project scope, resist scope creep, and prioritize satisfying the primary project.
Bonus take away! Prototypes may not be production ready, but they can still be useful. I can go back and look at what I did on this tangible desk and remember what I did to solve which problems. It is a model that I can reverse engineer and treat as a mnemonic to remember the concepts applied to produce a useful tangible tool. Don't throw out your prototypes, reference and learn from them. Use them to teach your peers and reports about what you learned. It's easier to digest concepts with smaller scopes.
This post is the first of the series, part 2 on discovery and feasibility comes next.