12

We're having a problem at work: we're trying to schedule work so that we can assess time scales and get deadline dates.

The problem is that it's difficult to plan for a project without knowing everything that's going to happen.

For instance, right now we've planned all our projects through the start of December, however in that time we will have various in house and external meetings, teleconferences and extra work. It's all well and good to say that a project will take three weeks, but if there is a week's worth of interruption in that time then the date of completion will be pushed back a week.

The problem is 3 fold:

  1. When we schedule projects the time scales are taken literally. If we estimate three weeks, the deadline is set for three week's time, the client is told, and there is no room for extension.

  2. Interim work and such means that we lose productive time working on the project.

  3. Sometimes clients don't have the time that we need to take to do the work, so they'll sometimes come to us and say they need a project done by the end of the month even when we think that the work will take two months - not to mention we already have work to be doing.

We have a Gantt chart which we are trying to fill in with all the projects we have and we fill in timesheets, but they're not compared to the Gantt chart at all. This makes it difficult to say "Well, we scheduled 3 weeks for this project, but we've lost a week here so the deadline has to move back a week."

It's also not professional to keep missing deadlines we've communicated to the client.

How do other people deal with this type of situation? How do you manage the planning of projects? How much "extra" time do you schedule into a project to account for non-project work that occurs during a project? How do you deal with support issues and bugs and stuff? Things you can't account for during planning?

UPDATE

Lots of good answers thank you.

Thomas Clayson
  • 1,013
  • 1
  • 7
  • 12
  • 1
    Take a look at Liquid Planner (http://www.liquidplanner.com/). It allows you to enter optimistic and 'realistic' work hours for a task and calculates a estimated release date (with 50%, 90%, 98% accuracy). And it does a lot more, so if I were you I'd try a demo – jao Oct 21 '11 at 11:38
  • 2
    From your profile I see you are a developer. Your management has to deal with this and with the client. Your job is to make estimates of how much it will take and communicate transparently when something goes wrong. Management takes it from there. – JohnDoDo Oct 21 '11 at 11:42
  • 1
    About point 3: explain the [project triangle](http://en.wikipedia.org/wiki/Project_triangle) to your client: cheap, good, fast: pick any two. – mouviciel Oct 21 '11 at 12:33
  • JohnDoDo - we're a small company and development isn't all we do. Management want us to project manage our own projects. – Thomas Clayson Oct 21 '11 at 13:29
  • 1
    Mouviciel - that's good in theory, but not in practice unfortunately. we already have this in mind. – Thomas Clayson Oct 21 '11 at 13:31
  • @ThomasClayson How is that not applicable in practice? It's a well known fact of project management (of all types, not just software) that you can only control two of size/scope, cost, and time/effort, and the third is dictated by the other two. – Thomas Owens Oct 21 '11 at 14:03
  • @ThomasOwens - In theory it is a good idea. But in practice our company will take any job and won't challenge the client, the reason being that if we say "we can't do it in such a short time" they'll say "well we won't do it" or "we will take our business elsewhere" and then we "lose" £X. Sometimes the management set the timescales based on what they feel is "appropriate" to keep up appearances, or even worse challenge our timescales because it looks unprofessional to take "so long", or even more simply because the cost of development (by our timescale) doesn't make the project cost effective. – Thomas Clayson Oct 21 '11 at 14:50
  • 3
    @ThomasClayson That doesn't change the fact that the project triangle is truth. If your company doesn't understand simple project management, it might be time to leave. – Thomas Owens Oct 21 '11 at 14:57
  • @JohnDoDo From experience, management usually is just as lost as developers are (maybe even moreso as they have to rely on other people to make estimates unless relying relying on bs). – wildpeaks Oct 21 '11 at 22:30

8 Answers8

14

The problem is though that its difficult to plan for a project without knowing everything that's going to happen.

That's the point of risk management. You can't know everything, so you plan based on what you know and identify what things could have the most impact on your plan and how likely those are to happen. Assess the potential schedule impact as well by saying that if X happens, it will cause the schedule to slip by an estimated (key word - estimated) Y days or weeks.

Its all well and good saying that a project will take 3 weeks,

Never give such a specific estimate. Give a range or quantify the probability of hitting that estimate. For example, say "this project will take 2-5 weeks" or "there's an 85% chance this project will be done in 3 weeks and a 95% chance it will be done in 4 weeks".

Its also not professional to the client to keep saying we've missed a deadline.

True. However, you're mixing the concepts of "estimate", "schedule", and "deadline". Your estimate is an approximation of how long it will take to finish a given task or project and the probability of meeting that. The deadline is a customer-imposed date on which the project must be done in order to add value. The schedule is how you use your available resources to meet your deadline.

There are times when it's simply not possible to finish the assigned work within a deadline and all the estimation and scheduling in the world isn't going to make a difference.

So my question... how do other people do this? How do you manage the planning of projects? How much "extra" time do you schedule into a project to account for anything that happens in the mean time?

I recommend reading two books, both by Steve McConnell: Software Estimation: Demystifying the Black Art and Rapid Development: Taming Wild Software Schedules. Software Estimation is all about coming up with your estimates, presenting them to the clients, and some aspects of negotiation and dealing with unrealistic expectations. Rapid Development is general project management, dealing with development lifecycles, scheduling, resource allocation, and how to best schedule and budget projects to meet your estimates and deadlines.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
4

I would suggest dig into the Scrum development process details. It covers such sidetracking activities by the focus factor metric. Basically you've to work 2-3 sprints/iterations and then measure focus factor of your team (and for the each member it would be helpful as well). After this you would be able provide more accurate estimates which covers daily activity.

Take a look at this article - "The focus factor"

If any of you are familiar with Agile development, you’ve probably heard of the focus factor (or productivity factor). It’s used for planning to help determine how many “real hours” you have to work on something. It’s the difference between “real hours” and “ideal hours.”

enter image description here

sll
  • 421
  • 3
  • 10
  • 3
    Suggesting a specific SDLC without knowing the nature of the project and team is dangerous (for example, Scrum is inappropriate for a team of fewer than 5 or a team of more than 10, and jumping into Scrum without adequate research, buy-in, and cultural adjustments is setting up projects for failure), however the discussion of measuring the focus factor is indeed relevant and could be useful in any methodology, including plan-driven methodologies. – Thomas Owens Oct 21 '11 at 11:41
  • @Thomas Owens : OP could just take a look and perhaps he got insights regarding how to measure something like this or any an other thoughts... – sll Oct 21 '11 at 11:43
  • Thanks I will definitely take a look at all of this. We've got a team of 3 really, but in practice we work on projects by ourselves anyway. The focus factor argument is interesting. :) thank you. – Thomas Clayson Oct 21 '11 at 13:33
1

The thing about interruptions is that for given individuals or teams they tend to happen within a relatively small range of probabilities. For example, you have around the same number of meetings every week, or around the same number of hours spent on urgent bug fixes every month, or the same amount of time spent answering questions for people who drop by your desk, especially when averaged over a long period of time.

A lot of modern scheduling techniques take that into account. Scrum factors it into velocity. Evidence based scheduling also uses a velocity with a confidence interval for any given estimate. Pomodoro takes interruptions into account when you decide how many "pomodoros" you can count on completing in any given week. All of these depend on tracking historical measurements of your interruptions and factoring them into your estimates somehow. I recommend you take a look at all of them and devise a technique that will work for your team.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • That's the thing though, our interruptions don't happen like that. For instance, this week I should have been doing X but I spent 80% of my time doing interruptions. There have been more meetings than normal and a lot of support this week. Plus on top of that I've been made to put up some websites that have been shoehorned into this week and I had to set up a development server and provide tech support for the rest of the office. Next week there could be no meetings and no support. Or I could have to upgrade the routers, or backup a laptop or something. Here there is a large range of probs. – Thomas Clayson Oct 21 '11 at 14:55
  • 1
    Over a week or a day, you're right that it's unpredictable, but if you keep track of it month by month or longer, you will probably find that it evens out. If you really are more wild than normal, take a look at the confidence interval idea from EBS. It takes into account historical probabilities like "90% of the time, I have 5 hours a day of uninterrupted work, but the other 10% I don't get anything done all day." From that history, instead of hard dates, you get output like "There's an 85% chance we'll be done in a month, but 99% probability we'll be done in 6 weeks." – Karl Bielefeldt Oct 21 '11 at 15:31
1

Good advice all around.

One other thing that might be helpful for dealing with support issues is to dedicate folks to support on a fixed "round-robin" basis.

For instance, if you have 5 developers assign one to each day of the week. When that day comes, the assigned developer works for that day ONLY on support. The next day another developer takes over support. This way everyone has a chance to stay in their "flow", everyone gets a taste of the dogfood.

How you ACTUALLY choose to divide up the regular support work doesn't really matter (the days-of-week round robin is just an example). What does matter is to limit the support-time to fixed regular intervals. This makes development time more predictable with the trade-off that you can't have "everyone drop everything" to deal with support issues.

Angelo
  • 1,614
  • 13
  • 9
0

This is a skill that really comes with experience, and often people are asked before they are able to accurately judge such a thing. I've always worked in a fairly close-knit group with an informal style, but we developed a few rules of thumb that seemed to hold up well.

First, no task takes less than a week. Always estimate in weeks, even if a task only seems like it would take a few days to accomplish. There will be some reason it will not be done before the end of the week.

Second, Give it your best effort in estimating the amount of time the task will take, including interruptions, customer support issues, getting it through testing, etc. Now, double that number. That is your estimate (in weeks).

Third, make sure your manager isn't already adding some padding to your estimates. Our team had a manager complain about our estimates. It turned out he was already going to multiply it by 2.1 (his empirically derived padding estimate) and we had already doubled it before telling him.

It is not a fancy tool, and may not be a perfect method, but it works surprisingly well.

MattG
  • 304
  • 1
  • 3
0

THe people doing the estimation need to understand that no team is ever 100% on a project. You have sick leave, vacation, jury duty, bereavement leave, required HR meetings (it's benefits time!), team meetings that aren't project related, unavoidable delay, bathroom breaks, support work on items already in production, dealing with emails, , configuring the new computer after the old one died, answering questions about future work and doing estimates for that work, mentoring juniors, etc. that have to be factored in. It is irresponsible for an estimator to assume more than 6 out of 8 hours available per day. That is a guarantee the deadline cannot be met. If you are guaranteeing the deadline can't be met, you are guaranteeing an unhappy customer.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
0

You're absolutely correct - it is difficult to plan a project without knowing everything that's going to happen. But it is very important to keep a track of things that are a norm as well as the tasks that your forsee. Here's where schedule management plays a part. I've been using the Microsoft project management (standard version) for which also includes features that're part of a project management scheduling software.

You can visit http://www.microsoft.com/project/en/us/schedule-management.aspx for more information.

Garry Burks
  • 11
  • 1
-1

Seems like there is a lot of hidden effort drawn from your project teams through which you are losing focus and velocity. It might be benneficial to actually separate the task for dealing with

..support issues and bugs and stuff?

to a specific group of people so that the other team members can focus on the new development tasks. Through this their overall production might drop a bit but quality will improve because there is less distraction. This in return will reduce the number of bugs, hence a-hoc work that makes it's way into your projects.

As for the planning part, I completely agree with Thomas Owens answer.

Carlo Kuip
  • 560
  • 2
  • 6