In talking with many organizations about their IT estimation practices over the years, I’ve noticed a recurring theme has been their self-perception of immaturity when addressing the use of a commercial estimating tool. Estimates in the workforce are typically generated via the Delphi method, multi-tabbed spreadsheets, and uncalibrated guesses.  When recommending a top-down tool approach, the feedback can be: “we aren’t mature enough to use a tool or model.” 

I’ve actually seen the opposite.  The top-down approach offers an on-ramp to more formal estimating by its very nature of needing few inputs, rather than the myriad of cells, rows, and columns required to be populated in a spreadsheet.  A top-down tool approach leads us away from relying on the institutional knowledge of a few people that may have relevant experience, but one day may retire or move on from the organization taking that knowledge -with them.  Also, a parametric top-down approach leveraging relevant historical data is much better than a wet thumb in the air.

In agile development, it's not unusual for software teams to have a fixed schedule or budget before any work begins. This is great information for stakeholders, but what if those targets are unrealistic? What if there were a way to evaluate trade-offs early in the decision-making process, before any detailed planning occurs?

With a top-down estimation tool like QSM's SLIM-Estimate, your scrum teams can quickly determine how much functionality they can deliver in a planned release schedule. If that target schedule turns out to be unrealistic, you can leverage SLIM-Estimate's time-tested models to calculate the impact of trade-offs. What happens if you add more people to the project? If the schedule is non-negotiable, how much functionality can you deliver in that period of time? SLIM-Estimate provides you with visualizations that are powerful when presenting to senior-level management and stakeholders. Plot your estimates against relevant agile trendlines from QSM's database of over 13,000 projects (the largest of its kind) and you can see how your estimates check out against the industry.

The video above shows how to use this powerful tool to generate defensible agile estimates you can present to stakeholders early in the planning process. Having data-driven information like this at your fingertips will allow you to plan and negotiate, and maybe even avoid disaster.

When a project goes over schedule, costs too much money, or doesn’t deliver the desired functionality, business leaders may wonder what could have been done differently. Why not ask a professional estimator? Often, these are the people holding the crystal ball - those charged with planning and assessing the project before it even gets off the ground.

We recently polled our own seasoned estimation experts at QSM to find out their thoughts. With many years of forecasting, tracking, and benchmarking software projects under their collective belts, everyone from our consultants to our support and sales teams chimed in to compile a list of what estimators consider to be the most critical software development management issues. In this article, Don Beckett shares these lessons learned (and methods to solve them), which are invaluable to both project managers and C-level business leaders alike.

Read the full article!

Early project decisions, when not much is known, are easily the hardest. They're also often the most critical. Maybe you've found yourself in a position where you need to communicate to stakeholders what your work is going to cost and how long it will take to deliver. Feeling the pressure to deliver, you might have to make decisions based on gut feel instead of past performance. This can lead to setting unrealistic targets and often results in projects going late or over budget. 

At QSM, this is when we recommend turning to historical data. Whether it's your own data or trendlines from the 13,000 validated projects in the QSM industry database, leveraging actual completed projects can make your estimates more reliable. 

Believe it or not, collecting your own project history isn't as difficult as it sounds. We recommend capturing just a few basic metrics: Functionality Delivered, Total Effort, and Total Duration. Once you have this information, you can calculate a Productivity Index, which is the measure of productivity for the overall project or release. Then all of these metrics can be leveraged by any of the other project lifecycle tools in the SLIM-Suite for estimating, tracking, and benchmarking.

In the video above, you can see how easy it is to gather your own completed projects to use early in the planning process and determine if your estimates are reasonable or not. This helps you understand the big picture before you make any important project or portfolio decisions. 

How large is your project?
It’s projected to cost $2,000,000.
That’s cost. not size!

How large is your project?
We believe it will take 14 months to complete.
That’s schedule, not size!

How large is your project?
It’s going to be a 25-person project.
That’s staff, not size!

Software estimators often think of project size as what a project produces (features, stories, requirements, function points, or code). These are what a project has to create or account for in order to fulfill its mission. Business leaders, understandably, are more likely to visualize project size in terms of resources expended (cost, time to market, or FTE staff).  These competing definitions of “size” can produce confusion and ambiguity. Which leads us to Tip #1.

Tip 1

Be prepared to explain to business leaders how quantifying project size (as seen by an estimator) helps business leaders get more accurate estimates of the things that matter to them: cost, schedule, quality, and staffing. I find a graphic like the one below from SLIM-Estimate can be useful to illustrate the relationship between a project’s size (primarily of interest to development staff and project managers) and the major project management metrics of interest to the C-suite.

Background

No two software projects are exactly alike. So, one way to find out what a “typical” software project looks like is to take a large sample of completed projects from the QSM historical database of over 13,000 completed software projects and look at measurements of central tendency for staff, effort, size, schedule duration, and productivity.

For this study, QSM looked at validated projects that completed beginning in 2010. We eliminated 1 person projects and those that expended less than 1 person month of effort. The eliminated projects accounted for 13% of the sample. About 80% of the projects fell into the Business IT application domain, many of which were from the financial services sector. This domain includes projects that typically automate common business functions such as payroll, financial transactions, personnel, order entry, inventory management, materials handling, warranty and maintenance products. We determined both a median and an average for each metric. With the exception of schedule (project duration), these differed significantly which indicates that that the sample metric values were not normally distributed. To minimize the effect of unrepresentative projects (those that comprise a small part of the sample, but whose metric values are very large or very small), we decided to use the medians – values with 50% of the projects above and 50% below the “average” as a better measure of central tendency.

The "Typical" Project

If you were unable to attend our recent webinar, "How to Estimate Reliability for On-Time Software Development," a replay is now available.

Software development is a major investment area for thousands of organizations worldwide. The negotiation and early planning meetings often revolve around major cost and schedule decisions. But one of the most important factors, reliability, often gets left behind in these early discussions. This is unfortunate since early reliability estimates can help ensure that a quality product is delivered and predict if it will finish on-time and within budget. In this webinar, Keith Ciocco shows how to leverage the QSM model-based tools to estimate and track the important reliability numbers along with cost, scope, and schedule.

This presentation includes a lively Q&A session with the audience and covers such topics as:

On Wednesday, Dec. 8 at 1:00 PM EST, Keith Ciocco will present "How to Estimate Reliability for On-Time Software Development."

Software development is a major investment area for thousands of organizations worldwide. The negotiation and early planning meetings often revolve around major cost and schedule decisions. But one of the most important factors, reliability, often gets left behind in these early discussions. This is unfortunate since early reliability estimates can help ensure that a quality product is delivered and predict if it will finish on-time and within budget. In this webinar, Keith Ciocco will be showing how to leverage the QSM model-based tools to estimate and track the important reliability numbers along with cost, scope, and schedule.

Keith Ciocco has more than 30 years of experience working in sales and customer service, with 25 of those years spent with QSM. As Vice President, his primary responsibilities include supporting QSM clients with their estimation and measurement goals, managing business development and existing client relations. He has developed and directed the implementation of the sales and customer retention process within QSM and has played a leading role in communicating the value of the QSM tools and services to professionals in the software development, engineering and IT industries.      

Register now!

If you were unable to attend our recent webinar highlighting the pioneering measurement work by Larry Putnam, Sr. and how it applies to today's estimation challenges, a replay is now available.

QSM was deeply saddened by the passing of our founder, Larry Putnam, Sr. just a few months ago. Larry's left behind a 40 year legacy in the software estimation and measurement field. His models were the basis for our SLIM-Suite of tools and many of his discoveries about the behavior of software projects still hold true today. In this webinar, his son and QSM Co-CEO Larry Putnam, Jr. reviews Larry Putnam, Sr.'s original research and the data it was based on. He then explores if that original research continues to stand the test of time when compared with data derived from modern development approaches. He also shows how modern agile development practices exploit some of the laws Larry discovered over 40 years ago. Finally, he discusses the role of estimation in today’s increasingly agile world.

Watch the replay!

On Wednesday, Nov. 3 at 1:00 PM EDT, Larry Putnam, Jr. will present "Larry Putnam, Sr.'s Legacy and Understanding the Physics of Software Projects."

QSM was deeply saddened by the passing of our founder, Larry Putnam, Sr. just a few months ago. Larry's left behind a 40 year legacy in the software estimation and measurement field. His models were the basis for our SLIM-Suite of tools and many of his discoveries about the behavior of software projects still hold true today. In this webinar, his son and QSM Co-CEO Larry Putnam, Jr. reviews Larry Putnam, Sr.'s original research and the data it was based on. He then explores if that original research continues to stand the test of time when compared with data derived from modern development approaches. He also shows how modern agile development practices exploit some of the laws Larry discovered over 40 years ago. Finally, he discusses the role of estimation in today’s increasingly agile world.

Register now!