It happens time and time again. Clients look to their vendors to provide software development or configuration services and both sides are often left with big questions. Is the price fair? Can we really get the project done within our duration and resource goals? How can we negotiate for a successful outcome?

There are estimation solutions available that can help. The good ones will leverage empirically-based models, historical data, and industry analytics to uncover which proposals are feasible and which ones are risky.

In the first view below, there are two columns: the “Desired Outcome,” which is one vendor’s proposal and the second column, which is the data-driven “Recommended Estimate.”  The vendor is promising to complete the work in 3 months with a $750,000 price tag. You can see that this proposal is “Risky” and that the vendor will probably finish late and will either have to ask for more money or lose money in the long run.  The charts in the view provide a graphical representation.

In the second view for the same project, you see a second vendor’s proposal compared to the “Recommended Estimate.” The vendor’s bid is for 8 months with a $1,000,000 price tag and there is a “Moderately Conservative” rating. In other words, this vendor has a much better chance of achieving what they are promising. 

If you've been using SLIM-Collaborate's convenient, web-based project access to keep your stakeholders engaged and informed, you know SLIM-Collaborate offers streamlined, role-based estimation and data collection services designed to complement our feature-rich desktop tools. SLIM-Collaborate's simplicity and ease of use make it easier to promote consistent standards and practices to users across the enterprise, while seamless data exchange with the SLIM desktop tools lets your most experienced users leverage the power of advanced features.

Recently we talked with SLIM-Collaborate users, and one request stood out: they wanted us to bring Contingency planning into SLIM-Collaborate.  Release 3.1 of SLIM-Collaborate does just that, and even adds new risk buffering capabilities to the probability-based risk modelling available in SLIM-Estimate.  Here's how it all works.

Step 1: Create Reusable Contingency Profiles (Back Office)

Part of SLIM-Collaborate's innovative approach lies in letting experienced users (the "Back Office") analyze the business, then design and publish reusable building blocks (templates, trends, filters, dashboards, profiles) that simplify and standardize estimation and data collection for less experienced users. 

QSM has recently released an update to the feature-rich SLIM-Suite of tools.  For a detailed list of updates, download the SLIM-Suite 10.1 release notes. The 10.1 desktop release updates the look and feel of SLIM-Suite tools with easier-to-read fonts and a cleaner, simpler color palette inspired by modern Business Intelligence and Data Analysis applications. A new, high resolution theme also offers better support for high DPI and high resolution monitors.

Bird's Eye Staffing View

Many of the visual updates are subtle, so this post will cover the high impact features you're likely to notice on upgrading to SLIM-Suite 10.1. In SLIM-Estimate, cross-hatched phase shading on time series charts has been replaced by lighter, transparent curve fills that grow progressively darker for successive phases.  The view below shows staffing over time, not broken out by role, for a project using a traditional lifecycle.

Detailed Staffing View

Agile projects may prefer a more granular view of project staffing by role, with sprints delineated over the project timeline:

Task-Based Schedule View

Agile is all the rage today and companies are investing lots of capital to work within agile frameworks. Are these new methods the key to reducing project failure? When projects get behind schedule, a common reaction is still to add more people. Doug Putnam recently examined 390 contemporary applications of the same size, a significant portion of which used agile methods and tools, to see what matters more - staffing decisions or methodology. He discovered that while the additional staff reduced the schedule by approximately 30%, the project cost increased by 350%. The additional staff also created 500% more defects that had to be fixed during testing. Over the past 15 years, QSM has performed this same study in five-year increments and has found the same results -- staffing decisions have more of an impact on project success than any development methodology. In this article, Doug Putnam identifies a staffing "sweet spot" and outlines a step-by-step planning process  that uses predictive analysis and early estimation to more accurately account for staffing needs.

Read the article!

We hear a lot about software projects that are too large or attempt to do too much in too short of a time.  They are very visible and negatively impact both budgets and careers in a not positive manner when they fail.  Small projects may fly under the radar.  This is a mistake.  Most IT projects aren’t large undertakings like Healthcare.gov; rather, they are enhancements and customizations to already existing software systems and account for the majority of most enterprises’ software budget.  Planning these projects to be optimally productive is an area in which most companies can realize the greatest returns.

How do you know what is the optimal amount of software to develop in a project?  In a newly published software benchmark study QSM analyzed productivity, cost/effort, and time to market of a large sample (over 600) of business IT projects that have recently completed.  The projects were divided into quartiles based on the amount of software they developed or customized, which were then compared to each other.  Fully ¼ of the projects were smaller than 3,200 implementation units in size or 68 function points for projects that used that size measure.  Projects in this quartile had a median productivity of 200 IU per staff month or 5 function points per staff month.  The median duration of these projects was slightly more than 3 months. The second quartile contained projects from 3,200 IU up to 8,000 (or 69 to 149 function points).  These projects had a median productivity of 377 IU per staff month (or 7.62 function point per staff month) and lasted a little more than 5 months.  This is a productivity improvement of 89%.  The smaller projects were markedly less productive.  So, simply by bundling software work into larger packages there are significant efficiencies to be gained.

As the Apps Global CTO for Microsoft Services, Lenny Fenster sees the need for estimation in many shapes and sizes throughout the world. In his twenty years at Microsoft, Lenny has also seen many different attempts to improve how Microsoft Services estimates time and effort for software development projects. Not all of them have hit the mark. In this presentation for the QSM 2018 Virtual Conference, Lenny talks about the evolution his team is driving in Microsoft Services to improve the maturity, consistency, and defensibility of software estimation for some of the largest and most complex software projects in the world. He talks specifically about the intentional separation of scope and estimation and the use of SLIM as a key ingredient in the success they are now having. Estimates are now done much quicker, reducing the time to run an estimate from days to just 4.5 hours.  

Lenny was gracious enough to answer questions throughout his presentation about the estimation process at Microsoft Services. This sparked great participation from our audience, who asked a number of questions worth resharing. Here are the highlights:

Q: Did you experience any resistance among the architects in changing the way they did estimation to a new approach?­

QSM would like to thank our fantastic presenters and all that attended our virtual conference. More than just one-dimensional presentations, each session included interactive Q&As with active participation from our audience. It was great to hear such a wide variety of presentations covering project management success in many different areas, including the return on investment from estimating agile projects, the application of the SLIM tools to government outsourcing programs, and the benefits of leveraging flexible sizing techniques and QSM estimation methods. If you were unable to attend last week, you can find replays of all of the presentations below. We encourage you to reach out with any additional questions or feedback.

QSM turns 40 this September! To celebrate this milestone, we will be hosting a free, all-day virtual conference on September 19th for current clients and those looking to learn more about software estimation best practices. The conference will feature presentations from IBM, Microsoft, Progressive Insurance, Rockwell Automation, and KPMG, as well as new developments in QSM research and tools. Below you will find a list of speakers and presentations. 

• "Our Evolution Around Estimation" - Lenny Fenster, Microsoft Services

• "Strengthening Estimation Governance in a Large-Scale Organization with SLIM-Collaborate" - Christophe Guillou and Angelo Moore, IBM Global Services

• "Using Project History to Produce Estimates" - Daniel Horvath, Progressive Insurance

• "Big Rock Estimation with SLIM Estimate" - Aaron Jeutter, Rockwell Automation

• "Five Core Metrics to Reduce Outsourced Software Project Failure" - Joseph Madden, KPMG

• "Understanding the Physics of Software Development" - Larry Putnam, Jr., QSM

• "The Evolution of SLIM-Suite Tools" - Kate Armel and Laura Zuber, QSM

You can find the speaker's bios and abstracts here. Click here to register.

In many agile environments, the budget, team size, and schedule are fixed based on an organization’s predetermined targets for sprints or iterations. This leads many project managers to question if software estimation is even necessary. The problem is, without a reliable size estimate, the amount of functionality promised within the time and money constraints could be difficult to achieve and could cause the product delivery to be short on features, or late and over budget.

This is where scope-level estimation tools come into play. They can help evaluate whether targets are reasonable and, even if the schedule and budget are both set in stone, they can help figure out how much work can be delivered. This type of analysis helps set customer expectations and provides data driven leverage for negotiations.

The best estimation tools leverage empirically-based models, industry analytics, and historical data. They can even be used before iteration level planning takes place. They ensure that the overall goals are reasonable before detailed plans are developed. 

In the three views below, we see an estimate generated from a “Time Boxed” method. This is where the product manager was able to input the predetermined time, a productivity measure (PI), and a team size, to see how many story points could be completed within the set constraints. The analysis also includes a “sanity check” of the estimate, comparing it to an agile industry trend from the QSM Industry Database and their own agile historical data.

The application of contingency buffer, more commonly known as “padding” or “management reserve” is the final step in any project estimation process.  The most common practice is for the estimator to use an intuitive multiplier which is added to base estimate.  Unfortunately, everyone has a different multiplier which is shaped by their own personal bias about risk and it is hidden in their head.  This creates a fundamental problem with transparency and consistency within most organizations.

Fortunately, there's a better way.  One solution is to define and configure agreed upon standards that are matched to specific business risk situations.  These should be collaboratively agreed to by all the stake holders in the organization.  Then they can be codified into a configuration that can be selected at the time when contingencies are typically applied to an estimate.  This helps solve the consistency issue.

To attack the transparency issue, you can use a technique of overlays to visualize the contingency in comparison to the base estimate.