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.

One of the stated purposes of function point analysis is to provide a size measure that can be used as an input to help estimate the cost, effort, schedule, and staff needed to develop a software project. The standards for how this is done are maintained by the International Function Point Users Group (IFPUG). In a nutshell, function point analysis identifies, from a user perspective, logical groups of data that a project or application maintains or accesses and logical processes that update, query, transmit, or report on that data. The counting rules are extensive, very specific, and assign function point values to these based on the number of data stores a process accesses and the data elements it touches. To help assure that function point counting is conducted in a standardized manner, IFPUG certifies counters who have demonstrated mastery of the counting rules through passing an exam. These counters have the title of Certified Function Point Specialists (CFPS).

There is a problem with using traditional function point analysis in the conceptual phase of a software project when the budget, schedule, and staffing are being planned: the information required to count function points according to the rules is normally unavailable and, in many cases, does not yet exist. To overcome this obstacle, function point counters have devised a number of quick counting methods to estimate project function point counts. Most of these are rules of thumb whose implementation varies from one counter to another.

SiFP was developed by Roberto Meli and associates in Italy. In 2019, IFPUG acquired the rights to the methodology and plans to integrate it into its portfolio in 2021.  Follow this link for more details.

So how does SiFP differ from regular function point analysis, and why is it simpler? Three differentiators stand out:

This year has brought many challenges. Many of us have pivoted to working remotely, trying to maintain open communication with our teams while confronting new business problems presented by COVID-19. At QSM, we've made it our goal to provide the resources our clients need during this period of uncertainty, whether it's online support, consulting, or virtual training. We've also worked to continue offering a steady stream of free resources to the online community, such as webinars, white papers, and blog posts. So as we close out 2020, we wanted to take a moment to highlight a few of our most popular. 

We'll start with one of our most widely-attended webinars to date, "Taking Software Estimation and Planning to a Higher Level." Being able to generate estimates early before detailed planning takes place is essential and can have a major impact on annual budgeting, resource allocation and cost and schedule overruns. A useful presentation if you're new to estimation or if you're a seasoned estimator, this PDU-approved webinar summarizes best practices for top-down estimation and how to leverage estimation tools. Make sure and watch until the end to catch the lively Q&A session from our audience!

Project managers and estimators have long struggled with the issue of how to measure software size. Really, before you can calculate cost and schedule, you will need some notion of how big the project will be. There are myriad of ways to size a project depending on the methodology you use and where you are in the planning process. Here at QSM, it's one of the common questions we receive, so we've devoted many years of research to the topic. Our website features a wealth of resources on sizing and in this post, we will highlight a few of the most valuable for anyone grappling with this issue or looking for a place to start.

General Sizing

• QSM's Software Sizing infographic is a great place to start. This easy to understand visual resource helps explain the most popular sizing methods and when to use them, the difference between functional and technical size, sizing challenges and more!
• Measuring Software Size - Insights from the Past to Guide the Future is another helpful guide if you're struggling with which sizing units to use. This PDU-approved webinar will help you determine what sizing measure will work for you based on your own historical data. This presentation is worth a watch no matter what development methodology you use and can help improve future estimates and in-flight project forecasts.

Function Points

Stripped down to the bare bones, value in software estimation measures the functionality that a software product provides to its users (both human and non-human) while production cost measures not just value but the work that is required to deliver that functionality. Software estimates need to account for both. Examples of non-functional cost items include configuration, throw-away code, cloud architecture, and quality requirements. Size measures such as IFPUG and NESMA function points quantify value (delivered functionality) and are recognized as functional size measures. Both measures intentionally ignore technical requirements. They can be very useful when used for asset management, measuring scope creep on a project, or assessing software quality (defect density per delivered unit). For estimating they are an important input; but one that needs to be supplemented to reflect the non-functional cost factors: i.e. what needs to be done behind the scene to create that functionality.

If you were unable to attend our recent webinar, a replay is now available.

Software size measures are critical to project estimation, governance, and closeout. Methods for measuring size have been around for decades, yet many organizations still struggle to establish consistent, repeatable processes for capturing software size. Common agreement is that project size is the most important predictor of cost and schedule.

In this PDU-approved webinar, Laura Zuber describes ways to measure software size and gather actual data for completed projects to improve future estimates and in-flight project forecasts.

Watch the replay!

On March 24 at 1:00 PM EDT, QSM will be hosting a PDU-approved webinar, "Measuring Software Size - Insights from the Past to Guide the Future."

Software size measures are critical to project estimation, governance, and closeout. Methods for measuring size have been around for decades, yet many organizations still struggle to establish consistent, repeatable processes for capturing software size. Common agreement is that project size is the most important predictor of cost and schedule.

In this webinar, Laura Zuber will describe ways to measure software size and gather actual data for completed projects to improve future estimates and in-flight project forecasts.

Register now!

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.

Why do projects fail? There are a multitude of reasons from lack of up-front planning to failing to make necessary adjustments as requirements change to overstaffing when the project is running late. Whatever the reason, there are steps you can take to avoid these common traps. In this article for Software Executive Magazine, Larry Putnam, Jr. explains how focusing on scope-based estimates, agile forecasting, and smaller teams will help your development team deliver products on time and according to budget.

Read the article!

QSM recently published the sixth article in the QSM Agile Round Table series. The QSM Agile Round Table was formed to discuss the role of estimation in agile environments. QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment. The previous two articles focused on determining size in a consistent enough manner across multiple products, projects, and agile teams in order to have good historical data on which to base an estimate. They looked at several possible units of measure for software size, including story points, function points, and source lines of code (SLOC). SLIM-Estimate and SLIM-Collaborate permit any of those units, as well as others, to be used for software sizing. In order to use a sizing unit other than SLOC in the SLIM tools, you must assign a gearing factor.  For function points, gearing factors are discussed here. In this article, QSM's Andy Berner addresses ways of choosing a gearing factor for story points.

Read the article!