Christopher and Valerie Talk Estimates
Having a great conversation with Val the C# Gal, thought I'd share.
So, Christopher . . . Not to back you into a corner, but if you had your druthers, how small would you like projects broken up? A month of requirements gathering, followed by a month of spec writing, followed by development, for example? Or maybe a week of each followed by a release? I am interested to hear what has worked best for you.
No, no - feel free to back me into a corner. It's a good way to get honest answers.
That said, my preference is to let each project tell me what kind of iteration period it needs. Believe me, I know how hippy-dippy that sounds. But it's honest. For example, once I complete a high-level set of requirements - the proverbial view from 10,000 feet - and it's time to start drilling down, I'm not likely to say "let's write spec for a month", but I am likely to say "let's spec out the garthok-gnarfling feature first. And if the client agrees that it makes business sense to do so, and I have a high degree of confidence that garthok-gnarfling won't break anything else that I need to build, I'll test, document and deliver that garthok-gnarfling feature by itself so it can be put to use while the rest of the system is being built.
Mind you, this is just my personal preference - it is very important to me to get working product in the hands of the client. I think it helps the client feel as though the project is real, not some intangible, abstract thing that will be delivered Q3 of 200x. However, not every project lends itself to such tight iterations - usually two or three or more features will be interdependent in such a way that delivering any single one by itself is pointless, and this is OK. I'm not a fan of trying to force reality to fit my own prejudices.
In general, some combinations of the client, the market, the business process, and politics will dictate what kind of iteration is needed for a project. For example, I recently did an ASP project that had me delivering pages every week. A few years back, I did a project for Exxon-Mobil that had me delivering product every 6 months for a couple of years. Both projects were successful according to the performance measures set out at each project's kick-off meeting, so it's hard to say for certain that either approach is "better". Each project got the approach it demanded.
I realize that this does not answer your questions directly - you want a concrete "x is better than y" answer. Problem is, I don't think I have one for you. But I can say this:
- In general, shorter cycles of design/develop/test/release seem to work well
- In general, design-it-all, build-it-all, test-it-all, deploy-it-all projects are more problem-prone
- In general, prioritizing the most useful and least interdependent features leads to shorter initial delivery times
- In general, most projects have artificially short schedules anyway, so don't be shy about putting your foot down the next time someone hands you an estimate that is obviously inappropriate.
In other words - it depends. ;)
Is It A Goal, or Is It A Wish?
In my self-appointed role as an effectiveness fanatic, I often ponder the process of setting goals for a project, or for my personal life. Setting goals is tough.
"Wait a minute" you think. "What's tough about goal setting? You state a desired outcome, and BAM! You have your goal. Right?"
Wrong. If all you have is a stated outcome, you have a wish. Not a goal.
Let's think about this from (surprise!) a software development standpoint. Suppose a client calls me up and asks for an application that will manage their bonus compensation process. Since I've done that sort of work before, I could plop right down and put together a pretty handy application that does just that. But will the application I put together be the same application the client saw in his head when he asked for it? Probably not. The reason is that simply stating that you want a bonus compensation management system does mean that getting a bonus compensation management system is a goal of yours. At this point, it is simply a desire - a wish.
How do we move this client request closer to the realm of "goal" and farther from the realm of "wish"? Well, for starters we can clarify the request - what exactly IS a bonus compensation management system, anyway? Does it need to store stock grants? Will it be storing full employee information about each person receiving bonuses, or just their SSNs? Will it print checks, or will it need to export the financial data to Great Plains? I can think of at least 100 questions that could be used to clarify the original request. The problem with a client asking a developer for a "bonus compensation management system" is that it is not measurable - you have no mutually agreed-upon way to tell if you've built a management system for a bonus compensation process or a balloon ranch on Mars. So the first step in having a goal is to make sure it is well-defined enough to be measurable. In software terms, this would be a requirements document.
Now that we've got a measurable desired outcome, the next thing to do is figure out when it can/should be accomplished. Features dictate dates. Hopefully the process of clarifying things into measurable terms has provided sufficient detail to make an estimate - if not, more analysis can be done to determine a deadline. If you're working on one of those projects that was promised for delivery on x date before anybody even knew what they were actually building, then I feel for you. I've been there and it's not fun. Luckily, this item is being written based on a "perfect world" assumption, and in a perfect world you could look at what is required of you first, THEN provide a realistic completion date. So the next step toward a goal is a deadline. How much time is needed to make your measurable stated outcome a reality?
Now it's time to drill down a little deeper. We know what we want to accomplish, and we know enough to set a realistic date for accomplishing it. The final piece of the puzzle is to figure out how to pull it off. What things need to happen - and in what order - in order to go from having what we have now to having what we want to have, within the set time frame? In software terms, we need a project plan. Part of this will be taken care of by the analysis done to make sure we can measure our relative success or failure - it's nice to have that kind of overlap. More work will need to be done to plot it all out like a project schedule. Step 1: Gnarfle the garthok. Step 2: Foo the bar. Step 3 . . . And so on. What actions have to be taken to move us closer to the goal each day, arriving (more or less) precisely at our goal on (more or less) precisely the date we wanted to arrive there?
This is nothing groundbreaking, but it IS frequently overlooked. Everyone states desires - in fact, we do it institutionally in the form of New Year Resolutions. But to take your desire - whether it is to write a bonus management system or to lose 100 pounds - and turn it into a goal, it must:
- Be measurable
- Have a deadline
- Have clear steps to make it happen
Think about your projects. Think about your life in general, for that matter. Are you putting sufficient thought into things to make them concrete goals? I can tell you from experience that wishes do not translate into good software, a slimmer waistline, more money, etc. But goals do.
While you're thinking about it, head over to GoalBox.com and publicly commit to some resolutions for 2005. Make them specific and give them dates! ;)
Dell Complicates Life for Home Businesses
I am fortunate in that I can run my business from my home. I have a crack team of developers spread out all over the country and I can manage it all from here. But working from home just got a little less convenient for guys like me.
A few months ago I ordered a new Dell Precision and had it delivered to a mailbox I rent for business use - I don't want business mail intermingling with personal mail, and I definitely don't want the UPS or FedEx truck coming through the neighborhood constantly. Delivery was made and I was pleased. I am a big fan of Dell.
Fast forward to a couple of weeks ago. I ordered an additional LCD from Dell to replace the CRT I had been using as a second monitor. Imagine my surprise when the Dell representative told me that they could not deliver to my mailbox address! Only three short months ago, they had delivered an entire system just fine. The fellow from Dell explained that there had been enough cases of fraud for the company to institute a policy of not shipping to mailbox addresses anymore unless the product was paid for in full at the time of order. I was using my Dell Financial account, therefore I was told that they had to ship directly to my home.
Now, I can see the logic behind this - nobody likes to be stolen from, and it is only prudent to take steps to prevent it. But if Dell truly will not ship to a mailbox address such as the UPS store, Kinko's, etc. then I can think of a lot of home business operators who are going to be feeling the pinch. What happens to home business operators who live in areas that have laws regarding the type and frequency of business deliveries that are allowed at one's residence? What happens to home business owners (like myself) who simply don't want the FedEx or UPS truck rumbling up to their door?
I have a hard time getting mad at Dell for trying to protect themselves, but at the same time, I find myself thinking that this could be a huge PITA for many home business operators.
It is humorous to note that my LCD ended up being delivered to my mailbox anyway. What's the story, Dell?
