What to do if your estimate doesn’t get accepted?

Developers and managers sometimes worry that presenting an estimate that’s too high will cause the project to
be rejected. That’s OK. Executive management has both the responsibility and the right to decide that a project
is not cost-justified. When technical staff low-balls a project estimate, it denies the executives important
information they need to make effective decisions, effectively undermining the executive’s decision-making
authority. This results in diverting company resources from projects that are cost-justified to projects that aren’t
cost-justified. Good projects aren’t supported adequately, and bad projects are supported excessively. The
whole scenario is incredibly unhealthy for the business, and it tends to end unpleasantly for the people involved
in the projects that should not have been approved in the first place.

Developers and managers sometimes worry that presenting an estimate that’s too high will cause the project to  be rejected. That’s OK. Executive management has both the responsibility and the right to decide that a project is not cost-justified. When technical staff low-balls a project estimate, it denies the executives important information they need to make effective decisions, effectively undermining the executive’s decision-making authority. This results in diverting company resources from projects that are cost-justified to projects that aren’t cost-justified. Good projects aren’t supported adequately, and bad projects are supported excessively. The whole scenario is incredibly unhealthy for the business, and it tends to end unpleasantly for the people involved in the projects that should not have been approved in the first place.

Advertisements

Communicating Estimate Assumptions

An essential practice in presenting an estimate is to document the assumptions embodied in the estimate.
Assumptions fall into several familiar categories:
Which features are required
Which features are not required
How elaborate certain features need to be
Availability of key resources
Dependencies on third-party performance
Major unknowns
Major influences and sensitivities of the estimate
How good the estimate is
What the estimate can be used for

An essential practice in presenting an estimate is to document the assumptions embodied in the estimate.

Assumptions fall into several familiar categories:

  • Which features are required
  • Which features are not required
  • How elaborate certain features need to be
  • Availability of key resources
  • Dependencies on third-party performance
  • Major unknowns
  • Major influences and sensitivities of the estimate
  • How good the estimate is
  • What the estimate can be used for

How to Kill a Software Project

• Show the same demo twice to the same audience.

• Focus on the technologies, not the problems and scenarios.

• Fail to maximize return on investments; for example, developing proof−of−concept

prototypes is more effective than adding additional content to an existing prototype.

• Change project focus from the larger scale to the smaller scale.

• Don’t maintain consistency between releases.

• Isolate team efforts from other groups within an organization.

• Rewrite existing clients, servers, and applications.

• Change the purpose of the system, so that the models describe the wrong focus and

objects.

Napoleon Lessons on Planning, Execution and Leadership

Nothing can breakdown a team more quickly than a leader that have disproportionate reactions or that give-up easily

Any Leader that uses is power against their subordinates is subject to lose his power


Is it better to overestimate or underestimate?

Intuitively, a perfectly accurate estimate forms the ideal planning foundation for a project. If the estimates are  accurate, work among different developers can be coordinated efficiently. Deliveries from one development  group to another can be planned to the day, hour, or minute. We know that accurate estimates are rare, so if we’re going to err, is it better to err on the side of overestimation or underestimation?

Arguments Against Overestimation

Managers and other project stakeholders sometimes fear that, if a project is overestimated, Parkinson’s Law  will kick in – the idea that work will expand to fill available time. If you give a developer 5 days to deliver a task  that could be completed in 4 days, the developer will find something to do with the extra day. If you give a project team 6 months to complete a project that could be completed in 4 months, the project team will find a  way to use up the extra 2 months. As a result, some managers consciously squeeze the estimates to try to  avoid Parkinson’s Law.

Another concern is Goldratt’s “Student Syndrome”. If developers are given too much time, they’ll procrastinate until late in the project, at which point they’ll rush to complete their work, and they probably won’t finish the project on time.

A related motivation for underestimation is the desire to instill a sense of urgency in the development team. The line of reason goes like this:

The developers say that this project will take 6 months. I think there’s some padding in their estimates and some fat that can be squeezed out of them. In addition, I’d like to have some schedule urgency on this project to force prioritizations among features. So I’m going to insist on a 3-month schedule. I don’t really believe the project can be completed in 3 months, but that’s what I’m going to present to the developers. If I’m right, the developers might deliver in 4 or 5 months. Worst case, the developers will  deliver in the 6 months they originally estimated.

Are these arguments compelling? To determine that, we need to examine the arguments in favor of erring on the side of overestimation.

Arguments Against Underestimation

Underestimation creates numerous problems – some  obvious, some not so obvious.

Reduced effectiveness of project plans. Low estimates undermine effective planning by feeding bad assumptions into plans for specific activities. They can cause planning errors in the team size, such as planning to use a team that’s smaller than it should be. They can undermine the ability to coordinate among groups – if the groups aren’t ready when they said they would be, other groups won’t be able to integrate with their work.

If the estimation errors caused the plans to be off by only 5% or 10%, those errors wouldn’t cause any significant problems. But numerous studies have found that software estimates are often inaccurate by 100% or more. When the planning assumptions are wrong by this magnitude, the average project’s plans are based on assumptions that are so far off that the plans are virtually useless.

Statistically reduced chance of on-time completion Developers typically estimate 20% to 30% lower than their actual effort. Merely using their normal estimates makes the project plans optimistic. Reducing their estimates even further simply reduces the chances of on-time completion even more.

Poor technical foundation leads to worse-than-nominal results A low estimate can cause you to spend too little time on upstream activities such as requirements and design. If you don’t put enough focus on requirements and design, you’ll get to redo your requirements and redo your design later in the project – at greater cost than if you’d done those activities well in the first place. This ultimately makes your project take longer than it would have taken with an accurate estimate.

Destructive late-project dynamics make the project worse than nominal Once a project gets into “late” status, project teams engage in numerous activities that they don’t need to engage in during an “on-time” project. Here are some examples:

  • More status meetings with upper management to discuss how to get the project back on track.
  • Frequent reestimation, late in the project, to determine just when the project will be completed.
  • Apologizing to key customers for missing delivery dates (including attending eetings with those customers).
  • Preparing interim releases to support customer demos, trade shows, and so on. If the software were ready     on time, the software itself could be used, and no interim release would be necessary.
  • More discussions about which requirements absolutely must be added because the project has been  underway so long.
  • Fixing problems arising from quick and dirty workarounds that were implemented earlier in response to the     schedule pressure.

The important characteristic of each of these activities is that they don’t need to occur at all when a project is meeting its goals. These extra activities drain time away from productive work on the project and make it take longer than it would if it were estimated and planned accurately.

Weighing   the  Arguments

Goldratt’s Student Syndrome can be a factor on software projects, but I’ve found that the most effective way to address Student Syndrome is through active task tracking and buffer management (that is, project control), similar to what Goldratt suggests, not through biasing the estimates.

I believe that Parkinson’s Law does apply to software projects. Work does expand to fill available time. But deliberately underestimating a project because of Parkinson’s Law makes sense only if the penalty for overestimation is worse than the penalty for underestimation. In software, the penalty for overestimation is linear and bounded -work will expand to fill available time, but it will not expand any further. But the penalty for underestimation is nonlinear and unbounded – planning errors, short changing upstream activities, and the creation of more defects cause more damage than overestimation does, and with little ability to predict the extent of the damage ahead of time.

Tip: Don’t intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates.

A Working Definition of a “Good Estimate”

A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets

Communicating about Estimates, Targets, and Commitments

One implication of the close and sometimes confusing relationship between estimation and planning is that project stakeholders sometimes miscommunicate about these activities. Here’s an example of a typical miscommunication:

EXECUTIVE: How long do you think this project will take? We  need to have this software ready in 3 months for a trade show. I can’t give you any more team members, so you’ll have to do the work with your current staff. Here’s a list of the features we’ll need.
PROJECT LEAD: OK, let me crunch some numbers, and get back to you.

Later…

PROJECT LEAD: We’ve estimated the project will take 5 months.
EXECUTIVE: Five months!? Didn’t you hear me? I said we needed to have this software ready in 3 months for a trade show!

In this interaction, the project lead will probably walk away thinking that the executive is irrational, because he is asking for the team to deliver 5 months’ worth of functionality in 3 months. The executive will walk away thinking that the project lead doesn’t “get” the business reality, because he doesn’t understand how important it is to be ready for the trade show in 3 months.
Note in this example that the executive was not really asking for an estimate; he was asking the project lead to come up with a plan to hit a target. Most executives don’t have the technical background that would allow them to make fine distinctions between estimates, targets, commitments, and plans. So it becomes the technical leader’s responsibility to translate the executive’s request into more specific technical terms.

Here’s a more productive way that the interaction could go:

EXECUTIVE: How long do you think this project will take? We  need to have this software ready in 3 months for a trade show. I can’t give you any more team members, so you’ll have to do the work with your current staff. Here’s a list of the features we’ll need.
PROJECT  LEAD: Let me make sure I understand what you’re asking for. Is it more important for us to deliver 100% of these features, or is it more important to have something ready for the trade show?

EXECUTIVE: We have to have something ready for the trade show. We’d like to have 100%  of those features if possible.
PROJECT LEAD: I want to be sure I follow through on your priorities as best I can. If it turns out that we can’t deliver 100% of the features by the trade show, should we be ready to ship what we’ve got at trade show time, or should we plan to slip the ship date beyond the trade show?

EXECUTIVE: We have to have something for the trade show, so if push comes to shove, we have to ship something, even if it isn’t 100% of what we want.
PROJECT  LEAD: OK, I’ll come up with a plan for delivering as many features as we can in the next 3 months.

Tip: When you’re asked to provide an estimate, determine whether you’re supposed to be estimating or figuring out how to hit a target.

Microsoft Unified Communications

Today I’ve attended the event “Building Communications Enabled Business Applications for Office Communications Server 2007 R2” at Microsoft.

Office Communications Server Rocks!! Contextual Collaboration, Business Process Communication and Anywhere Information Access.

Unified Communications is the sentence. Lets integrate it in our applications.

Unfortunatelly the server-side requirements for OCS are huge! – Exchange Server 64bits – Windows Server 2003 or 2008 for Application Server

Definitely Microsoft Unified Communications are not for everyone. It seems to me that it is best suited for specific projects…



Believe in Yourself

Self Confidence is the first requisite to great undertakings.

Do well on your positives not your negatives.

Always be positive and think success, not failure.

It’s only those people who believe in the dream and have passion to make the dream come true that you want, because that’s what makes it work and gts the job done faster.

By John C. Maxwell

Commit to your true dream

Find out what you want and go after it as if your life depends on it. Why? Because it does.

When people discover their dreams and commit to them, there’s no telling what kind of impact they will make.

By John C. Maxwell