How can I communicate to my manager that previously unknown problems will impact the project deadline?

Question

My team is responsible for implementing a big new IT tool in the company.

Sometimes there are problems based on incompatibilities between our company's existing systems and the tool and we have very vague idea of how to approach the problem. Our manager (no technical background) sets a deadline, e.g. "Ok, let's finish this by the end of the next week."

We start solving the problem, but while doing so, maybe just a few days before finishing it, we uncover more problems that are below the tip of the iceberg. That could be more incompatibilities, inconsistencies within our own historical systems, and much more for example.

Often, it is impossible to entirely solve the main problem until we solve the sub-problems.

Since this tool is very new, I think it is not easy to accurately predict the deadline to solve a problem. Yet our manager is very aggressive with deadlines.

How to properly explain this kind of situations (especially the fact that we cannot predict when we will uncover any hidden issues)?

Answer 1

Ideally you should have a good idea of what work is required prior to setting a deadline, and the deadline should be proposed based on that schedule. When your boss decides a deadline you aren't sure you can make, if you say nothing then you are tacitly agreeing to do it. If you tacitly agreed to a deadline you can't make, apologize, explain, and try to negotiate a revised deadline.

How it Should Work

So a new tool has to be made (estimate has to be done, report has to be written). The first step should be to figure out:

1. What it should do
2. What is required to do it
3. When it should be done by

It sounds like you skipped step two here. If your boss comes up and starts saying, "We should have something to do X, Y, and Z!" and you think this is a good idea (you have no objections to creating it), you should say something like:

Great idea boss! My team will look in to what we need to get that done, and we will report to you on A at B o'clock so we can discuss the schedule.

The goal is to point out that the first step after deciding what to do is to look in to what needs to be done to accomplish it so that you can have a better time estimate. And your boss shouldn't have a concern so long as you don't take longer to do the study than he thought it would take to do the entire project. If you aren't going to check the work volume first, be very very sure that your estimate is realistic and you've given a good thought to what potential problems could arise along with a way to solve them if they pop up.

Lack of Comment is Tacit Agreement

If your boss comes up and starts saying, "We should have something to do X, Y, and Z!" and you don't actually know if you can do X, Y, and Z or how long it will take, you need to speak up. Maybe you don't think Z is really necessary. Or maybe you think it's a good idea but haven't really looked in to Y in depth before. You need to speak up now or forever hold your peace.

If you don't say anything, you are agreeing to do what your boss says by the time your boss says.

Apologize, Explain, Negotiate

So you botched it in this case. It happens. You may have legitimate excuses but now is not the time for them -- you already tacitly agreed to take the task and finish it on time. Own up to your mistakes, explain why they happened (and how they won't happen in the future), and be proactive in providing a revised schedule to help negotiate a new deadline. For instance:

Hey boss, about that project to do X, Y, Z. I screwed up. I thought I had a good handle on Y but it turns out to be a lot more complicated than I thought. I should have brought that up in the meeting before setting the deadline. After looking in to Y, it looks like we will also have to work on A, B, and C. That work will take an additional 3 days. If we drop feature Y we can have it done by Friday and add in Y by next Friday, or we can push the entire schedule back to Wednesday complete with X, Y, Z. How should we proceed?

You are clearly stating this was your fault (it is). You are explaining what happened and that you have learned from it (hopefully you have). Finally, you are giving the boss two choices on how to proceed:

1. Finish part of it on time
2. Finish all of it delayed

Your boss can then pick one or the other, or negotiate something different. And then you'll have learned a valuable lesson for next time the boss has a great idea, and can bring this stuff up before it becomes a problem.

Answer 2

There are only so many ways to control project releases - only so many levers to pull. They are time/release date, features, quality and resources.

1. All job estimates should have padding included for the unknown. It's not always enough but it's always needed.

2. If you have identified sub-problems, also identify solutions. You can do the 'menu' style of a perfect solution, the worst possible solution that would result in a working product, and a reasonable compromise that would not be ideal but would be workable. If there are large features remaining, consider which of those can have alternate, less perfect solutions.

3. Scope out all the solutions. See if there's a combination that gets you within the desired date.

4. Prioritize the remaining, incomplete features. Which are things you can do manually for now? Which could be dropped entirely without impacting the user experience/the core value proposition of the product? Which are absolutely necessary for your manager to consider the product a 'win'?

5. Look at available resources. What would happen if you added people to the project? What if people worked extra hours to finish, and do you have a bonus structure of some form to remunerate them for their extra work?

6. Ask the team how much time they can shave off by doing a lower quality job. Look at the bug list and reprioritize 'must be fixed' issues. What can you remove and fix after release? How much time will that save?

7. Finally, go back to your manager and relay the facts of the situation. Tell him/her the approach you want to take, what the impact will be, and that it is the best way you can see to reach the desired sate as closely as possible. Answer his/her questions with facts. Take the approach s/he suggests/accepts

Answer 3

First of all, I agree with most of the stuff which atk said.

Let's look at this from the managers point of view

1) As you said he is not technical, so he may be not aware of underlying problems and task itself may look very straightforward to him.

As example, the task could be to change a button color. It sounds like a 3 minute task, but may be it's very complex, if this button in some 3rd party code to which you don't have full access.

He may not know all these information. So, in this case, you have to educate him and explain what is the problem, offer several solutions, give estimates on how long it make take to implement each of this solution.

I wouldn't recommend to talk to him through each obstacle, but definitely talk to him about newly discovered serious problems.

2) He may not trust software engineers, because he had bad experience with previous team.

If he trust you then he will accept the information which you will give him and will try to come up with new plan. if he doesn't trust you then it can easily become problematic situation.

Try to build trust - solve simple problems, explain complex problems, go extra mile. The worst idea would be to NOT communicate (as many tend to do).

3) Most likely there are some external factors which force him to be aggressive with deadlines.

I would recommend to learn what is the overarching goal. I noticed that quite often, you can bring way more business values (and meet deadlines) by changing requirements just a little bit (so they will still be aligned with the goal, but will be technically simpler).

Answer 4

Before the project

When you're scoping out a project, you need to research and talk through:

• Dependancies
• Known time expenditures
• Risks

This ideally is a collaboration between the guy who represents the business (probably your manager) and the guy who will take responsibility for the work (sounds like you).

Chances are, ahead of time, you can figure out that you'll have a few key technical things that you have to get done, and some of them will be in a certain order, other's won't be. Have a plan and map these out, so you'll know what relies on what (aka, the critical path).

Some areas have known time expenditures. This could be something like technical work you've done before - such as routine tasks in known systems. Others are simply work within the business - like procurement or security approvals. Have the knowns figured out.

Then tackle the unknowns. You'll have to make a guess, and with the dependancies and known time expenditures mapped out, you have some hope of finding your rocks and hard places. You'll probably end up with some awareness that "Task C, which we have no clue on CAN'T take more time than 1 week, or this just won't work".

That's where you hit "risks" - unknown, never-before-tried work is a risk - the risk is that you don't know what you'll encounter when trying it, and what will happen when you hit a problem. There's also the point that someone who had familiarity with this new type of work might do it quickly, but someone doing it for the first time is likely to be slower and make some mistakes.

That's the point where you figure out what to do about the risk. More time is one option, Lengthen the overall project schedule before committing. More knowledge is another mitigation - hire someone who knows the tool, get a consultant, get a killer support contract on the new tool, or budget time for a bootcamp for one of the employees. Or more than one of these things if the risk is big enough.

During the project

Review and rebaseline.

Sometimes you can have predictive measures - for example if task 1 6 weeks, then maybe another task will generally be known to take 1/2 that time... so if task 1 swells to 8 weeks, then figure that task 2 will also go from 3 weeks to 4 weeks.

Other times, you may want to review some of those risks and mitigations. Maybe you went to a bootcamp but it was lame, so you don't feel that you've adequately addressed the risk. Or you got that support contract but the company isn't providing the quality you expected, and your boss needs to have a long harsh talk with the sales rep...

If you don't reflect on whether you are succeeding with your attempts, you fall into the old proverb - "don't that don't learn from history..."

After the project

Do a lessons learned. Avoid blame, but reflect on what worked and what failed. If you had the opportunity to plan this again, what would you change in your plan?

Jot these answers down for next time. After a while you'll probably end up with categories of projects, and some knowledge of what happens when you attempt the big, weird, "we have no clue beforehand how to do this" projects, and a list of solutions that worked and didn't. That's the gold of reflecting, because it'll keep the company from wasting money on stuff that doesn't work.

Answer 5

You have to define the project and not let some non-technical person determine it to be, "install this application so it functions perfectly with existing system."

Maybe you indicate what the manufacturer suggests are the steps of a typical install. Once you have to include additional steps, you have a new project. Upgrading the OS may be another project in itself. Document everything and/or get approval from your boss to adjust/extend the project or possibly put it off for another time so more important projects can get started.

You haven't indicated what the consequences are for missing your boss's deadline. Often, bosses or any other person who doesn't truly know what it takes to complete a project (get it done by the end of the week), set a deadline because they believe if they don't, you'll just take forever and never get it done. He'll yell, moan, complain or be sad, but will probably get over it. Again, it depends on what the consequences are.

Answer 6

hey dude does this new tool need to be integrated into every system for it to be useful to somebody?

if it does then you just need to take the average integration times for previous systems and extrapolate that onto the next one.

if it doesn't then i'd suggest getting it live for a handful of systems and integrating the others as you go. this way your manager can report results and you will gain more credibility, and you will gain valuable early experience from field testing.

try to avoid the big-bang approach if you can and try to mine out the value incrementally. its more predictable and you collect your points as you go rather than attempting to scoop them all at the end. Having stuff live will give you bargaining power.