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:

Technology organizations spend thousands of hours a month planning and delivering their software engineering, cloud, and IT transformation projects. Unfortunately many of these projects start off with unrealistic expectations around cost, duration and scope; or they start fine, but then customer requirements change. Being able to generate metrics analysis and adaptive forecasting when projects are in trouble is essential to saving money and time. All of this combined with the need to negotiate and reset expectations can make this process a challenging one. In this webinar, presented on Thursday, January 21 at 1:00 PM EST, Keith Ciocco will show how estimation and control tools can be leveraged early and while projects are in-flight.

Register here!

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!

Estimation return on investment - a hotly debated topic in some circles, but still a very active and frequent conversation in C levels all over the world. Something that hasn’t changed in the 20+ years I’ve been involved with estimating software development, regardless of methodology, has been the question asked by senior leadership when embarking on developing new functionality - “How much will it cost and when can we deliver?”  Despite the emergence of new methodologies, this question is understandably the main driver of whether to proceed with a project or not.  The ROI I am focusing on here is the IT budget we are committing to building a project, or portfolio of projects.  Very often, we are faced with that question very early on, when we know little about the project’s full intended capability, but the C level is asking for an estimate and we better respond with a defendable answer.

The ROI is realized in several ways - firstly in the form of estimating the appropriate staffing levels.  We have often assisted clients who initially estimated their projects with too many FTEs.  A relatively simple tweak to the staffing skills combined with empirical data for effort calibration can prove, in many cases, that the FTE count is too high. In the graph below, the yellow diamond represents our current estimate compared to the green dot (adjusted estimate) resting on the blue trendline in the middle representing the industry average for staffing vs. size.  Properly adjusting the FTE levels can save thousands, even hundreds of thousands of dollars depending on the project size, and millions of dollars across a portfolio.

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, "Increase PMO Collaboration to Improve IT Portfolio Management," a replay is now available.

IT project portfolios are diverse - technologies, platforms, methods, resources and more! Ensuring that project priorities align with business strategies and resource demand requires project intelligence and better estimation capabilities. Join Keith Ciocco and Laura Zuber for this PDU-approved webinar to learn how to leverage centralized data about scope, capacity, cost, staffing and quality to explore estimate solutions that overcome common PMO challenges of shrinking budgets and scarce resources. See how tailored access and process workflow increase visibility and provide the tools for effective project prioritization, review and governance.

Watch the replay!

IT project portfolios are diverse - technologies, platforms, methods, resources and more! Ensuring that project priorities align with business strategies and resource demand requires project intelligence and better estimation capabilities. Join Keith Ciocco and Laura Zuber for this webinar on Thursday, Oct. 22 at 2:00 PM EDT to learn how to leverage centralized data about scope, capacity, cost, staffing and quality to explore estimate solutions that overcome common PMO challenges of shrinking budgets and scarce resources. See how tailored access and process workflow increase visibility and provide the tools for effective project prioritization, review and governance.

Register here!

During a recent consulting engagement, a customer asked if the QSM defect discovery model applied to Agile projects.  Of course, the best (and only) way to determine this was empirically.  From our database we extracted a sample of business IT projects that had completed since 2013 that recorded pre-implementation defects.  81 of these projects were Agile and 354 did not specify Agile as their development methodology.  We created average trend lines for both datasets and they displayed very similar patterns that conformed to the QSM defect discovery model.  This allowed us to answer our customer’s question affirmatively.

Having a large project sample at hand and being curious, we decided to compare these metrics:

• Mean time to defect (which measures the average time a system runs defect-free in the first month after implementation)
• Average development time in months
• Staffing
• Cost/effort

In a nutshell, the Agile and non-Agile projects used very similar staff sizes.  The Agile projects completed sooner and expended slightly less effort.  Quality was where the two project sets differed significantly.  Pre-implementation, Agile projects recorded fewer defects than non-Agile ones.  However, post-implementation the non-Agile projects operated longer between discovering defects in production than did Agile projects.

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

Agile methods have brought vast improvements to software development practices, but as with any process, still pose many implementation challenges. Estimating, planning, and tracking Agile projects is particularly difficult because the formality, consistency, and repeatability of Agile practices vary widely across organizations. In this PDU-approved webinar, Laura Zuber shows how macro level metrics gathered for completed projects and used as the basis of estimation and project control promote repeatability and predictability. Learn how SLIM-Suite tool’s customizable modeling parameters, such as Agile increment lines and sizing techniques, let you balance the needs of teams and the business.

Watch the replay!