In my last post, I talked about how I came to the idea of applying proper project management principles to my amateur radio hobby to add focus. It was a great idea, but I’d forgotten just how much leg work there is in proper project management. Mission statements, project definition documents, deliverable identification, scope of work documents, risk assessments… it goes on and on and that’s all stuff that happens before you even start work. I’ve re-learned that being a project manager is something like being a Catholic or a Mormon. There is always more you should do than you ever can do so you always feel guilty about missing something. I suspect that’s the way upper management gets more out of them. Any conscientious person in that role will flog himself trying to keep up. Now I don’t want my hobby to be like this. If all it is is a bunch of “you have to do this” tasks, I’ll never do it. So I’ve come up with a model that I think works, will help me focus my efforts, and will keep things fun.
A project hierarchy acts almost like its own scope document by channelling the right efforts into the right project
First of all, I’ve adopted a hierarchical organization. There are a lot of aspects to ham radio, and I don’t want any one project to be over-broad, or else I’ll just end up scattering my efforts. Again. At the top I have the overall “super-project”, The VA1DER Project. Under it will be categories like HF and VHF. Under those will be specific projects to acquire and refurbish hardware, build antennas, etc. As noted above, I could bury myself in work with all the projects and sub-projects. There is good management, and there is ridiculous make-work. What I want to do is focus myself, so each sub-project will get one framework document that contains:
- A project overview.
- As mission statement. They are all going to get one. I found creating the initial one very helpful, and I want to continue this.
- A statement showing how the project fits into the parent’s mission. Each sub-project, no matter how far down it is nested in the hierarchy, will have to conform to its own and every higher level parent project’s mission statement. This is to combat project creep. Otherwise it would be too easy to slowly creep away from the initial mission statement.
- Current progress.
- Lessons learned. What I’ve done wrong or right along the way so hopefully other people starting out can benefit from my mistakes.
One document per sub-project. This will keep me focused without burying me in paperwork. I could have added a scope-of-work document, but I realized that the way I’ve organized it hierarchically is really a scope limitation mechanism. The entire organization is really the scope definition and control.
That’s it. That’s all. Nothing else, unless I need it to stay organized. I can likely stage the work without a Gantt chart, and being both manager and sponsor, I don’t need change management. But if I do end up doing something really complicated, there’s nothing saying I can’t break out extra tools as required.
I’ll be maintaining this all on the site here. Each project definition will be its own page. I have to start by back-documenting what I did prior to adopting this model, so you’ll see pages starting to appear soon. Back documenting the case for work already done is, well, cheating, but if I’m honest when I do it, it will be a good way to shed some hindsight on what I’ve done and see how it measures up to the scrutiny of the process I’m building. More on that as it comes.