I run a workshop on estimating and planning for testing (and development) project team members and managers. In one of my breakouts, we review a near Death March project scenario to see how students will react to the challenges in their communication to upper management stakeholders.

One of the surprising outcomes of the workshop is that a very small percentage of the teams actually say “No” to their leaders—less than 2 percent. Another 8 percent will negotiate on scope and/or quality targets. Slightly over 90 percent commit to the project as-is, with no negotiation or discussion. Now keep in mind, this is as close to a disaster as I can make it and still 90 percent of attendees buy into it.

Why is that?

I think there are two key factors that are coming into play. First is a bit of overconfidence on our part as technologists. Or call it youthful enthusiasm. We think that we can do anything and are usually overly optimistic in our thinking around the level of effort surrounding technical tasks. Development teams are notorious in this regard, but I would argue, so are testing teams.

Another factor is FUD (Fear, Uncertainty and Doubt) as to how the organization will accept your reply. How will you be perceived, is anyone else struggling with the commitment and this is what you get paid for—right? Depending on the culture, this socio-political pressure to “simply agree” can be intense as well.

Given all of this, I thought it would be useful to share a few negotiation strategy points or patterns that you might find useful in combating your own youthful enthusiasm when it comes to committing to schedules and work:

Always Negotiate: I’ve never seen a software project that didn’t require it.

Buy Time: It’s always a good idea to gain more time for research, thinking, analysis, engaging other team members, looking back at historically similar projects, becoming more familiar with and fleshing out the requirements, etc. Rarely is it a good idea to simply commit immediately—even for well-understood tasks.

Speak in Terms of Ranges and Uncertainty: If at all possible, communicate your effort in ranges aligned with best-worst-average case views to the work. There is something called the “Cone of Uncertainty” that you can Google for more information. It basically represents the reality that estimates align with the level of information. In other words, your estimate accuracy is poor before requirements, better after requirements and even better as the design completes. Ranges help reflect this natural uncertainty.

Mention Risk, Over and Over: One of the downsides to executives and stakeholders pushing so hard on date commitments is that they miss the risk proposition. We need to continue to list high priority risks for them during the life of the effort—not out of fear, but simply to ensure their awareness of the projects’ uncertainty and associated risks. We also need to aggressively monitor risks and advise of positive and negative changes as they occur.

Plan for a Plan: This is a variation from buying time that I find imperative. Instead of providing a direct response, I’ll lay out my thoughts for gathering information, estimating the work and coming to a more thoughtful schedule response—a plan for coming to the plan. Typically, you have little time for this, so it needs to be aggressive. I also leverage ranges into the plan's milestones. For example, committing to a rough plan of attack and then declaring another milestone when we’ll understand enough to narrow the estimates and reduce the risks.

Leverage History: Whenever possible try to leverage your historical data as part of your estimation process—and not simply for task estimates. Consider your historical risk patterns, development release maturity levels and defect trending/product stabilization curves as well. I’ve found that the higher level patterns repeat as much as those at the task level. Another important factor of history is that everyone remembers the results. If the previous five similar efforts took 10 weeks to complete, why would anyone think it could take five weeks this time?

As the story went, the Lion already had the courage. He just needed to be reminded of that fact. And please don’t be offended by my use of the word courage. It’s much more of a metaphor for having a bit of it, as well as a set of effective negotiation tools at your disposal. I hope I’ve given you some tools to consider the next time you’re pinned down in a dark hallway and asked—“How long will it take to test an application?”

Bob Galen is an author, speaker and the principal consultant of RGCG LLC in Cary, N.C. He can be reached at bob@rgalen.com.