How Long Will It Take To Deliver?

February 27, 2009

A typical question that arises in the software business – and I’ve had this happen to me literally as a meeting to elicit the business requirements was coming to a close – is, "So, how long will it take to deliver the requested features?"

My default answer in this situation is, “Well,” (my standard lead), “we’ve got a lot to review, I’ll get back to you as soon as we are finished with the estimates.”

Have you ever felt challenged about delivering estimates? There are times in the past when I've had feelings of trepidation, coupled with the thought that those on the business side were being unreasonable and overly demanding. Their urgency was crystal-clear, and they didn't seem to care one bit (no pun intended) about what it would take to produce the software. They wanted it yesterday. Are there unreasonable people in the business world?

Yes, there are. There are some who aren't looking to create that win/win scenario. They want to win at all costs. For them, winning is the thing.

More often than not, however, the business has its demands that cause what appears to be unreasonableness to those of us on the software side. After all, the business has its customers that it has made commitments to, and the business needs to make its dates as well.

This leads to an interesting dynamic when business people interact with software teams. Many times, those on the business side push towards an aggressive date to ensure that they’re getting full value for their money. It’s partly about maximizing value, but there is another reason. Negotiating is a way of life for many business people. It's their default mode of operation.

Unfortunately, too many in the software world spend so much time with computers that they are terrible (or at the very least inexperienced) negotiators. Bottom line: don’t let someone negotiate you into a bad position! Make sure that you have your facts, and by all means hold your ground.

When it is all said and done, no matter how passionate someone is being about the end date, the world won’t stop if your position – one that you can support – is that there is too much being requested given the constraints that you have (resources, time, budget).

No one on either side of the table wants to start a project with the dates that are wrong from the outset. In some cases it would help to understand the key drivers that are pushing the business. Ask questions! Maybe another solution is available, or priorities for delivery can be adjusted to create a win/win scenario. Other times, problems could have been avoided if someone had provided the business side with insight on why exact estimates are difficult to come by.

It’s about educating, building trust, and establishing a true partnership.

Consider the following.

For some reason, software projects always seem to start with an implicit assumption that ALL of the requirements have been fully expressed and will remain stable. Even when everyone involved agrees that there will be variability, once a date gets published…

People forget that the definition of estimate is approximate and everything ends up revolving around the exact end date provided in the estimate. It's not right, but that is what happens.

The truth of the matter is that requirements are rarely as complete and locked down as everyone thinks they are – despite how complete they appear on paper. Even when you think that you’ve nailed the requirements from a business standpoint, the act of writing software will surface the need to define new requirements.

The primary cause of this is that computers require specific, detailed instructions for every task that they perform, and it is virtually impossible to catch all the little nuances of how a business operates at this kind of detailed level up front.

Now add the fact that non-business people (programmers) are translating someone else’s knowledge and understanding of the business into the software. So I ask you, what are the odds that the software will be completely correct on the first pass? I came across a great quote that expresses this reality:

"Software is an opinion about how the business works."

I don’t know who coined this phrase, but I’d love to find out so that I can give credit where credit is due.

The reality is that software projects require adaptation as they progress, and while I feel that you should perform as much due-diligence up front as possible to minimize the unknowns and to help create greater confidence with the estimates, I also recognize that there will in fact be unknowns and change that must be taken into account.

This is also why I advocate small projects. Small projects that target delivering the features that will provide the greatest business benefit are the projects on my “most likely to succeed” list. Small projects keep issues contained.

I also advocate that the people doing the work must provide the estimates. People who will be performing the work must have an understanding of what is being asked and they must be committed to accomplishing that work. The best way to achieve this is to have them estimate the work in the first place.

Another very important concept that I recognize as a manager is that estimates will vary depending upon who will be doing the work. Studies have shown that there are 10x productivity differences between programmers at the same level, something you must take into account if you want an accurate end date!

When it comes to the actual estimation process, I’ve found that the most reliable estimates come from a team effort. The general approach is that the team meets and reviews the requirements one by one, listing the development tasks required to meet each requirement. Everyone gives their estimate, followed by a discussion if someone is low or high – so that the team can understand the deviation.

Sometimes there is someone on the team who knows that they can leverage code in some way, either through a third-party component or existing library routine that can reduce the effort involved. Other times someone may recognize certain considerations that others have failed to notice. Overall, the vetting process by a team results in fairly reliable estimates.

Another benefit of the team approach is that there will be recognition within the team that certain tasks can and should be performed by a specific individual. Someone may have related experience and be willing to write the code – or at least mentor someone who wants to gain expertise in this area.

The final benefit with a team approach is that you've got a bunch of detail-oriented people examining the requirements from the perspective of those who need to translate what has been provided into software. A team estimating session is a great, early way to catch problems with the requirements, particularly those tacit requirements that detail-oriented people will surface.

Many times there is pressure to starting coding – now. And every time that I’ve short-changed what I know to be solid due-diligence, particularly the up-front work, I’ve regretted it. Do your homework and engage those on the business side with meaningful dialog about what it takes to deliver software.

Over time, trust will be built through a demonstrated command of the facts and by meeting key delivery dates – something that can only happen with realistic estimates. In the end, effective, results-oriented delivery that truly satisfies the business requires a true partnership.