2

I am an embedded developer, often tasked with bringing up prototype hardware.

This tasks are highly variable in the tame it takes, mostly due to reasons outside of my control and this is not known before I start my work.

For example, if everything works fine bringing up a specific peripheral should take half a day to a day. But if there are issues with it, either due to a mistake in the circuit or faulty drivers, this can take a week or even longer.

What I usually do is give two estimates, for both cases, although the bad case one is usually very vague or very high. Depending on the task at hand it might be impossible to estimate.

I have also recently learned when to stop and state that it's not worth investing in this particular path (such as picking a different integrated circuit instead of writing drivers for it).

It has bugged me for quite some time since despite gaining experience my estimates do not improve. Is there anything I can do to improve this situation? Or should I just accept this as the reality of my job?

Edit

The answers suggest communication - this is not an issue here. Given the size of our company I report directly to the person handling client communications and give a short verbal status update daily.

5
  • Which estimate is not improving? Is it the one for everything working, the one where there are issues, or both?
    – sf02
    Mar 5 '20 at 21:04
  • 2
    Who are you giving these estimates to, and for what purpose? Is that person able to give you guidance on their expectations? How are your peers developing their estimates?
    – dwizum
    Mar 5 '20 at 21:04
  • Why do you feel or know your estimates need to improve?
    – DarkCygnus
    Mar 5 '20 at 21:07
  • This is in a startup and I'm the only person with my skillset, so no guidance. The estimates are passed through my boss to our clients. And mostly the bad case one does not improve. Mar 5 '20 at 21:08
  • @DarkCygnus a recent project had multiple bad cases causing some delays and I am questioning if I could have handled this better. Mar 5 '20 at 21:09
1

Depending on the circumstances and technology, some things are just hard to pin down. I almost always give a range, even when I'm very confident in my estimate (there is always a chance I am wrong!) I have come to terms with the fact that there is always a margin of error and I make this very clear to my clients/management. I let them know how long I think it will take, how accurate I think my estimation really is, how much I think I could be off by, etc.

When there are a lot of unknowns and the range is large, it helps to give more than just a high and a low. "Wellllll...it might be done tomorrow, but it also might take a few weeks" doesn't really mean much of anything. Give them as much detail as you can and plan a road map. Explain each thing that can go wrong (if known) and how much time it will add. At the very least, give 3-4 estimation points within your range. Something like "Well, if the stars align and I don't run into any obstacles, I could possibly have this done by tomorrow, but that is unlikely. My optimum target goal is to have this done in 4 days, but I expect some unknowns to arise and I anticipate it taking closer to 7 days."

Perhaps most importantly, update the estimate as often as possible given new information. With every day that passes you should have a more accurate estimation as to how much time remains. If this number changes, let them know. If you run into a major obstacle, let them know right away that there might be a delay. Don't wait until your estimated date of delivery to say "oh yeah, I ran into some problems and it's gonna be a little longer"

1

Board bringup, like many activities in new product introduction, is intrinsically uncertain.

You simply don't know in advance everything that you're going to end up dealing with. The same problem is faced in all kinds of industries... construction, supply-chain work, event-planning, etc.

This has to be made clear to your stakeholders.

That said, there some things you can do to make it easier to swallow for the people who need an answer to "when will it be done?"

Do what government contractors and software developers do: break down the project into multiple phases or milestones, break down each of those into even smaller pieces. Report regularly on progress including set-backs, answer questions, show your work. Reassess the subsequent milestones as you complete the current ones. As long as the backlog of remaining tasks mostly shrinks, people who aren't toddlers are perfectly OK with the idea of an uncertain timeline.

Never casually give a PM "a date" for anything, they're apt to shake their head like they understand and then silently record it as a hard-deadline even if you put a dozen conditions on it. Many of us learn the hard way that saying yes to an optimistic/unreasonable/impossible deadline and then putting forward a heroic effort that ends up missing that deadline is not respected, it's scorned. It's much better to be a jerk about the deadline far before it hits, that way there's no surprises.

Ultimately if you make "a promise" that promise gets made into other promises that end up getting repeated through the ranks and up to a customer. If the thing doesn't get delivered, that chain of promises leads back to you-- so you have to be careful about what you commit to.

2
  • It might be that being "the Linux guy" on the team and doing schematic reviews for those boards made it too personal for me. Virtually every IC which is controlled from Linux is also picked by me, or at least approved. Mar 5 '20 at 21:48
  • @JanDorniak, I am trying to say that the uncertainty and inability to give an accurate completion date is actually a part of your job that you must work-around. It's a matter of breaking down the project into pieces so that stakeholders have a continuous sense of progress rather than simply "done" or "not-done". This is largely a communications problem.
    – teego1967
    Mar 6 '20 at 11:34
0

Based on your responses to comments, I would like to present a slight frame challenge to your desire to improve your estimates.

While your desire to self-improve is noble, the point that needs "improvement" may be the negotiation with the client, not you providing estimates. It shouldn't be your responsibility to see issues that are not forseeable, or to know how much time they will take. A skilled client manager will know how to handle "bad news" or changes when talking with a client. I would be careful of assuming too much of someone else's responsibility.

Rather than focusing on improving your estimates, you may want to focus on working with your boss on the overall communication process - i.e. if you estimate 100 hours, and you hit an issue at 20 hours that will cause an unknown delay, that becomes the point at which communication with the client needs to be handled appropriately.

So:

  • Check with your boss on how they feel about your estimates. Ask if there's anything you can clarify, or any additional information you can provide.
  • Make sure you and your boss are on the same page when issues do happen, and you are giving your boss the information they need in order to decide what to communicate to your clients
  • As a way to reflect, look at past projects and the un-forseeable issues that came up. There will always be issues that you can't predict. But, are there things you can change about your work process that will make them less significant, or more predictable in duration? Are there things you can standardize to gain some efficiency through re-use? Are there things you can test earlier in the process to catch issues before they become work-stoppers? And so on.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .