In software estimation, some discovered relationships turn out to be true primary principals of software development.

Way back in 1978, Larry Putnam, Sr. discovered that the relationship between project duration and project effort was exponential.¹  His equation equated to:

Duration in months = 2.15 times the cube root of effort in manmonths

In his 1981 book, Barry Boehm described the nominal relationship in COCOMO² as:

Duration in months = 2.5 times the cube root of effort in manmonths

Very similar results.  Is that something specific to the way projects were managed way back then?  Or, is this a true fundamental law of software project management?

Sometimes, it is fun and also informative to revisit pioneering work to see how things have (or have not!) changed over the decades since.  I have used updated benchmarking data to check this staffing relationship and found it to be surprisingly persistent. 

I took project Main Build (Design through Test) effort and Main Build duration from the QSM database, for projects that have competed in the 21^st century.

The following graph has duration in months on y axis, and effort in personmonths on x axis.

The exponential regression shows that the “nominal” duration of these projects = 2.0 x cubed root of effort.  

Many of the project managers that I speak with track their software and systems projects at a very detailed level. They use detailed spreadsheets or other tools to track hours and tasks on a daily basis. This is fine, but it's important to manage the big picture so we can avoid assigning detailed tasks to duration and budget goals that are unrealistic.

By "big picture" I mean tracking at the project release level and focusing on a few key actuals: size, duration, effort, reliability, and efficiency. It's important to track these actuals to a reliable plan. These are the measures that can give us the biggest and quickest insight into a project’s potential success or failure. You can see this analysis in the SLIM-Control graphs below, showing the blue plans versus the red actuals.

Once the project is underway and we start tracking the actuals, we can generate new project forecasts based on the actual work delivered, time elapsed, and effort spent. These new forecasts are empirically-based. This will enable us to adapt to change requests, see when the project will finish and how much it will cost. The SLIM-Control graphs below show the blue plans versus the red actuals plus the new forecasts shown in white. SLIM-Control is curve-fitting to the actuals and running empirically-based mathematical models to generate the new forecasts.

The staff build-up plan defines how many, what kind, and when staff are needed for the entire project. Too many or too few, bringing them on too early or late, employing the wrong mix of expertise or experience - avoiding all these pitfalls with a staff build-up plan will ensure a successfully staffed project. Reviewing proposals for a complex project, such as major software development or support, is a challenging activity. Since labor is the major cost and feasibility determinant for such projects, requiring the submission of a "staff build-up plan" and verifying its realism is crucial in determining whether a proposed project can realistically succeed. In this article for Contract Management Magazine, QSM's Gene Shuman identifies the key components of an effective staff build-up plan.

Read the full article!

QSM is pleased to announce we have recently been selected as one of the 20 Most Promising Productivity Tools Solution Providers by CIO Review. In the last few months, CIO Review has analyzed hundreds of productivity tools solution providers and shortlisted the companies that are at the forefront of tackling challenges in the arena. A distinguished panel comprising of CEOs, CIOs and analysts including CIO Review’s editorial board has selected the final list of Productivity Tools Solution Provider of 2015. In their selection process, they looked at the vendor’s capability to fulfill the need for cost-effective and flexible solutions that add value to the productivity tools landscape.

QSM establishes a productivity baseline for its customers’ projects, identifying immediate opportunities for improvement, while providing the ability to measure the return-on-investment (ROI) once those improvements have been implemented. QSM's Software Lifecycle Management (SLIM) tools support better decision making at each stage of the project development lifecycle.

Read the full report.

Let’s face it -- times have changed since the initial principles of predictive analytics and software estimation were established. Today more than ever, we live in a time where there is an incredible dependence on software – it is the cornerstone of almost every business. Risk management and cyber vulnerabilities are now major concerns that weren’t even on the radar decades ago. 

The 2016 version of the QSM Almanac, released earlier this week, takes a truly unique look at the last 35 years of predictive analytics and estimation for business intelligence to determine if its previously developed principles are still applicable today, and, if so, how those principles apply to the current state of software projects. The results are somewhat incredible, and I thought I could share a few of the highlights from this year’s resource as a preface to the full (and free) Almanac, which can be downloaded here:

We speak to a number of scrum masters, project managers, and CIOs each month. QSM does research on software development projects - all types, including agile and waterfall. We work with a huge database of completed software projects, updated with new industry data on a regular basis. We provide predictive analytics and we study cost, schedule, risk, quality, size, resource demand management, business intelligence, and vendor management.

Within the last couple of years, we have been hearing some agile managers say that there is no need to estimate agile projects. They say that they are managing in smaller increments or sprints and that they already know how much velocity can be achieved. They also say they are constantly “grooming the backlog” so there is no need for a formal estimation model to forecast the amount of work that needs to be done. They are managing at the sprint and task level so they feel like they have everything under control.

The bottom line is that agile projects still need to be estimated to see the big picture: the release estimate. It's essential to know the release cost and effort before the project plan is handed off to the scrum master and before committing to the customer. The negative feedback we hear regarding estimation is somewhat ironic because agile processes actually lend themselves very well to formal estimation since they promote the use of size measures like user stories, story points, and epics. Having good size information is a big part of estimating successfully.

Major corporations spend millions of dollars each year writing proposals to win software and systems business. They typically have a team of people that spend hours or days in strategy meetings to write what they hope will be a winning bid. Usually these companies are responding to a “Request for Proposal” which is sent out to a number of competitors. It’s almost like a sporting event. Let the games begin! Our team versus theirs. Sometimes jobs are on the line. No one wants to have to lay off people because there is not enough business coming in the door.

As part of this process, a project plan will be created. Oftentimes the team will work out a plan based on some previous experience and the opinions of a number of subject matter experts. Usually the plan will include a detailed spreadsheet with a larger number of tasks and the hours that it will take to complete each task.

The fact is most people don’t have a way to validate whether or not the plan is reliable. They also can’t see what chance they have of achieving their overall promised schedule, quality, and budget goals. They don’t have an easy way to negotiate these proposal decisions internally or with the client.

What's missing? A top-down, empirically-based estimate. Running a top-down estimate allows the proposal team to generate a “big picture” estimate for cost, duration, risk, and quality based on historical data and time tested mathematical models. With SLIM-Estimate (shown below), the team can run an overall project level estimate, and sanity-check their proposal with industry trends to make sure that their numbers are competitive and realistic.

If you were unable to attend our recent webinar presented by QSM's Andy Berner, a replay is now available.

As companies try to innovate and at the same time keep software development costs in line, balancing the projects you plan with the resources you need becomes a major challenge. Portfolio and resource management systems, such as CA PPM (formerly known as CA Clarity), have many of the ingredients you need to meet that challenge, but a key ingredient is missing: credible resource demand for the projects you plan to do.

Andy Berner shows how QSM SLIM-Estimate’s Top-Down Resource Demand capabilities provide that missing ingredient. He explains how SLIM-Estimate predicts resource needs for your projects and why it provides the best demand estimates for resource planning. He demonstrates how SLIM-Estimate provides demand information in a way that matches your resource planning process, and how integration with SLIM-Estimate enables the successful use of the resource management capabilities of your portfolio management system.

Watch the replay!

One thing that I hear from project managers on a regular basis is that estimating a software project is a really tough thing to do. I have to tell you that it doesn’t have to be that way. Here are some reasons why project estimation can be easier than you think.

In a recent webinar on using the SLIM tools and methods in an agile environment, we showed a template for agile projects included with SLIM-Estimate. I was asked, "Since agile teams are a fixed size group that stays together throughout the work on the release, why doesn’t the agile template use the Level Load shape?" My answer was the typical short answer to a complex question, "It’s complicated and it depends." In this blog, let’s take a look at some of those complications and dependencies.

The team, the whole team, or nothing but the team?

When using SLIM-Estimate to estimate the effort required for a release, agile or not, you have to decide, "Whose effort are we interested in?" When describing a team in a scrum project, we usually talk about three major roles: product owner, scrum master, and team member. These people are, in general, full time on the project. If you are only interested in estimating the effort of these full time team members, then you may want to use the “Level Load” shape in SLIM-Estimate. The total effort of these people is based on the number of people multiplied by the duration of the work on the release.