Selling Your Software Estimate

In many instances the software industry continues to flounder when it comes to understanding how to properly plan and manage software development project. One need not look far to find evidence that software project planning and management is a complicated challenge. Software estimating is indeed a hard thing to do. But often the problem goes deeper than that. There are many practitioners in our industry who have mastered this skill and still we seem to have way too many projects failing. Software projects often fail not because software professionals lack the proper estimation skills but rather because they lack the skills to negotiate successfully with business leaders during the planning phase and throughout the life of the project. This paper discusses the importance of well reasoned and purposeful negotiation in selling an estimate to a business or customer and presents some strategies for planning and executing such a negotiation.

Introduction

Having spent almost 30 years in the software industry, I think I can safely say that we continue to flounder when it comes to understanding how to properly plan and manage software development projects. One need not look far to find evidence that software project planning and management is a complicated challenge. Quantity is illusive when discussing software, making it hard to determine how ‘big’ a software project is likely to be. Even in situations where software projects are properly sized, they have a tendency to grow once underway. Software technology is constantly evolving, complicating translation of past performance into future predictions.

It’s true. Software estimation is a hard thing to do. Despite this there are many practitioners in our industry who have mastered this skill. And yet we still seem to have way too many software projects failing. It is this author’s theory that the estimating challenges cited in the previous paragraph are only part of the problem. Software projects often fail not because software professionals lack the proper estimation skills but rather because they lack the skills to successfully negotiate with business leaders during the planning phase and throughout the life of a project.

Project leaders don’t want to embark on projects that are destined to fail – they want their projects to be successful. On the other hand they do want to perform in ways that make the business and its leaders happy. Sometimes these two goals are in violent conflict because the business needs are greater than the resources that the business chooses to apply to meeting these needs. It is often the job of the project leaders to bring this to the attention of the business. No one likes to have to tell the boss no. It is often easier to capitulate, hope for the best and save the bad news for later. This is generally a bad strategy and often leads to project failures.

Decisions around project planning and the management of an on-going software project should be based on cold hard facts – not solely on what the business wants or expects nor on the project teams best guess. Ideally every project decision represents the results of collaboration between the business and the project leaders to develop a plan that delivers to the business an optimal set of capabilities for the investment the business is willing to make for such capabilities. Unfortunately this is not always the case. While it is generally true that all stakeholders in a project have the greater good of the business as a goal, there is often not consensus on how best to drive to this greater good or even as to what constitutes this greater good. And there are individual agendas to contend with as well.

Collaboration requires negotiation. The business wants a certain set of features or capabilities from the project team. Naturally they desire to minimize the time and cost associated with getting these features while also expecting the features to be of a specified degree of quality. The project team wants to deliver quality features and they want to ensure that they have sufficient time and people to make that happen. They also want to prevent ending up in a ‘death march’ situation. The project team develops a plan that to the best of their knowledge satisfies all parties. When this plan is presented to business leaders, one of three things might happen:

• The business leaders accept the plan as is because there is trust between the business leaders and the project team – most likely based on a track record of good planning and estimation.
• The business leaders reject the plan and insist on a specific plan that aligns with their cost and schedule targets.
• The business leaders feel that the plan is too costly or the schedule is too long. This opens the door for a negotiation

The focus of this paper is the third case. Strategies are presented to facilitate properly preparing for and executing a negotiation around a project plan and the underlying estimate.

According to BusinessDictionary.com a negotiation is a bargaining (give and take) process between two or more parties (each with its own aims, needs, and viewpoints) seeking to discover a common ground and reach an agreement to settle a matter of mutual concern or resolve a conflict. In our case, negotiation is the process through which the project and the business come to an agreement on what is a reasonable set of capabilities the project team can deliver given the resources and time the business chooses to devote to obtaining those capabilities. It is important to remember that this negotiation is most likely not a one-time event. Software projects are notorious for change. Good project leadership will update the project plan with project changes. Each of these updates may set the stage for additional negotiations. The secret to success with this kind of a negotiation is preparation.