Submitted by timburgan on
in
Forums
Hello
My boss and Senior Executives want to know estimates of how long each product will to take to be build. These will be used to track the project's progress and to plan resourcing.
My estimates are based on gut feel. I go about it by figuring out the components that need to be built, their complexity and estimating from there.
I want there to be historical data on how long it takes for these components to be built, so that I have actual data to go on next time round.
Is it reasonable to ask my directs to keep track of time they spend building each component?
As a side note - there is a mandatory requirement for all IT staff to record time against enterprise-endorsed projects, using Microsoft Project Server. This is good on the surface, but I find it unrealistic to expect that 100% of work time can be assigned to an enterprise project. In addition, the way it's setup, the lowest level time can be entered at is at the product level (i.e. Product A, Product B, Product C), which won't give me the component level data I want. Plus, my boss and I don't get visibility of the data submitted by my directs/contractors anyway. It goes directly to the Senior Executive's program management/support area.
I'm very interested in any other approach to this. Personally, I started tracking my time using this paper approach (http://davidseah.com/blog/2010/01/emergent-task-timer-updates/), using a new sheet per day. At the end of the week, I sum the totals per product to enter that into Microsoft Project for the Senior Exec, whist still having a component-level record for the next time I need to do an estimate.
Can I ask my directs to do similar: Submit to me their Totals by Product Component for the previous week? Shall I do that in one-on-one's? I don't feel that it's too much of a burden for them to record. I suspect there will be pushback however.
Thanks - I look forward to any feedback and advice.
You can ask your directs to do anything you want...
... although whether they'll do it or not is a separate matter.
Introducing change is always a bit of a problem, especially when you're asking people to do something uninteresting or perceived as "bureaucratic". Myself, I'm in the process of introducing estimation and deadline setting to my team of developers, and while it's going well, it isn't without its challenges.
People prefer to know *why* something is happening. If you explain that you're trying to improve your ability to provide estimates grounded in reality for upcoming projects, you'll tend to have a lot less pushback. Even better is if you're willing to be flexible in how people collect the data, as long as its reported to you in the form you need to do your job. For example, if you mandate that everyone use your paper-based system then put it into a spreadsheet to e-mail to you, people will be a lot less receptive than if you explain that you need the numbers in a spreadsheet, and you've been using this paper-based method, but if people want to experiment with other ideas (like a time tracker on the computer, or whatever) you're fine with that -- as long as you get the numbers you need in the spreadsheet. You can be firm on the outcome you need, without needing to be firm on the process by which that outcome is achieved.
On the subject of doing the estimation itself, I'm a huge advocate of the Evidence-Based Scheduling system described by Joel Spolsky (http://www.joelonsoftware.com/items/2007/10/26.html).
Thanks Matt- I just
Thanks Matt- I just followed the Delegation Model on Wednesday with a new direct (contractor) regarding this. I made sure he was aware of why, which he could appreciate and agreed to take on the responsibility. It's the first opportunity I've had to use the delegation model. It went great, no problems.
Regarding estimates, you must've read between the lines in my original post! The whole purpose of trying to capture some historical data so I can try out the Evidence Based Scheduling approach.
Good to keep track of
Good to keep track of time, but take it with a grain of salt.
I don't know what domain you're in, but much product development and especially software development is very poorly estimated, to the point that schedules are often created and then just ignored. There's a reason that estimates in the software world are called guesstimates. Spolsky's approach and the ones suggested by agile methods (SCRUM notably) do get you much much closer.
I think it's fine to ask your guys to keep track of time. But the harder you make it, and the more "accurate" you make it, the more time it will take up and the more frustration you'll create. At best you're only going to get estimates of the time taken anyway. And, after all is said and done, you're still going to be producing meaningless estimates.
To take only one example where things can break down: Joe took 10 days to do feature Y, so I'll schedule 10 days for feature Z because I think it's similar. And I'll assign it to Sue. Well, Joe and Sue aren't interchangeable, and Y and Z aren't really the same, and you may find out later that what you really want is X instead of Z and by the way, turns out that Joe didn't think about aspect N of Y so it really needs 5 more days of work... doom doom doom.
This data can be useful, and needs to be collected, but beware of the limitations. Estimations and time tracking work can work better or worse in different disciplines.