how to explain to people how difficult your project is

Question

That is something that literally affects any engineer in a bigger organization. You have a project that takes longer than expected, but for a good reason.

Project you depend on did not ship on time. In the meantime you discovered that infrastructure you planned to use is going to be deprecated and when you have finished coding someone told you that using feature X is not allowed, because it will break foo and bar right after launch. Of course owners of foo and bar were well on board 6 months ago and assured you that what you are doing is ok and yesterday changed their minds.

Is there any way to explain this to:

• managers,
• other engineers convinced that "Hey man, I could code this in a week?",
• customers.

Answer 1

I have very little trouble with this, ever. I just tell people what I've been trying to do the last 2 hours and how it fits in the whole project. Anyone who hasn't been sitting next to me or has been working on the same project will understand that this is difficult in a matter of minutes.

Maybe I'm just bad at explaining things...

Answer 2

No body likes doing it, but document your progress on a regular basis. Make sure you include the impact of any changes from either customers, management, or vendors. Be honest about mistakes. Finally when did any project go as planned? Prepare for problems. Include some extra time for the unexpected. Hide it well so people don't take advantage of it.

Answer 3

A lot of people do not care about how it's difficult, they want it on time. They do not care if it's perfect design or that won't break, they want the product ship in time.

It's depend of the person, some will take time to listen but often they won't listen you until you show them that few more days would save them cost later.

I think the biggest argument you can have is to show them how many money they lost by not following your advice, than, you will have all their attention.

Answer 4

Depends on whether it's really a "good reason" - the question isn't whether the delay can be explained, but whether you considered "unexpected delays" in your original estimate. If your projects always end up lasting twice as long as the original estimate you gave, no matter how good the reasons for the delay are, there's still a problem with your estimates.

Answer 5

-Managers: For managers I make sure to keep them aware of any struggles or road blocks that come up during development. For example say you were planning to use an already existing function and found a bug in it and then had to fix that bug before you could go forward. There are a couple parts of the product I work on which didn't get very good code coverage during testing when they were implemented. Bring up problems as they occur rather than let them pile up though.

-Engineers: Depends on the company. I've worked places where you could say "fine let's see you do it." Or maybe you could see about getting their help on the project. Either you'll learn something or they'll see what the roadblocks are. Otherwise you just explain to them issues in a similar way to the managers but use more tech-speak to do it. I think a lot of engineers are competitive in nature so really other than having a coding race this problem might not be solved.

-Customers: This all depends on what sort of communication you are allowed with your customers. You probably don't want to tell them about problems on the same level as your manager or engineers. If customer wants feature x and tells you to use technology y which is causing the problem then you could explain to them the road blocks. Otherwise I would stress the how they probably don't want you to deliver a sub-par product.

Answer 6

The number one problem with project management is transparency. From the client"s point of view, you ask their opinion during requirements gathering and then disappear for weeks or months at a time. This makes people very nervous. A strategy that has worked for us is starting with line item estimates and follow up with weekly status reports. When some risk to the project emerges we immediately tell the clients, and either extend the deadline or start cutting features. We no longer try to make up the time to meet the original deadline.

With frequent updates and early warning we have found much less finger pointing when the inevitable happens. When clients don't believe your explanations it's because they feel they have no control over the project, except to put pressure on the team to work harder. Keep you clients in the loop, and include them in fast/good/cheap trade-off decisions and you may find your clients working with you instead of against you.

Answer 7

A strategy I try and use, is constant communication. When I hit a road block, I will communicate that I hit a road block, what caused it why its significant and how it will impact the schedule, and if needed how I can make up the schedule in other places.

I also have been sticking to quick releases with smaller feature sets that are not as polished as they could be (the UI is not as preety, or advanced features are not implemented). Quick small releases has a huge benefit from a user perspective in that they get to see and use the system at various checkpoints and then can provide feedback which can result in the project going new directions.

It also helps in estimating since we are dealing with much smaller feature sets and timeframes. Earlier this year I was on a two week cycle; however, we have been takling bigger features recently and added more process around the deployment that we are around 3-4 weeks.

The other thing that I have seen a lot is people who artifically inflate the sense of dire when hitting a roadblock in the name of Architechure Purity or the System Design. Don't let the art of engineering prevent you from releasing, because at the end of the day no matter how preety the code or system is, it won't immediatley impact the bottom line, and sometimes you have to make the sacrifice to not spend the additional resources today knowing you'll be paying twice that in the future (but hopefuly in the future your organiztion can afford the cost). Being in a startup company this is critical for me to keep in mind.

Josh

Answer 8

Do the best job you can to get it working in the time you have. If it doesn't work, tell them what you're going to do to fix it. If they have any professional respect for you, that should be enough for them.