How do you manage project estimation and managing your teams time

Question

I'm thinking of things like:

• designating a developer having say 6 hours out of their normal 7.5 hour day dedicated to the project, the rest for other work/company related activity (meetings, emails, calls etc), maybe a senior dev is less.
• building in 20% contingency time to estimates.

What are the best ways to produce tight estimates and at the same time shield developers from management.

Addendum: I've been asked to help my current client with these types of issues. They are a really poor dev team with the business calling all the shots, scope creep, overlapping environments, priority changing at a whim etc. I want to help them get better.

Answer 1

A pet peeve of mine are arbitrary deadlines.

Project Deadline: the problem

Project estimation invariably leads to a date which becomes an implicit deadline. Missing that date, regardless of cause, often feels like a failure if it is not outright characterized as such. When you give a date you set expectations and when those expectations are not met it is natural for people to feel somewhat cheated or deceived. Team morale often takes a hit.

Project Deadline: blunt team management and it's cost

In my experience people want arbitrary dates because they want to use project management as a blunt tool to try herd developers into what to work on and how hard to work. So, the best case scenario is the team works to a deadline and get's it done early. The same performance you would generally get without a deadline.

The worst case scenario is, as anyone who has ever had a project go over a deadline knows. The closer you get to a deadline, the more shortcuts are taken. The more quality of code suffers. And generally the more morale suffers. It is idiotic to try and force people to work to an arbitrary date when you look at the cost. The outcome is you've produced bad code and made morale worse. You may even have some turnover as developers seek other places to work.

Just to reiterate:

• Best case scenario is the same performance you get from the team without a deadline.
• Worst case scenario is bad code, bad morale, and a bad experience all around.

Projects Without Deadlines: a better way

I don't give dates unless there is a hard deadline. The release has to align with a marketing campaign, a particular event, etc. However, the question then becomes how to we (the development team) interact with others? How do they know when their requested piece of work will get done?

Frequent Releases: Vertical Slices and Velocity

Firstly we track all the work that is done. No work is engaged in that is not feature or a bug fix. Everything is done as a vertical slice. So when a feature is completed, it is releasable. We release biweekly currently, but have in the past released weekly. The result of this is everyone sees not only progress and completed work, but they get a sense of rate of work as well. Indeed we even have a weekly velocity (we use the idea of continuous weekly Sprints), along with a 14 week mean, standard deviation and median.

Public Priority List

Second we have a priority list that is public and we only work on the highest priority work. I manage the list, and make calls about priority informed by various factors. I double check with my manager.

So people get to see there work in relation to others, and they get to see each piece as it is complete released (on the biweekly release). So far it seems to work, and best of all no arbitrary dates.

Answer 2

Previous performance is the best predictor assuming you have valid data. It still may not be accurate enough, but the more cumbersome you make gathering data to gain accuracy, you risk not capturing it at all.

IMHO - being focused on what is important is the best way to manage your time and hit due dates.

Answer 3

That's a good start @James, but consier that administrivia interruptions don't all come in a convenient 1.5-hour block, they tend to be sprayed throughout the day and have impact far beyond the nominal time for recovery.

Also, 'hours' is not a terribly meaningful measure of achievement. An hour spent staring at the monitor watching the clock waiting for lunch to get some Starbucks to wake up enough to have the will to tackle the bug that kept you awake all night is not the same as an hour spent at Starbucks debugging like a maniac while IM'ing four friends for help with a tricky I/O blocking and race condition.

While a 20% margin might account for simple errors and oversights, but not for major omissions and mistakes (and platform "gotchas!")

Finally, as @Bill suggested, the PM site would be a better place for this question.

Answer 4

Depending on the size of your team(s), there are various project management methodologies which can be used to help establish realistic and achievable deadlines.

The most popular Agile methodologies are SCRUM and Extreme Programming (XP). Both have best practices and revolve around principles which are just common sense.

20% is a number I've also seen in the past which in practice is quite realistic. This number can be diminished if developers don't need to switch frequently between tasks.

Personally, adopting SCRUM really helped my team establish realistic timelines and milestones. It also helps communicate our objectives to the rest of the company. (the "non-techies")

Answer 5

The addendum is a different beast than the OP. Now you're talking about how to educate management on how software development works, and what's been recognized as setting things up for failure, such as scope creep. That's quite different than helping a team get good at estimation and time management.