21–30 of 51 posts
There is lot of stuff about honesty and so on. After being maintenance programmer for a long time, I would just say: Do not stress about it, and always inform relevant people.
The key is to divide your milestones in very small tasks in hours and communicate this detailed hourly plan with your total estimate. Update your manager/client about your progress as frequently as possible. Twice a week if not daily. During the project, if you realize that your estimates were originally wrong, fix it asap and communicate immediately. Frequent communication is the key.
The most important thing is to state unmisunderstandably, before you start the project, that you are making an estimate which has an error range of +/- 3 orders of magnitude and that you will be revising it as you go along. Once that is clear, the customer is prepared and will be expecting and able to handle estimate revisions whenever you make them.
How do you communicate if you won't hit an estimate? Immediately, with brutal honesty, and positively. 1. Immediately: Never delay communication. Most people will be less upset about the schedule than the fact that they weren't informed. 2. With Brutal Honesty: Explain exactly what's going on. You may end up with a pleasant surprise. "Oh, can we just have xyz then?" or "How can we reduce the scope?" or " How can we h…
Stuff happens. Good project managers will adjust and move on.
Additionally, if you are being blocked by something external, you MUST let your project manager know ASAP! One of his primary jobs is to remove impediments, so you can do your job.
The advantage of things like Scrum is that a 1 week sprint size should flag up slippage within a week.
It's hard for people to actually know they're going to miss a deadline, and they might feel that they can course-correct. But if you have a really clear definition of done, and work broken down into pieces that fit within a week, and you do planning each week... then you will know as soon as you slip, that you are slipping. And if the product owner is involved in planning, then there's just no hiding it and he can communicate it upwards.
Things like agile and Scrum are core processes for this... they give you nowhere to hide, and that helps those who need delivery to get that feedback early so they can prioritise what they most want delivered (if the deadline is more important than the totality of the delivery) or how they're going to communicate slippage up the chain (if the totality of the delivery trumps the deadline).
If this is all noise to you, then just do this:
1. Break your 3 month project down into logical pieces of work, each one small enough for you to understand roughly how to do it (realistic work effort) where no single piece of week should be larger than 1 week (if it's bigger, it's a smell that you're estimating badly and don't understand each of the parts involved).
2. Order all of the pieces of work such that you are doing the most important things (decided by the project sponsor) first.
3. At the start of each week declare what you will finish that week, always the most important things you could be doing... and get to work.
4. On Friday, see whether you finished everything you said you would. If you have not... you have slipped and it impacts next week and gets communicated.
Here are some challenges that come to mind in software estimation:
1. Estimates are almost always done too quickly, with too little information. If you can wait, spend more time, or reduce the unknowns, do so. If nothing else give it an extra fifteen minutes. If you can say "I'll get back to you with an estimate by ..." (e.g. tomorrow or end of day) that's even better.
2. Estimates are ranges, a probability that the work will be done across a range of time. but are often given as a specific date or amount (e.g. "It will be done tuesday/take 5 working days"). Early or quick estimates may be ranges of 15x or more (e,g, "it will be eight hours to three full work weeks"). Don't be afraid to capture that ambiguity in a range. Others may not understand ranges, so give them the high end if needed, but at least be aware that ranges exist. Often ranges, or high estimates get push back. This is your opportunity to specify what questions need answers, what requirements need refined, and what areas need more design and architecture to reduce ambiguity. These things can reduce ranges of estimates.
3. Know the difference between estimates, targets, goals, and commitments. Confusion between these leads to miscommunication and frustration. Often we'll make a guess like "maybe two weeks" which is a wild instant estimate, and others will see how nicely that lines up with their target date, and believe you have committed to that goal. Commitments should be explicit, and part of your process.
4. Do not negotiate estimates. Managers are trained to negotiate, and a naive manager will almost always reduce estimates through negotiation, which is a distortion of reality. Developers should collect the information they need about the requirements, ask questions, then produce their estimate in isolation, and refuse to change it. The way to change an estimate is to change the requirements, often addressing ambiguity and questions, and re-estimate the work given the new information. This is hard to do, because a "better" timeline can make everyone feel better in the moment, but will lead to problems later.
5. Renegotiate when change happens, or when you are in danger of failing a commitment. This one answers half of the original question, to my mind. If you didn't make a clear commitment, or requirements are changing with out any renegotiation, you have to fix those first. After that, keep a close eye on scope creep, and changes. Change happens, accept that, but make sure that those you have commitments to understand that change has impact on your commitments, and you can either commit to the original work and timeline, or you can commit to the new work, and a new timeline. Holding you to new work on an original timeline is not fair to you, and not a problem to be solved at the developer level. This one can be quite challenging, some people use "change management", itemized / ticket based change requests, even explicit signoffs. If you have trouble here, find what works for you.
6. Learn from history. You won't get it right. A lot. Keep track of how you are doing, improve processes and spend more time refining requirements/acceptance criteria etc. Make sure commitments are negotiated and explicitly agreed to. Keep learning.
7. You will make mistakes. If you uncover new questions, requirements, found work, it was in a certain sense an estimating error, but it has a different fix. If you had a reasonable view of the work to a fair level of detail and spent reasonable time on the estimate, and are still missing your commitment, you have made a mistake. That's OK, especially early on, or in new areas for you, if a team has shifted etc. The answer is, communicate. Let your manager know immediately, as soon as you realize it, that you feel you are at risk of failing a commitment, and you need to revisit. From there, you can investigate the new work, or re-estimate based on your increased understanding of the problem. Perhaps note some data for your historical tracking. Learn. Next time, make a better estimate. It does feel bad to miss a commitment, or even to not make a deadline that someone else set up. That's very human. The way to feel better about it, is to get better at it.
The above is based on my decade of experience as a software developer, and a solid foundation from Software Estimation: Demystifying the Black Art, By Steve McConnell http://www.amazon.com/Software-Estimation-Demystifying-Devel...
I highly recommend the book as a learning resource, and having the whole team, managers included, read at least the first portions of it. It also has specific tools for various estimating challenges.
My favorite question: "Is the date slipping, or has it slipped?" What you really need to do is help the person setting the deadlines plan. There are things they're doing that are synchronized with finishing the project, and there are things that simply depend on the project. Marketing may want to publish a blog post. Sales might want to promise a delivery date (or already has). Management might want to claim victory…
I second the "Slip once, and slip hard" tip. Saying "one more day" a second/third time as it is both confusing and annoying to others.
The key is to divide your milestones in very small tasks in hours and communicate this detailed hourly plan with your total estimate. Update your manager/client about your progress as frequently as possible. Twice a week if not daily. During the project, if you realize that your estimates were originally wrong, fix it asap and communicate immediately. Frequent communication is the key.