A Hard Lesson Learned17 Oct 2011 in Work
For a few months now, I've been working on a side project for a local girl's volleyball club. While the people I'm working with are very nice, this whole project has been a lesson in how bad of a businessman/project manager I am. I'm struggling with whether this is a sign I should stop taking on these side projects, or if its a sign that I really need to pay more attention to the business side of things. If nothing else, I hope this will serve as a warning to others on what not to do.
Lesson One: It's Going to Take Longer Than You Think
No matter how much time you think it's going to take, you're likely underestimating it. When I first got involved in this project, I expected it to be about 100 hours of work. I stopped counting the actual hours invested on this project at 200 because it just got to be too much to think about. There are components to this project that are similar to, but not exactly the same as, tasks I had completed before. However, these tasks turned out to be far more involved than I had anticipated, and so my initial estimates were quite a bit off.
Lesson Two: Have a Detailed Statement of Work
At some point, there's going to be a difference in interpretation of some part of the project design. No specification can be so complete as to eliminate every possible point of contention. However, the more detailed the original statement of work is, the smaller these issues should be. Having a very detailed statement of work allows both parties involved to have a clear understanding of what is expected, and prevents the last minute "it was supposed to..." statements.
Lesson Three: Have a Contract
I'm not saying you need some behemoth document that requires a $150/hr lawyer to understand, but there needs to be a legally binding document that includes when you will deliver the work, in what format, how much you will be paid, and when you will receive payments. Having this makes sure there's no surprises for either party involved -- you know your deadlines and when and how much you will be paid. The customer knows when they will receive what they're paying for and how much that is.
Lesson Four: Have a Change Request Process
There will be changes during the development or delivery process. It's going to happen, and you can't change that. What you can have is a process to deal with it. The customer needs to know what costs they're incurring by asking for changes and whether or not the changes will affect the delivery date. You need to build a revised detailed spec with the new changes in it.
The Bottom Line
I hate paperwork, meetings, and managing. However, it turns out that, to an extent, those may fit in the category of "necessary evils." If you read through the list of lessons above, you can probably imagine the mistakes I feel I've made on this project. I've unfortunately lost quite a bit to this project, including most of my weekends for the past 3 months and a LOT of sleep. Hopefully, I'll learn how to do things the right way -- and maybe you won't have to learn this lesson the hard way!