While doing research on projects counted in function points, the sample size was large enough (over 2000 projects) to allow me to compare the productivity of different project types.  The QSM database uses these project categories:

• New Development (> 75% new functionality)
• Major Enhancement (25% - 75% new functionality)
• Minor Enhancement (5% - 25% new functionality)
• Conversion (< 5% new functionality)
• Maintenance

I calculated the normalized PI’s for projects in each development classification compared to the QSM Business trend lines.  The advantage of this is that it takes into consideration the impact of size and shows how the productivity of each project “application type” differs from the QSM Business IT average.  The datasets included medium and high confidence IT projects completed since 2000.  When I obtained the results, I went back over my selection process and calculations to make sure I hadn’t made a mistake.  The numbers were that surprising.  But, no, I hadn’t fat fingered anything (neither physically nor mentally).  Average productivity for conversion projects  was more than a standard deviation below the QSM Business IT average.

“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?

Effort seems like a metric that's very straightforward, but there is a lot of complexity here, particularly if you are performing benchmark analysis. Recently, I was tapped to help out with a benchmark assessment. One of the metrics that the customer wanted to analyze was effort per function point. "Effort" on its own is very vague, and while the customer might know which phases or activities his organization uses, I can't be sure that definition will match what I think he wants. In order to effectively benchmark, we need to make an apples-to-apples comparison by examining what is really behind the effort number, so it was necessary to send the client phase and activity definitions. 

Here are some helpful definitions to help you understand which activities are included in each phase: 

In a post for The Guardian's Datablog, Jonathan Grey explores the rise of data journalism. Data journalism is "a journalistic process based on analyzing and filtering large data sets for the purpose of creating a new story. Data-driven journalism deals with open data that is freely available online and analyzed with open source tools. 

Although data is a powerful tool, Grey reminds readers that it's not a silver bullet and counters some commonly held data myths. 

Data is not a perfect reflection of the world.

When I think about software projects, my memory goes back to the large ones I worked on when I was a developer.  These projects lasted for many months and usually had teams that were divided into sub-teams that worked on specific areas of functionality.  They typically created major systems for the customer.  But was that the normal life of a software developer?  Not really.  Years were spent on production support handling change requests, while the many small projects we completed are now only vague memories.

Recently, for some research I am doing on function points, I worked with a database of over 2000 recently completed software projects. As a byproduct of that research, I was able to come up with a portrait of the “average normal” Business IT project that I would like to share.

• The normal project is not new development.  In fact, only 16% of recently completed IT projects in the database were new development.
• 75% were either major or minor enhancements.
• Median project duration from the beginning of analysis until implementation was 7 months.
• Median effort was 22 person months (or 3520 hours at 160 hours per person month)
• Average staff (team size) just over 3 FTE people.
• Average size – 160 unadjusted function points.

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.

I discovered early on that the player who learned the fundamentals of basketball is going to have a much better chance of succeeding and rising through the levels of competition than the player who was content to do things his own way. A player should be interested in learning why things are done a certain way. The reasons behind the teaching often go a long way to helping develop the skill. — John Wooden

John Wooden is regarded as one of the greatest college basketball coaches. He believed that after talent, courage, and character, fundamentals built successful teams. Successful software projects result from knowing and practicing fundamentals as well, and it begins with estimation.

I thought it would be fun to see if Coach Wooden, by way of noted quotes, could help simplify a few SLIM core concepts.

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.

Last Thursday, I hosted a webinar introducing our new, cloud-based estimation tool, SLIM-WebServices (watch the replay here). The Q&A portion of the presentation, which was fielded by both Larry Putnam, Jr. and myself, featured some great questions from the audience about the new tool's capabilities. Here are the highlights:

How will this work with the desktop version? Do they work together or separately?

Either way. The web version comes with enough information to work as a standalone. If you want more configuration capability, then you’ll want to have the desktop products and you can have a power user creating templates for the web version.

How do I use SLIM-WebServices if I don’t have the desktop tools?

You can have QSM create the templates for you on a consulting basis if you don’t have the desktop tools. SLIM-WebServices also includes standard templates representing multiple lifecycles that you can download very easily. However, any customization would need to be done with the desktop tools or with QSM Consulting.

Can we have a company-specific estimation database so that users can select from previous estimates?

A recent series of posts by Karl Wiegers eloquently discusses the "reality of tradeoffs" software professionals deal with every day, going beyond the typical success drivers (time, cost, and quality) to include product features and staff. He shares inspiring practical information by making distinctions between constraints, drivers, and degrees of freedom, each representing the amount of flexibility the project manager has to adjust a key factor.

SLIM-Estimate has modeled the non-linear interdependencies of these metrics for over thirty years. It accounts for Wiegers’s five project success factors explicitly, showing the tradeoffs between them in real time. I have mapped Wiegers’s Five Dimensions to SLIM-Estimate’s parameters to show how you can use SLIM-Estimate quantify the trade-offs Wiegers describes.