The latest version of QSM’s Performance Benchmark Table is live!

QSM is excited to announce the release of their latest version of the Performance Benchmark Table.  Last updated in 2009, the table provides a high-level reference for benchmarking and estimating IT, Engineering, and Real Time Systems.  It displays industry average duration, effort, staff, and SLOC (or FP) per Person Month for the full range of project sizes encompassed by each trend group. 

The results were analyzed from a database of 1,115 high or moderate confidence projects completed between 2008 and 2012.  Sixteen countries and 52 different languages were represented in this sample.  In addition to the industry average, minimum and maximum values were also provided for each metric to help give a range of possible results.

The project sizes differed somewhat from the previous version to accommodate the new range of sizes present in the data.  Rather than using the same project sizes across trend groups, we selected project sizes specific to each trend.  Since Business projects are typically smaller than Engineering or Real Time projects, this allows readers to select a size relevant to the type of project they’re estimating or benchmarking.  

This tool can be particularly useful to developers and/ or project managers who are new to estimation or do not have historical project data.  

With the release of SLIM-Suite 8.1 quickly approaching, I thought I’d take a moment to share a preview of the updated QSM Default Trend Lines and how it affects your estimates.  In this post I wanted to focus on the differences in quality and reliability between 2010 and 2013 for the projects in our database.  Since our last database update, we’ve included over 200 new projects in our trend groups.

Here are the breakouts of the percent increases in the number of projects by Application Type:

• Business Systems: 14%
• Engineering Systems: 63%
• Real Time Systems: 144%

Below you will find an infographic outlining some of the differences in quality between 2010 and 2013.

From the set of charts above, we can see some trends emerging which could indicate the changes in quality between 2010 and 2013.  By looking at the data, it’s apparent that two distinct stories are being told:

1. The Quality of Engineering Systems has Increased

Monday morning I received an email that read:

Hi All,
You can set your clocks to it: the birds flying north for spring, daylight savings time, and this email being sent on the Sunday before the tournament begins.  That's right, March Madness is upon us my friends, and we’ve officially made it through winter. 

The message continued with details about how to participate, but as you can see, it’s time for QSM’s annual March Madness tournament.  So how do I justify spending company time filling out brackets?  By blogging about how this is actually related to project management.  As I went through the exercise of predicting the course of this tournament, I realized that many of the thoughts I had also go through the minds of project managers.

Before I reveal my picks I want to give some background information.  I’m new to this whole March Madness tournament thing.  I’m not familiar with the teams.  I don’t know the players’ strengths and weaknesses.  I didn’t watch their games earlier in the season, so I don’t know their stats.  All I know is that my significant other went to Ohio State so I want them to win.

“You can’t know where you’re going until you know where you’ve been.”

At this point, we’re about one month into 2013 and many of us have abandoned our New Year’s resolutions.  Personally, I prefer to set my yearly goals about a month in because it gives me some time to reflect on what I really want to improve without being distracted by everyone’s bandwagon resolutions like getting in shape or eating less junk food.

The other reason I prefer to wait a month before resolving to do anything is because it gives me time to collect some baseline data.  In his Wall Street Journal article, Bill Gates writes, that “you can achieve incredible progress if you set a clear goal and find a measure that will drive progress toward that goal.”

To use the common example of getting in shape, I’m going to explain:

1. How to set a goal, and
2. How to measure it so that you can effectively achieve your goal.

First you need to set a baseline measure of what your abilities are.  How fast and far can you run?  How much weight can you lift?  How much do you weigh?  Knowing the answers to these questions can help you determine what needs improvement.  

Next you need to identify your end goal and find a way to quantify progress towards that goal.  What does “get in shape” actually mean?  Do I want to be able to run faster?  Farther?  Do I want to be able to lift more weight?  Do I want to weigh less?  All of these goals can be quantified (e.g. I want to be able to run a mile 30 seconds faster than I currently do, I want to run a 10 miler, I want to be able to bench press 100 pounds, I want to lose 20 pounds).

It’s tempting to do things that you shouldn’t.  In software development, unrealistic deadlines and changing requirements often lead teams to make counterproductive decisions, such as adding additional staff in order to achieve a deadline.  This not only creates more defects on the current project but also takes resources away from other projects.  

I recently faced a similar dilemma when deciding whether or not to indulge in the holiday treats in the office breakroom.  Should I consume the sugary snacks that taste delicious but have the potential to cause obesity (among other health consequences) or should I eat the banana I brought with me?  Perhaps to me, this internal debate became exaggerated after reading Kidd et al.’s (2013) study and watching the accompanying video on environmental stability and satisfaction.  However, after some thinking, and more indecision on my snack choice, I came to the conclusion that software is like a marshmallow.

“The only thing that is constant is change” ~Heraclitus

This proverb is often told to individuals (like me) who love to see a project follow a plan from start to finish.  I’ll be honest, I’m a planner. I’m thrilled when the plans I put in motion actually work out the way I intended.  These are the moments when I retort, “the only people who like change are wet babies.” However, more often than not, something changes, which throws off my entire plan and forces me to not only revisit Heraclitus’s proverb but also rethink my plan entirely.

Building software, particularly in Agile development, is no exception. In fact, the second principle of the Agile Manifesto states that developers should: “Welcom[e] changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

It would seem, then, that this principle would disappoint any planner working on an Agile team. Why bother creating a development plan if you know the stakeholders are going to change their minds about their desired features at the last minute? While we’re on this subject, if the requirements are going to change from one iteration to the next, why bother estimating the project at all?

When learning something new, people often try to relate the new information back to something they already know in order to help make sense of the new concept or idea.  As a psychology major now working in the software world, I’ve found myself relating a lot of what I’m learning back to the psychological theories and concepts I learned in college.  Therefore, it is no surprise that upon reading The Twelve Principles of Agile Software, I’ve discovered that many of their principles map to organizational psych concepts.

Agile development theory approaches software development holistically.  I believe this is one of the reasons Agile projects have become so successful.  Rather than merely focusing on skill development, Agile methods foster leadership skills and teamwork among members of the development team itself, as well as between the development team, the project owner, and the stakeholders.  One avenue for this is to unify the development team and project owner with the common goal of achieving stakeholder satisfaction.

The first principle states, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”  The question I had upon reading this was what do the authors mean by the term satisfaction?  When thinking about satisfaction, most people think of outcome satisfaction, or the ultimate outcome of something, in this case the functionality of the delivered software project.  Process satisfaction on the other hand, refers to the level of satisfaction associated with the method of developing the software, or how much the stakeholders enjoy the software development process.

After spending the past few weeks working with the Agile projects in QSM’s historical database, I’ve become interested in Agile Development Theory, particularly due to its popularity. While spending days at a time examining our database, I’m left with numerous data-driven questions. Therefore, I thought I would take this opportunity to write a series of Agile-related blog posts.

QSM’s database contains over 100 Agile projects from the U.S. and abroad. The projects include a variety of application types and their top three programming languages were JAVA, C++, and VB.NET.  Seeing this, I thought it might be interesting to examine the “typical” Agile project according to our data.

So what does the “typical” Agile project look like? For consistency purposes, I limited the sample to IT systems projects completed in the last six years. I measured the Duration, Effort, Average Staff, and MTTD at various project sizes to see how they compare.

Below are two figures that give demographic information about our “typical” Agile projects: 

This scatter plot shows the individual Agile projects compared against QSM’s Business Agile trends.

What would you do if you knew from the beginning that the project you were working on was doomed to fail? Would you ask for an extended deadline? More people? Or would you agree to the project manager’s needs knowing in advance that the agreed upon criteria could not be met? Unfortunately, this is a situation that faces nearly 70% of software developers, reports Adrian Bridgwater in an article for Computer Weekly. Luckily for software developers and project managers alike, the launch of QSM’s cloud-based product, SLIM-WebServices, can help your organization prevent project failure.

Through the use of QSM’s advanced algorithmic analyses and extensive project database, SLIM has assisted seven of the top 10 systems integrators in the world with their estimation and benchmarking needs. “Project intelligence is infinitely more valuable when shared,” explains Larry Putnam, Jr., co-CEO for QSM. SLIM-WebServices’ cloud-based format makes it easier than ever to share project intelligence. Users can create and share estimates anywhere there is an internet connection. Putnam concludes by stating, “With SLIM-WebServices, we’re empowering more people in more positions at more places in an enterprise – improving visibility, transparency and informed decision-making. Ultimately, this is a company’s best defense against cost overruns, schedule slippages, and failed implementations.”  

Learn more about SLIM-WebServices!