Too many projects are late, over-budget, under-delivered, or a combination.  The problems continue despite widespread awareness and improvements in project management knowledge, tools, and process maturity.  

A recent piece in the Washington Post business section identified a likely culprit: “the planning fallacy”.  Princeton psychologist Daniel Kahneman and Amos Tversky of Stanford describe it as “the tendency to underestimate the time, costs, and risks of future actions and overestimate the benefit of those actions”.  The results are time and cost overruns as well as benefit shortfalls.  The concept is not new: the pair coined the term in the 1970s and has been researching it since.

According to the Post, cognitive biases such as optimism bias (the tendency to expect positive outcomes from one’s actions) and overconfidence can be causes of the planning fallacy. There is a growing body of evidence, collected by researcher Bent Flyvbjerg at Oxford University, that optimism bias is an important bias affecting the quality of forecasts in project planning. 

Other explanations of the fallacy include possible intentional and deliberate considerations on behalf of the planner - such as incentives, organizational pressures and strategic deception. 

Our recent webinar, Agile Estimation: Beyond the Myths, Part 1, presented by Andy Berner, featured a lively Q&A session. Here are a few of the highlights that you can catch in the PDU-approved replay.

Q: You talked about different types of work and how they're done concurrently. What about the work of developing the system architecture?

A: How architecture is determined in agile projects is a really interesting question. Grady Booch, who is one of the great proponents of software architecture used to say that the biggest difference of opinion between him and Kent Beck, who is thought of as the inventor of agile, was the extent to which architecture is planned versus evolved. So there's controversy, but I think all agile methodologists would agree that some basic architecture constraints are an input to the coding work, and thus we would consider that as part of "getting to ready," and also agree that some detailed architecture decisions evolve along with the detailed design as part of “getting to done.” So it's split.  The more complex the project, the more likely you’ll need strong architectural input that was part of "getting to ready" and should plan more architectural effort as part of the "getting to ready" portion.

Q: Can you create an agile estimate using function points as an input?

Beginning with the release of SLIM-Suite v8.1, two new SLIM-Estimate solution methods were added to let you see what a “typical” project would look like: that is, the resources it would require, based upon historical projects from either the QSM database or your own.  The two methods are:

• Solve from Trends Wizard
• Trend Based Solution

SLIM-Estimate provides several different ways to solve the software production equation and produce an estimate.  The solution method you select depends upon the information you have available.  The traditional methods, known as Quick Estimate Wizard and Detailed Method, take inputs of Size and Productivity (PI), and calculate Effort and Time.  The Solve for Size Wizard, perfect for time-boxed estimates, takes inputs of Time, Effort, and PI, and determines the amount of functionality that combination of resources can produce.

The trend solutions require only one input – Size.  Using the specified Primary Trend Group, Time and Effort are read from the average trend line and productivity (PI) is calculated.  These methods extend the capabilities of producing a defensible project estimates very early in the life cycle.  You can determine the feasibility of project goals, assess risk, and manage stakeholder expectations even if all you can estimate is a relative application size, expressed as a “T-shirt” or bin size, as shown in the figure below.

Enterprise application capacity planning is a difficult juggling act. On one side of the equation you have business demand, looking for innovative technology to help improve business performance and increase profitability. The IT organization stands on the other side of the equation, responsible for satisfying these demands. The capacity of this team is limited by the organization’s facilities, the number of developers and their specific skills, and the infrastructure and tools they use. This leaves the business and technology executives in the unenviable position of trying to balance the demand for IT development with the current capacity levels. In this article for Software Magazine, Doug Putnam and Taylor Putnam-Majarian demonstrate how top-down parametric estimation can be leveraged by organizations to manage capacity and demand effectively.

Read the full article!

If you were unable to attend our recent webinar, QSM's Software Sizing Infographic: A Visual Aid for Understanding Software Size, a replay is now available.

Software size, the amount of functionality in a given software release, is arguably the most critical of the five core metrics of software estimation. There is little point in tracking effort, duration, productivity and quality if you are unable to quantify what you are building. Yet, despite its critical importance, software sizing is often a difficult concept for many to understand and use properly in the estimation process. In this webinar, Joe Madden gives an overview of QSM's Software Size Matters Infographic, which addresses the challenges of measuring software size and identifies the most popular sizing methods and when to use them. With over 17 years of software sizing experience, Joe provides case studies and best practices for real world application.

Watch the replay!

When an organization wants to proactively manage their software activities from inception through development and sustainment, an enterprise software estimation or acquisition Center of Excellence (COE) is a great solution.  A significant portion of our professional services business at QSM is helping companies design and stand up enterprise COE operations. 

There are three main components to a successful COE implementation.  They are:

1. People – Finding people with the right characteristics and developing their skills;
2. Business Processes – developing the right business processes to support decision making; and
3. Tools – Acquiring and configuring analytical tools to support the business processes.

Our clients often ask us to identify the best characteristics and skills for a person that they plan to staff into a COE.  We went back and looked at our most successful implementations, and here is what we found.

Ideal Enterprise COE Skill Set:

There is an old adage that if your only tool is a hammer, everything looks like a nail.  We use the lessons learned and experience we have gained to address current issues.  But if the problem (or software project) we face today is fundamentally different from those we’ve dealt with previously, past experience isn’t the proper framework.  In effect, we will be using a hammer when a saw or a chisel might be the tools we need.

The solution, of course, is to first gain an understanding of the problem at hand.  What are its defining features?  How does it behave?  Only then can a proper solution be designed and the appropriate tools selected.

To a large degree, our understanding of how products are developed comes from knowledge gained from manufacturing since the beginning of the Industrial Revolution.  Mentally, our first instinct is to try to apply those lessons learned to software development.  But there is a huge problem with this approach. The creation of software is not a manufacturing process, but rather a knowledge acquisition and learning process that follows different rules.  Here is a simple example.  If I have an assembly line and want to double my output, I have several choices.  I might add a second shift of workers or I could install an additional assembly line.  Because manufacturing is a repetitive process in which design problems are solved before product construction begins, the relationship between labor required and output remains fairly constant.  In a nutshell, we already know exactly what we need to do (and how to do it).