The language they understand is months and dollars (or any other type of currency).

The language they understand is months and dollars (or any other type of currency).

Clients, stakeholders and pointy haired bosses really do care about how long a project will take, how much the project will cost and by extension the effort required to deliver the project. What clients, stakeholders and bosses don’t care about is how much the team needs to think or the complexity of the stories or features, except as those attributes effect the duration, cost and effort.  The language they understand is months and dollars (or any other type of currency). Teams however, need to speak in terms of complexity and code (programming languages). Story points are an attempt to create a common understanding.

When a team uses story points, t-shirt or other relative sizing techniques, they hash a myriad of factors together.  When a team decomposes problem they have to assess complexity, capability and capacity in order to determine how long a story, feature or task will take (and therefor cost).  The number of moving parts in this mental algebra makes the outcome variable.  That variability generates debates on how rational it is to estimate at this level that we will not tackle in this essay.  When the team translates their individual perceptions (that include complexity, capacity and capability) into story points or other relative sizing techniques, they are attempting to share an understanding with stakeholders of how long and at what price (with a pinch of variability).  For example, if a team using t-shirt sizing and two week sprints indicate they can deliver 1 large story and 2 two medium or 1 medium and 5 small stories based on past performance, it would be fairly easy to determine when the items on the backlog will be delivered and a fair approximation on the number of sprints (aka effort, which equates to cost).

Clients, stakeholders and bosses are not interested in the t-shirt sizes or the number of story points, but they do care about whether a feature will take a long time to build or cost a lot. The process of sizing helps technical teams translate how hard a story or a project is into words that clients, stakeholders and bosses can understand intimately.

#NoEstimates  . . .Yes or No?

#NoEstimates . . .Yes or No?


Hand Drawn Chart Saturday!

When I published An Estimation Framework Is Required In Complex Environments, several people that I respect, including Luis Gonçalves (interviewed on the SPaMCAST 282 with Ben Linders), begged to differ with my conclusion that a framework was ever required.  Luis made an impassioned plea for #NoEstimates.  The premise of #NoEstimates is that estimates enforce a plan and plans many times are overcome by changes that range across both technology and business needs.

Vasco Duarte, a leading proponent of #NoEstimate describes the process as follows:

  1. Select the highest value piece of work the team needs to do.
  2. Break that piece of work down into small components.  Vasco uses the term risk-neutral chunks, which means pieces of work that if they don’t get delivered in the first attempt will not put the project at risk.
  3. Develop each piece of work according to the definition of done. #NoEstimates makes a strong case that unless done means anything other than usable by the end customers, the project is not getting the feedback needed to avoid negative surprises.
  4. Iterate and refactor. Continue until the product or enhancement meets the organization’s definition of done.

Estimates are part of a continuum that begins with budgeting, continues to estimating and terminates at planning.   Organizations build strategic plans based on bringing new or enhanced products to market.  For example, a retailer might commit to opening x number of stores in the next year.  If public, once publicly stated, the organization will need to perform to those commitments or face a wide range of consequences.  Based on experience gathered by working in several retailer’s IT organizations, I know that even a single store is a major effort that includes store operations, purchasing, legal and IT.  Missing an opening date causes embarrassment and typically, large financial penalties (paying workers who aren’t working, rescheduling advertising and possible tax penalties not to mention the impact to stock prices).  Organizations need to budget and estimate at a strategic level.

Where the #NoEstimates approach makes sense is at the planning level.  The #NoEstimates process empowers teams (product owner, Scrum Master/coach and development personnel) to work on the highest value work first and to develop a predictable capacity to deliver work.  The results generated by the team provide feedback to evaluate the promises made though organization-level budgets and estimates.

When performance is at odds with what has been promised business choices should be made.  Choices can range from involving other teams (when this makes sense) to accepting the implications of not meeting the commitments made by the organization.

Does #NoEstimates make sense?  Yes, the process and concepts embodied by #NoEstimates fits solidly into a framework of budgeting, estimating and planning.   Without a framework to codify the use of #NoEstimates and to govern organizational behavior, getting to the point of making hard business choices will generate pressure to fall back to command and control fashion.

Note:  I am working on scheduling an interview and discussion with Luis and Vasco on the Software Process and Measurement Cast to discuss #NoEstimates.

Sometimes you need a seeing eye dog to see the solution.

Sometimes you need a seeing eye dog to see the solution.

In the entry, The Top Five Issues In Project Estimation, we identified the five macro categories of estimation problems generated when I asked a group of people the question “What are the two largest issues in project estimation?”  Knowing what the issues are is important, however equally important is having a set of solutions.

  1. Requirements. Techniques that reduce the impact of unclear and changing requirements on budgeting and estimation include release plans, identifying a clear minimum viable product and changing how requirements changes are viewed when judging project success. See Requirements: The Chronic Problem with Project Estimation.
  2. Estimate Reliability. Recognize that budgets, estimates and plans are subject to the cone of uncertainty.  The cone of uncertainty is a reflection of the fact earlier in a project the less you know about the project.  Predictions of the future will be more variable the less you know about the project.  Budgets, estimates and plans are predictions of cost, effort, duration or size.
  3. Project History.  Collect predicted and actual project size, effort, duration and other project demographics for each project.  Project history can be used both as the basis for analogous estimates and/or to train parametric estimation tools.  The act of collecting the quantitative history and the qualitative story about how projects performed is a useful form of introspection that can drive change.
  4. Labor Hours Are Not The Same As Size.  Implement functional (e.g. IFPUG Function Points) or relative sizing (Story Points) as a step in the estimation process. The act of focusing on size separately allows estimators to gain greater focus on the other parts of the estimation process like team capabilities, processes, risks or changes that will affect velocity.  Greater focus leads to greater understanding, which leads to a better estimate.
  5. No One Dedicated to Estimation.  Estimating is a skill that that not only requires but practice to develop consistency.  While everyone should understand the concepts of estimation, consistency will be gained faster if someone is dedicated to learn and to execute the estimation process.

Solving the five macro estimation problems requires organizational change.  Many of the changes required are difficult because they are less about “how” to estimate and more about what we think estimates are, which leads into a discussion of why we estimate.  Organization’s budget and estimate to provide direction at a high level.   At this level budgets and estimates affect planning for tax accruals and for communicating portfolio level decisions to organizational stakeholders.  Investing in improving how organizations estimate will improve communication between CIOs, CFOs and business stakeholders.


Sometimes estimation leaves you in a fog!

Sometimes estimation leaves you in a fog!

When I recently asked a group of people the question “What are the two largest issues in project estimation?”, I received a wide range of answers. The range of answers is probably a reflection of the range of individuals answering.  Five macro categories emerged from the answers. They are:

  1. Requirements. The impact of unclear and changing requirements on budgeting and estimation was discussed in detail in the entry, Requirements: The Chronic Problem with Project Estimation.  Bottom line, change is required to embrace dynamic development methods and that change will require changes in how the organization evaluates projects.
  2. Estimate Reliability. The perceived lack of reliability of an estimate can be generated by many factors including differences in between development and estimation processes. One of the respondents noted, “most of the time the project does not believe the estimate and thus comes up with their own, which is primarily based on what they feel the customer wants to hear.”
  3. Project History. Both analogous and parametric estimation processes use the past as an input in determining the future.  Collection of consistent historical data is critical to learning and not repeating the same mistakes over and over.  According to Joe Schofield, “few groups retain enough relevant data from their experiences to avoid relearning the same lesson.”
  4. Labor Hours Are Not The Same As Size.  Many estimators either estimate the effort needed to perform the project or individual tasks.  By jumping immediately to effort, estimators miss all of the nuances that effect the level of effort required to deliver value.  According to Ian Brown, “then the discussion basically boils down to opinions of the number of hours, rather that assessing other attributes that drive the number of hours that something will take.”
  5. No One Dedicated to Estimation.  Estimating is a skill built on a wide range of techniques that need to be learned and practiced.  When no one is dedicated to developing and maintaining estimates it is rare that anyone can learn to estimate consistently, which affects reliability.  To quote one of the respondents, “consistency of estimation from team to team, and within a team over time, is non-existent.”


Each of the top five issues are solvable without throwing out the concept of estimation that are critical for planning at the organization, portfolio and product levels.  Every organization will have to wrestle with their own solution to the estimation conundrum. However the first step is to recognize the issues you face and your goals from the estimation process.

Just being ready to run does not mean you know all of the requirements.

Just being ready to run does not mean you know all of the requirements.

When I recently asked a group of people the question “What are the two largest issues in project estimation?” I received one response more than any other: requirements, prefixed by words like unclear and changing. In the eight years I have been hosting the Software Process and Measurement Cast I end each interview by asking what two changes could be made to make it easier to deliver better functionality (the actual words vary), and requirements are one of the culprits that appear over and over.  The requirements/estimation conundrum has not changed much over the multiple decades I have been in the software development world.  We have described the budget, estimate and plan continuum that most large projects follow, the estimation “problem” follows the same continuum.

Most large organizations have follow a cycle of budgeting for projects. Plans are immediately put into motion based on the budgets including “guidance” provided to the markets in public companies. The budgets become part of how executives and managers are paid or bonused. In IT, projects can make up a significant portion of C-level and other managers budgets.  Projects at this level generally represent concepts and at best are estimated based on interpolations from analogies. However estimates of cost, duration and revenue are generated by a lot of thought and hardwork.  Anyone that has been in the business knows that the scope of projects at this point are dynamic, But even this early on, the die has begun to be set.  

As programs and projects begin, a better understanding of the central concept is developed.  Based on that better understanding the budget refined however the refinement generally occurs within the boundaries developed and placed in the budget.  I have known project and program managers that tried all sorts of techniques as they fought to respect the stakeholder’s central concept and the need to meet the numbers. Techniques include sourcing decisions (offshoring), buying packages or even shedding known scope.  All of this activity occurs as the concept and the underlying requirements evolve. This issue occurs both in industry and government.

As work begins budgeting and estimating shift to planning.  In waterfall projects, estimators and schedules build elaborate work breakdown plans that help guild team members through the process of delivering value. Each requirement and task is estimated to support the WBS.  [WBS?] This type of behavior also occurs in some pseudo-Agile teams. For work that is highly deterministic this approach may work well, however if the business environment is dynamic or requirements evolve to more fully meet the product owner or other stakeholders needs, it won’t work.

The natural tendency is to eschew budgeting and estimating, to change how public companies report and how executives are paid.  This will happen, but not overnight.  In the interim the best option in most cases is to manage the boundary between estimating and planning using tools like release plans and minimum marketable/acceptable products.  The release plan needs to identify what has to be delivered (minimum marketable/acceptable product) with the nice to haves acting as the buffer that is managed to meet the corporate promises. This approach requires all parties to change some behaviors, such as over-promising by both IT and stakeholders and treating IT less like a factory and more like a collaborative venture.  Both are difficult  changes but just holding out for better requirements has not worked for decades and probably won’t get better soon.

Portfolio Estimation?  A life coach might help!

Portfolio Estimation? A life coach might help!

I recently asked a group of people the question “What are the two largest issues in project estimation?”   The group were all involved in delivering value to clients either as developers, testers, methodologists and consultants.  The respondents experience ran the gamut from Scrum and eXtreme through Scaled Agile Framework (SAFe) and Disciplined Agile Development (DaD) to waterfall.  While not a scientific survey, the responses were illuminating.  While I am still in process of compiling the results and extracting themes, I thought I would share one of the first responses: all resources are not created equal.  The respondent made the point that most estimating exercises, which begin at the portfolio level, don’t take into account the nuances of individual experience and capacity when projects are “plucked” from a prioritized portfolio to begin work.  This problem, at the portfolio level, is based on two issues.  The first is making assumptions are based on assumptions and the second is making decisions based on averages.  At the portfolio level both are very hard to avoid.

Nearly all organizations practice some form of portfolio management.  Portfolio management techniques can be range from naïve (e.g. the squeaky wheel method) to sophisticated (e.g. portfolio-level Kanban).  In most cases the decision process as to when to release a piece of work from the portfolio requires making assumptions about the perceived project size and organizational capabilities required to deliver the project. In order to make the assumptions, a number of assumptions must be made (a bit of foreshadowing, assumptions made based on assumptions are a potential problem).  The most important set of assumptions that are made when a project is released is that the requirements and solution are known.  These assumptions will affect how large the project needs to be and the capabilities required to deliver the project. Many organizations go to great lengths to solve this problem.  Tactics used to address this issue include trying to gather and validate all of the requirements before starting any technical work (waterfall), running a small proof-of-concept project (prototypes) to generating rapid feedback (Agile). Other techniques that are used include creating repositories that link skills to people or teams.  And while these tools are useful for assembling teams in matrix organizations, these are rarely useful at the portfolio level because they are not forecasting tools. In all cases, the path that provides the most benefit revolves around generating information as early as possible and then reacting to the information. 

The second major issue is that estimates and budgets divined at the portfolio level are a reflection of averages.  In many cases, organizations use analogies to generate estimates and initial budget numbers for portfolio-level initiatives.  When using analogies an estimator (or group) will compare the project he or she is trying to estimate to completed projects to determine how alike they are to another. For example, if a you think that a project is about 70% the size of a known project, simple arithmetic can be used to estimate the new project.  Other assumptions and perceptions would be used to temper the precision.  Real project performance will reflect on all of the nuances that the technology, solution and the individual capabilities generate.  These nuances will generate variances from the estimate.  As with the knowledge issue, organizations use many techniques to manage the impact of the variances that will occur.  Two popular methods used include contingencies in the work breakdown schedule (waterfall) and backlog re-planning (Agile). In all cases, the best outcomes are reflective of feedback based on performance of real teams delivering value. 

Estimates by definition are never right (hopefully close). Estimates (different than planning) are based on what the estimator knows very early in the process.  What really needs to be built becomes know later in the process after estimates and budgets are set at the portfolio levels.  Mature organizations recognize that as projects progress new information is gathered which should be quickly used to refine estimates and budgets. 

Trail Length Are An Estimate of size,  while the time need to hike  is another story!

Trail length is an estimate of size, while the time need to hike it is another story!

More than occasionally I am asked, “Why should we size as part of estimation?”  In many cases the actual question is, “why can’t we just estimate hours?”  It is a good idea to size for many reasons, such as generating an estimate in a quantitative, repeatable process, but in the long run, sizing is all about the conversation it generates.

It is well established that size provides a major contribution to the cost of an engineering project.  In houses, bridges, planes, trains and automobiles the use of size as part of estimating cost and effort is a mature behavior. The common belief is that size can and does play a similar role in software. Estimation based on size (also known as parametric estimation) can be expressed as a function of size, complexity and capabilities.

E = f(size, complexity, capabilities)

In a parametric estimate these three factors are used to develop a set of equations that include a productivity rate, which is used to translate size into effort.

Size is a measure of the functionality that will be delivered by the project.  The bar for any project-level size measure is whether it can be known early in the project, whether it is predictive and whether the team can apply the metric consistently.  A popular physical measure is lines of code, function points are the most popular functional measure and story points are the most common relative measure of size.

Complexity refers to the technical complexity of the work being done and includes numerous properties of a project (examples of complexity could include code structure, math and logic structure).  Business problems with increased complexity generally require increased levels of effort to satisfy them.

Capabilities include the dimensions of skills, experience, processes, team structure and tools (estimation tools include a much broader list).  Variation in each capability influences the level of effort the project will require.

Parametric estimation is a top-down approach to generating a project estimate.  Planning exercises are then used to convert the effort estimate into a schedule and duration.  Planning is generally a bottom-up process driven by the identification of tasks, order of execution and specific staffing assignments.  Bottom-up planning can be fairly accurate and precise over short time horizons. Top-down estimation is generally easier than bottom-up estimation early in a project, while task-based planning makes sense in tactical, short-term scenarios. Examples of estimation and planning in an Agile project include iteration/sprint planning, which includes planning poker (sizing) and task planning (bottom-up plan).  A detailed schedule built from tasks in a waterfall project would be example of a bottom-up plan.  As most of us know, plans become less accurate as we push them further into the future even if they are done to the same level of precision. Size-based estimation provides a mechanism to predict the rough course of the project before release planning can be performed then again, as a tool to support and triangulate release planning.

The act of building a logical case for a function point count or participating in a planning poker session helps those that are doing an estimate to collect, organize and investigate the information that is known about a need or requirement.  As the data is collected, questions can be asked and conversations had which enrich understanding and knowledge.  The process of developing the understanding needed to estimate size provides a wide range of benefits ranging from simply a better understanding of requirements to a crisper understanding of risks.

A second reason for estimating size as a separate step in the process is that separating it out allows a discussion of velocity or productivity as a separate entity.  By fixing one part of the size, the complexity and capability equation, we gain greater focus on the other parts like team capabilities, processes, risks or changes that will affect velocity.  Greater focus leads to greater understanding, which leads to a better estimate.

A third reason for estimating size of the software project as part of the overall estimation process is that by isolating the size of the work when capabilities change or knowledge about the project increases, the estimate can more easily be re-scaled. In most projects that exist for more than a few months, understanding of the business problem, how to solve that problem and capabilities of the team increase while at the same time the perceived complexity[1] of the solution decreases. If a team has jumped from requirements or stories directly to an effort estimate  it will require more effort to re-estimate the remaining work because they will not be able to reuse previous estimate because the original rational will have change. When you have captured size re-estimation becomes a re-scaling exercise. Re-scaling is much closer to a math exercise (productivity x size) which saves time and energy.  At best, re-estimation is more time consuming and yields the same value.  The ability to re-scale will aid in sprint planning and in release planning. Why waste time when we should be focusing on delivering value?

Finally, why size?  In the words of David Herron, author and Vice President of Solution Services at the David Consulting Group, “Sizing is all about the conversation that it generates.”  Conversations create a crisper, deeper understanding of the requirements and the steps needed to satisfy the business need.  Determining the size of the project is a tool with which to focus a discussion as to whether requirements are understood.  If a requirement can’t be sized, you can’t know enough to actually fulfill it.  Planning poker is an example of a sizing conversation. I am always amazed at the richness of the information that is exposed during a group-planning poker session (please remember to take notes).  The conversation provides many of the nuances a story or requirement just can’t provide.

Estimates, by definition, are wrong.  The question is just how wrong.   The search for knowledge generated by the conversations needed to size a project provides the best platform for starting a project well.  That same knowledge provides the additional inputs needed to complete the size, complexity, capability equation in order to yield a project estimate.  If you are asked, “Why size?” it might be tempting to fire off the answer “Why not?” but in the end, I think you will change more minds by suggesting that it is all about the conversation after you have made the more quantitative arguments.

Check out an audio version of this essay as part of  SPaMCAST 201

[1] Perceived complexity is more important than actual complexity as what is perceived more directly drives behavior than actual complexity.

A good framework helps Agile and waterfall teams flow together.

A good framework helps Agile and waterfall teams flow together.

A process framework provides a common language and outline to estimate.  The outline provides a scaffold into which project or program specific processes and functions can be inserted. An estimation framework will define a structure for estimation, the relationship between how estimation is being performed and both other engineering processes and program and portfolio level processes.  For example, in a program with Agile and waterfall teams, a framework would define how estimates generated by the different teams would relate and integrate.  A framework helps estimation become a repeatable process and also to help organizations institutionalize estimation.

A repeatable process, defined as a common set of actions that ensure the efficient use of resources and reduce variation, provides the routines needed for teams focus their creativity on delivering value rather than defining process. Reducing variation does not mean that Agile teams have to estimate the same way as waterfall team, rather that they follow a process that is appropriate to Agile methods. For example Agile teams leveraging a framework that called for estimates might use a combination of story points, planning poker and capacity while waterfall teams used parametric estimation processes. The more complex the project or program environment, the more useful frameworks are in reducing variability as teams do not have determine how estimates should be done and how they should integrate.

An institutionalized process is a process or set of processes that have become part and parcel of how team or organization delivers value. An estimation framework helps both teams and organizations know when and where to perform estimation so that performing the process is ingrained. Processes that are institutionalized don’t revert to chaos or into redefinition mode when projects are stressed; muscle memory takes over and the work gets done in an appropriate manner.

An estimation framework in a complex (but typical) IT organization must account for the needs of not only Agile team and waterfall teams, but also project, programs and portfolios that have teams that are using different techniques. Couple that with project and program offices that have different reporting requirements (some regulatory and/or contractual) and estimation needs get complicated.  Defining a framework so that all parties understand what needs to happen, when it needs to happen and the information that needs to be shared is not just important, it is required. 

Estimates are an approximation of effort, duration and cost of a project based on number of factors.

Estimates are an approximation of effort, duration and cost of a project based on number of factors.

Estimates are an approximation of effort, duration and cost of a project based on number of factors.  Factors include project size, nature, methods, techniques, life cycles, forecast team capabilities and perceived risks.  All estimates seek to account for these factors more or less explicitly. The number of factors accounted for explicitly is generally a measure of estimation process maturity. Factoring project risks into the estimate is an important step for improving the maturity of all estimation processes and an important step in developing solid estimates.  Project risks are important to understand because they foreshadow variability in a team’s level of performance.  Risks that become issues can impact productivity, time-to-market and cost.

In A Framework for Evaluating Agile Risk Management, I leveraged the macro-framework described by Tom DeMarco and Tim Lister in their book, Waltzing with Bears DeMarco and Lister identified five risk categories:

  • Intrinsic Schedule Flaws – A schedule flaw of any type will require additional planning, reporting and could potentially increase the effort and cost of the project.
  • Specification Breakdowns – A problem in the requirements can cause a myriad of problems ranging from rework to project failures.
  • Scope Creep – Scope creep represents a project adding scope with approval (such as backlog grooming in Agile or change control boards in waterfall projects).
  • Personnel Loss – Losing key personnel will impact the capability of the team(s) which could impact the cost, duration and schedule.
  • Productivity Variance – Productivity varies based on factors that include complexity and technology, estimates are generally created before all of the factors impacting productivity are known.

Risks that evolve and become issues (remember risks represent a possibility that something will happen) will affect the effort, cost and/or duration need to deliver a specific project. During the estimation process whoever is doing the estimate needs to account for the potential impact of risks on the project estimates.  

Risks can be expressed in terms of probability and impact. In Agile and Risk Management, Part 2 we defined impact as the effort that would be required to fix the issue and the probability of occurrence.  Using this framework to qualify risk, it is very apparent that risks represent a potential impact.  A heavy-handed approach to account for the impact of risk would be sum the potential impacts and add the result to the effort estimate.  The effort estimate could then be converted into duration (staffing models and release plans) and into cost.  

A more nuanced approach would leverage that same data to establish a range of productivity rates (output per unit of effort – function points per person month).  Productivity rates are a reflection of historical performance within an organization which reflect how change or project shocks affect performance. The range could then be weighted by probability to establish the estimate.  Monte Carlo analysis is a more advanced approach to incorporating the variability generated by risk into the estimate.  

Project risks don’t impact estimates, however the anticipation of the potential of a risk actually occurring should impact estimates.  The degree of effect is a matter of probability and potential bottom-line impact.

Would you be satisfied if you paid for five cabbages, but got only four?

Would you be satisfied if you paid for five cabbages, but got only four?

Estimates and customer satisfaction are intertwined because they set expectations. Estimates set the development team’s expectations about resources that will be available to deliver the project, including effort, people, calendar time.  From the customer’s point of view, an estimate will generate expectations about what will be delivered, when it will be delivered and what the project will cost.  The dark side of estimation is that once an estimate is even whispered, it quickly become set in stone and gains the power to dissatisfy. 

A project estimate is an outline of the resources that the team or estimator needs to deliver a given scope of work.  Regardless of the ultimate veracity, most organizations require an estimate for a project to secure funding and team resources.  Estimates create parameters that the team(s) will operate within.  Missing an estimate, whether due to lack of information, increased scope or changing business decisions, will impact other projects.  This ripple effect impacts other projects as overall portfolio is adjusted to deal with changing realities. This leaves very few within the IT department satisfied. 

IT customers and stakeholders have been trained that they need to ask how much a project will cost before they begin and many have been trained that answer is at best a guess.  However, it is a guess to which they will hold the team.  This leads teams to pad the estimate in a vain attempt to not to have break the news that something that was not anticipated (and probably could not be anticipated) has caused the estimate to be wrong.  The project estimate, which is typically generated at the point in a project where the team knows the least about what will be needed to deliver the customer’s vision, generates a substantial anchor bias.  The anchor puts teams and their customers in an almost immediate customer satisfaction hole that is difficult to remediate. 

Most customers and stakeholders have purchased large ticket items, like a car, and paid the negotiated price.  A significant proportion have purchased products that either had to be customized for them, including clothing (suits or prom dresses) or houses.  Rarely do the prices vary significantly from the negotiated price. But, those of us in the business would challenge the relationship between these examples and developing, enhancing or supporting software. However most of customers and stakeholders would not be impressed with the distinction.  When pressed they will be happy to tell you that they can find a supplier to meet their needs for a fixed price (and someone will always say yes).

Why should project teams care about customer satisfaction?  Simply put:

  • Customers supply the budget or pay the bills.
  • Selling to happy customers costs far less than finding new customers.
  • In the long run ALL customers can change suppliers (internal or external).
  • Happy customers promote your team or organization.
  • Satisfaction leads to less in-fighting and better relationships.

In the end, unless we can change the estimation landscape, we will need to get better at estimation if we want to keep our customers satisfied. In part this means that we need to include more people in the process and to hone our ability to predict the future.  

« Previous PageNext Page »