It's also, unfortunately, what leads to problems. Let's say, for example, you have an implementation for a customer that calls for developing five pieces of functionality. You put in a development task and appropriate testing tasks for each piece; then you put in a deployment task at the end. That should be enough for the development piece, right? You get your estimates from development - four tasks at four hours each, and one larger piece - it's going to take a week. Fine! You move on.
Fast forward a month. The one-week task took three weeks. Testing has been a pain. It's gone back for corrections five times now. Your deadline is completely shot, and no one can give you a well-defined date on when you'll be done.
What went wrong? Was the original estimate bad?
I would argue that the original estimating method was bad.
Modern software development isn't like it was in the days of yore. There are no monolithic programs (for the most part) anymore that it takes weeks and weeks to write the single thing, with no steps in between. In reality, that one week task described above probably consists of a number of sub-tasks, like:
- set up database tables
- create object X
- build method 1
- build method 2
- etc
Obviously, you do not want to micro-manage. You also don't want to overdo task list management. I would argue, however, that any given task should span no more than one day in your plan. If it does, then you need to break it down into sub-tasks. Why do this?
1. When breaking the task down into sub-tasks, often your team member performing the task will become more accurate with the estimates
2. You can more effectively isolate trouble tasks to explain them and report on them. How many times have you had this discussion: You: "Bob is running over on development. He's a week overdue on item X." Exec: "What part is he stuck on?" You: "Item X." Exec: "What does that mean? Can we get him help? How much more does he have to go?" You: "Uhh..."
3. You can actually get your team members help. Staying with the developer example: Is the developer overrunning on the database work? Get a DBA to help them. Are they stuck on a method in one of their objects? Maybe another developer can complete another objects involved in the functionality to get you back on track.
4. You can plan around day-to-day operations vastly more easily. If someone has a two-hour ops meeting on Thursday morning, and a conference call that evening, you can reliably say that they probably won't complete their day-long task that day. Push the timeline out one day. Very simple! A quick glance at your team members' calendars tells you, and them, everything they need to know.
5. Imagine how happy your team members will be when they figure out that they have a goal of one item per day. Come in to work, do this by end of day. No planning, no juggling, no balancing. You complete your task and move to the next. Simple!
6. You create stopping points. If team member X has to be pulled off the project for an operational thing for two days, you can simply insert that in the midst of a major task by dropping it between the subtasks. Simple and elegant!
Getting the right amount of detail lets you follow up the right amount, and estimate the right amount. If a task consists of five day-long sub-tasks, then when three of them are complete, you're somewhere between 60 and 80% complete. Once your team members learn that they are suddenly not facing the "what percentage are you done?" question nearly as often, they'll prefer your method as well.
Some team members aren't going to like this method, because they do have to think through the details. They will feel it is micromanagement. It isn't. Being asked to state at the end of the day if you finished what you started out to do that day is not a big deal. I recommend that you sit down with them and explain the benefits of this - they have one item to report to you, a simple yes or no, at end of day each day. Project status meetings become simple or non-existent. They can get help when they need it. Sell it however you must, but embrace this method. Your project plans may get longer, but believe me, they'll get more accurate as well.
Don't forget to leave your comments below
Stacey Douglas is currently the Director of Software Development for NASBA and resides in Nashville, TN. In the past, Stacey has been a developer, project manager, business analyst, sysadmin, and all points in IT in between. You can learn more about Stacey at his blog, undocumentedfeatures.com, and his website, staceydouglas.com.
Comments