Now that it’s officially summer I’ve been feeling the pressure to do some of the home improvement projects that I’ve been putting off since winter.  I figured watching one of those cable shows about flipping houses would inspire me to get started.  But instead, I started thinking about all the parallels between the show and software projects.

In our training classes, we often make the analogy that software projects are like construction projects.  When you start a project, you need to determine its scope.  That would include how big it is and how much functionality it will have.  You need to determine what resources are available to you.  This includes what tools you have to build your project, the number of people available, their skill levels, and your budget.  You also need to determine how much time you have to complete this project and the level of quality you’re willing to accept.

This particular episode began as most home improvement shows do.  A team of overly ambitious stakeholders with limited construction knowledge decide that they are going to flip a house because it’s all the rage this year.  They do some calculations based on the costs of acquiring, renovating, and maintaining the property, which determines that the house needs to sell in 60 days or else they will lose money.  Already, we’re looking at a high risk project.  

They hire a team of carpenters and contractors to start the work, but during the initial survey of the property they discover that the scope of the project is not possible given the allotted schedule or budget.  The team then engages in a series of spirited discussions about which features they can cut without compromising the overall quality of the house.  The remainder of the episode is then spent watching the team rush to finish the project on time.  

If you were unable to attend our recent webinar, Using Benchmarking to Quantify the Benefits of Process Improvement, a replay is now available.

With increasing pressure to improve quality while cutting costs, process improvement is a top priority for many organizations right now; but once we've implemented a process improvement initiative, how do we accurately measure the benefits? Benchmarking is critical to determining the success of any serious process improvement program. As with any type of measurement program, it requires an initial reference point to measure progress. To set our point of comparison, we first need to perform a benchmark on a contemporary sample of projects that are representative of the typical work that we do. In this webinar, industry expert Larry Putnam, Jr. will take you through the necessary steps to perform a successful benchmark - from collecting quantitative and qualitative data to establish the initial baseline benchmark all the way through to performing follow up benchmarks on new projects and process improvement analysis.

Larry Putnam, Jr. has 25 years of experience using the Putnam-SLIM Methodology. He has participated in hundreds of estimation and oversight service engagements, and is responsible for product management of the SLIM Suite of software measurement tools and customer care programs.

Watch the webinar replay!

“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).

On Thursday, Feb. 7, at 1:00 PM EST, Larry Putnam, Jr. will present Using Benchmarking to Quantify the Benefits of Process Improvement.

With increasing pressure to improve quality while cutting costs, process improvement is a top priority for many organizations right now; but once we've implemented a process improvement initiative, how do we accurately measure the benefits? Benchmarking is critical to determining the success of any serious process improvement program. As with any type of measurement program, it requires an initial reference point to measure progress. To set our point of comparison, we first need to perform a benchmark on a contemporary sample of projects that are representative of the typical work that we do. In this webinar, industry expert Larry Putnam, Jr. will take you through the necessary steps to perform a successful benchmark - from collecting quantitative and qualitative data to establish the initial baseline benchmark all the way through to performing follow up benchmarks on new projects and process improvement analysis.

Larry Putnam, Jr. has 25 years of experience using the Putnam-SLIM Methodology. He has participated in hundreds of estimation and oversight service engagements, and is responsible for product management of the SLIM Suite of software measurement tools and customer care programs. Since becoming Co-CEO, Larry has built QSM's capabilities in sales, customer support, product requirements and most recently in creating a world class consulting organization. Larry has delivered numerous speeches at conferences on software estimation and measurement, and has trained - over a five-year period - more than 1,000 software professionals on industry best practice measurement, estimation and control techniques and in the use of the SLIM Suite.

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.