I've just returned from a three-day very relaxing fishing nirvana that gave me plenty of time to think about todays topic. For the record I did catch two very nice largemouth bass and a bunch of smaller ones I hope to catch again next year. WES: 2, BASS: 0.
Project estimation has to be one of the most difficult areas of project management. I've worked with people who have a standard "6-months" answer. I ask "How long will it take to create 100 jobs?" The answer: "6-months". "Two jobs?" "6-months". Really making progress there...I could probably make this into a Dilbert cartoon.
Project estimation is related to all areas of development, not just datawarehousing. As any of us who have ever spec'd out worked units knows, estimating the time that it takes to accomplish a specific task is easier said than done. It depends on many variables including worker motivation, worker ability, timeline, and difficulty.
Let's start out by determining a unit of work. A unit-of-work, or work package, is the smallest piece of work. For a datawarehouse this might be extracting rows from an Oracle table. A project includes the other jobs (transformation, cleaning, load).
Worker motivation also influences timelines. I think there is a good compromise between being over-motivated and under-motivated. I'd rather have someone between the two extremes on my team eliminating burn-out and boredom. Happy, challenged employees will do much better work than someone bored with work. From my very first job in high school I have continually heard the mantra that I'll call labor shuffling. It's the theory that any one person can do any job in a certain organization. While I believe this is a great idea in theory I am not convinced that it works in practice unless executed to almost impossible precision. Never mind that putting on my economist hat it really bothers me to be operating in a region where we are inefficient.
Ability is difficult to ascertain. Enough said.
Tonight I had a disucssion with an associate regarding some opportunities he is having on a project. He's trying to put together an accurate timeline without having defined milestones. He has dates and estimated project durations for the project but they are mostly a stroke of wishful thinking. I recommended he work out an objective list broken down by work packages then use the PMI formula for estimating project timelines. I'm hoping our discussion helped him out.
Here's the formula PMI uses to estimate projects (I'm a Project Management Professional (PMP) and a member of PMI so I feel it's appropriate to share this here...let me know if you feel otherwise....taken from PMBOK, version 2000)
Program Evaluation and Review Technique - weights activities to determine most likely duration
PERT Weighted Average = Optimisitc + 4 Most Likely + Pessimistic / 6
Let's put this into play thinking of a DW load process. I'll give you the numbers and you figure out the weighted average.
O=5 ML=10 P=15
Time for you to do the math.......don't cheat.
Plugging it into the formula, WA = 5 + 4(10) + 15 / 6 = 60/6 = 10
It's probably going to take 10 days to complete so most likely is correct in this case. Hmmmm, maybe I should pick harder numbers. I think you get the idea.
If there is further interest I'll dive a little deeper into estimation techniques.
This post is a little short on content but my goal is to get you thinking about estimating timelines. Write down the answer to the following question on the same piece of paper you used to figure out the Pert forumla (you did write it down didn't you??) How do you estimate your timelines and is it accurate?