Setting your own deadlines when your primary responsibilities cannot be scheduled

Question

I know questions about setting your own deadlines have been asked before, but I think I'm in a unique situation. I have many software development projects, and one of the managers (though not my manager) keeps constantly asking me "when are these going to be done," and I constantly keep having to tell them "I don't know" because these are not my primary responsibilities.

As IT Support, my primary responsibility is to anything that is broken. If a computer or printer on the production floor is not working, then that comes first. If the network is down, that comes first. I cannot choose when things work and when they don't.

In addition to this, I have many more responsibilities that also cannot be scheduled which take priority over any software development project that I may have.

That being said, I have a terribly difficult time predicting when a project will be completed because I honestly don't know when I will have time to work on it.

The manager that is asking me about the completion dates of the projects has to track the progress and report it to the CEO of the company who apparently does not like being told you don't know when a project will be completed.

How should I deal with this situation?

Answer 1

This is a tough situation I admit. In a situation like this I would try to say which is the latest situation when I'll be ready with something. You are working in an IT environment so I assume you have similar activities so you can measure how much time you need. Here is an example by Larry Maccherone:

Here you can see how much time his team needed to finish something. You can read the diagram like this:

If you have a tough week your cycle time increases accordingly you can say you manager that you'll 32 days to finish, but during a calmer period you'll need about 12 days. You must emphasize that it is just a plan, not a full commitment. I think your manager will understand it.

There's also a screencast, you may find it useful.

Several month ago my former team had to give an estimation to sales about the possible date of certain deliveries. We were using lead time distribution in order to answer his question (my slides about it are available here):

Before, we had no idea what to say, so we gave him the lead time 9 because it was our average, sort of say. Then we learnt more and measured a lot so we told him that we would need maximum 5 days to deliver a new request. Maximum means that it is either 1,2,3,4 or 5, but nothing above (+1, we were using median because it was more accurate than average). And it worked pretty well.

Answer 2

You are right: "I don't know" is not acceptable, because it means you are incapable of planning. Your situation is not uncommon. This is an estimating and risk management challenge, which is the essence of all project management.

First and foremost, understand that your plan is a plan. You will not make your plan head on, with zero variance. So get real comfortable with that concept. You are after precision, not accuracy.

Second, planning for the project work is based on the utilization of human resources--yourself in this case--who are not 100% dedicated to the project. While your operations work has variability to it, you need to draw a line in the sand that says you will be committed to the project work x% of time, leaving y% to your operations work. That is the basis of your estimate for the project work. However, since your operations work has variability, i.e., supply will fluctuate with demand, so too will your project performance. This is an organic risk of this type of set up, it needs to be documented, and it needs to be communicated.

Third, your project work, based on your estimates, has a minimum, maximum, and most likley number of hours required to complete it. This is hours, not duration. Depending on where you want to fall in that hour probabilistic distribution, you can calculate the duration. Example, you are dedicated to the project at 20%. The hours estimate is 200 minimum, 600 maximum, and 450 most likely. Since you may want to be a bit risk averse, let's use 500 hours as your target. The duration formula is: Duration = Hours / Utilization, or Duration = 500 / 20%, or 2,500 hours or 313 days.

Therefore, you tell that manager you will complete this project 313 days from now plus or minus a 10% variance. You build your schedule, your track your performance, you watch your critical path, you capture your variances, you escalate early any unfavorable variances, you mitigate where you can, and deliver when you are finished. If it takes you 325 days, you are well within your stated variances and you can consider what you did a success.

If you really want to get sophisticated, you can add to this problem your probabilistic utilization distribution, too, meaning you will be dedicated to the project from 4% to 20%, most likley 12%. Run a simulation between that and your hours distribution and see what happens to duration from a pure random perspective. Then, you can base your duration plan on that result and on how risk averse you are.

Here is a sample simulation results using the numbers above:

This suggests your project will run anywhere from 150 days to as high as several years, but your MODE, your highest probability is 300 days. So set your target somewhere there.

This is a rather extreme example so the results are a bit comical, but hopefully you can see how it works.

Answer 3

A very simple approach would be to assess the proportion of your time that you spend on each type of task over a number of weeks: Let's say this comes out at:

• Support: 55%
• Projects: 30%
• Installations: 10%
• Training: 5%

So in an average week, based on the available data at that time, you will have about 30% of your time available for projects. If you can estimate your project effort (in hours or days), you can then work out how many weeks it will take on average to complete the project. Use this as your estimate, and caveat it with the fact that it will vary according to your other workload.

Continue to monitor your workload. As the quality of your data improves with time, you may find that your average project time changes - so it may drop to 20%, or increase to 40%, or it may fluctuate close to the 30% figure. Whatever it does, use this new figure to re-estimate the duration of your project. Highlight any major issues that have caused a major deviation from your plan, and flag up your new estimates to your managers, with proper explanations of any variances from the previous estimates.

One thing that you may need to think about is how to deal with multiple projects that you may have on your list at the same time: do you address them in parallel, or sequentially? I don't know your business, but I would suggest that a sequential approach would be better if that is possible. You may have to get someone to prioritise between projects, but doing a couple of hours a week on each of half a dozen projects almost guarantees that none of them will ever get to an end, whereas working on one project for 12 hours will allow good progress to be made, even if that 12 hours is split over the 5 working days.

Your manager may not like all that he hears, but at least you are providing a reasoned picture of how you think things are likely to progress, rather than saying "I don't know". Good luck!

Answer 4

This sounds pretty messy but I would start by trying to at least clear up your section of the mess.

The way to do this is to start by setting your own deadlines first. Odds are they won't be accurate because of how chaotic the situation seems to be but it won't matter, set them anyway. Without a deadline of your own, there is no reference point and you are just contributing to the mess.

You will have to adjust your deadlines often because of issues beyond your control but that's NORMAL, everyone goes through that. If you have to move the deadlines, just so it. Then when someone needs to know how you are doing, just tell them "My original deadline has been extended by by 14 days because Dept X can't deliver Y in time....., they asked for another week" or "I set a new deadline because ......". Whether you extend it or create a new one depends on your corporate culture and isn't significantly different. What's important is the word in bold (week). Always ask for a date when something happens that causes a delay.

The key thing is to document how your deadlines are changing, why they are changing and how you came up with the new date. Before you set your deadlines, there is no documentation. No documentation means management can't step in to help fix things.

If your documentation shows that the deadlines are always moved because of Dept X or some other chronic issue, point it out to management and get THEM to fix it. Most managers won't step on toes unless you give them reason to. If you want them to help you solve the mess, make it EASY for them. This is where the documentation helps. Bit by bit, the mess around your end clears up and you will be able to breathe.

By the way, if you KNOW you are going to miss a deadline (especially if its because of some external issue), bring it up BEFORE it happens. The manager will thank you for giving him time and a chance to fix it.