I don’t know the secret to accurate software schedule estimation, but I have a pretty good technique that is simple enough for anybody to do. With this technique, you will be able to estimate your software project schedules with the same accuracy as major software development houses, large corporations, and experienced consulting companies.
The process starts with a list of bullet points. This is similar to a “requirements list” but less formal, you can do it as bullets in Word or even individual lines of text in a simple text editor. Each bullet point should be 75 characters or less (a few characters will be added later as you will see).
No matter where you are in the project (early conceptual stages, initial planning stages, or even if development is fully ramped up and in progress) sit down with a blank list and start making single line entries, 75 characters or less, that describe the things that need to happen for the project to be completed.
Don’t limit it to product features, include mundane things like “buy new computer to replace the one that exploded”, and “hire new developers and get cubicles allocated”. As you can see, some of the items will be very specific (”buy new computer”) and some will be very broad (”hire new developers”). Try to keep each line focused on one thing - split “hire new developers and get cubicles allocated” into two items, “hire new developers” and “get cubicles allocated”.
After a while you’ll run out of things to put on the bullet list, or the list will get so long that you’ll begin to shake and cry uncontrollably. When either of these things happen, it’s time to stop.
Now, count the number of bullets. This is the number of days you’ll need until the next phase. When translating this to calendar days, make sure you leave out weekends. You will need the weekends anyway, but don’t include them in this number.
Let’s say you had 30 bullet points. This translates to exactly six weeks. For the next six weeks, work on the items on the bullet point list. When you complete one, put a “+” to the left of it. If you decide not to do one, put a “-” one next to it. For all of the other bullet points, leave them as they are - those are the ones that need to be worked on next. Note that even though we allocated one day per bullet point, this does not mean that each bullet point can or will be done in one day. The actual amount of time it takes to complete each bullet point depends entirely on the resources you have at your disposal. Do the best you can. Some bullet points won’t get done. Don’t worry, we’ve got that covered, as we’ll see in a bit.
Often, you will come across a bullet point that is really more than one task. Let’s say you had a bullet point that originally said “Implement user interface”. When you come upon that one, you won’t be able to just do it as-is. You’ll want to expand it out into some more bullet points. For example, “Implement user interface” might expand out to 50 more bullet points, itemizing the widgets that are needed, the various screens and menus that need to be designed, the visual styles that need to be determined, etc.
When you reach the end of the first phase, you will still have your bullet point list, but it will have been transformed. You need to clean it up at the end of each phase. Go through the list and remove all of the lines with “+” or “-” at the beginning of the line. Those have been addressed and you don’t need to ever think about them again until testing time. There will be quite a few bullet points from the start of Phase 1 that have not yet been addressed or thought about at all. That is ok, leave those on the list.
After you have cleaned out all of the addressed items, scan through the list including the newly expanded bullet points. No doubt some things will occur to you that weren’t on the first bullet point list, and are still not there. Add those to the list. Also, you may see some bullet points that can now be expanded out to more detail. Go ahead and expand those out now. As with Phase 1, keep doing this until you run out of ideas to add to the list, or until you begin to shake and cry uncontrollably.
Now it is time to start Phase 2. Count the number of bullet points that are on your cleaned up list and allocate one day per bullet point again. Let’s say you have 120 items on your list now. That is 24 weeks. Start into the new bullet point list exactly as you did with Phase 1. When an item is completed, mark it with a “+”. If you decide an item is not needed or will not be done, mark it with a “-”. If you find a bullet point that needs added detail, expand it into a new list of more detailed bullet points.
As you can probably tell, Phase 2 follows the exact same methodology as Phase 1. In fact, every phase follows this same approach. That is the beauty of this technique. Once you know the basic procedure, you know the whole methodology, and no special software is needed. In fact, this entire methodology can be implemented with a pad of paper and a pencil.
Eventually, the product will need to ship. The forces that determine the ship date of a product are typically beyond anybody’s control, no matter how powerful any individual person may be. You will typically have some early warning of when this date is, and you will need to allocate some time to fix any problems that exist with the software. Do the best you can. No doubt you’ll still be trying to implement items off your bullet point list during this time, so technically any testing you do will be invalid. Plan for some sort of automatic online updating system for the software after it ships.
And that’s about it! Unfortunately, this method doesn’t tell you the full schedule of the project on day 1. All you can say on Day 1 is when Phase 2 will start, and due to the unpretictability of each bullet point (some happen quickly, but most take longer than expected, and almost all of them expand into more bullet points), knowing when Phase 2 starts isn’t really much help. But it’s the best you can do, and it’s about as good as the best professionals can do. In fact, it’s better than a schedule that sets very specific dates in stone, because those kinds of schedules just make everyone shake and cry uncontrollably when they realize there is no way those dates can be met. With the bullet point approach, the shake-and-cry periods are planned out ahead of time and are expected, and so they are easier to deal with.
Am I serious? I started writing this partially to be funny, and partially to put down in words the actual approach that I use for software development. There are projects that I can schedule very well, but those projects are basically repeats of other projects I have done, using well understood technology and doing the exact same tasks as a very similar project that has already been successfully completed.
As the world of software matures, the number of repeat projects increases - this is the software industry’s version of building strip malls. If you’ve been doing it for a while, you know how long it takes to lay the grade, roll the pavement, and slap together the strip of shops. But often in software, there is some innovation required, so the project is more like building a spaceship that can also drive at highway speeds and travel waterways like a motorboat, with an outer skin that can display high resolution full color images and a life support system that includes the capability to manufacture cotton candy from sugar synthesized from molecules formed by shooting lasers at particles being accelerated in a 5-mile radius loop. These types of projects tend to be difficult to schedule, but the bullet-point list will get you as close as you can get to something reliable.
Oh, and we’re gonna need a killer stereo system in that thing. Add it to the list.
0 Responses to “Software Schedule Estimation Via Bullet Points”