Process Improvement

Process Improvement

Should Task Planning Occur Before Software Estimation?

I work for QSM, a leading software project estimation and demand management company. We focus on top-down estimation, meaning we figure out the total project duration and effort before any detailed planning occurs. We use SLIM-Estimate also known as the Putnam Model. Larry Putnam Sr. introduced SLIM in 1978. It is one of the leading software estimation tools in the world, validated with over 35 years of industry leading research and updated regularly with the latest technologies. 

Many people call us for help with team size software project estimation, they want to see how many people it’s going to take to deliver a specified amount of functionality within a certain duration and budget. At the time they call us they are often using task level planning tools to try to figure this out. 

The problem is that it’s tough to allocate people and the number of hours they will work when they haven’t figured out the specific requirements of each task and when they haven’t estimated the total duration and effort for the overall system. A manager could spend days creating a task level plan that doesn’t add up to the overall project duration and budget that is needed to deliver the functional requirements. When it doesn’t add up then re-planning has to take place costing more time and money. This is why QSM recommends estimating the big picture first, the scope level. 

Blog Post Categories 
Estimation Process Improvement Sizing

Avoid Process Improvement Failure with Pacing that Promotes Mastery

Software process improvement efforts often fail because we try to accomplish too much too soon.  Aside from the cultural and organizational obstacles to change, people need time to learn and assimilate new ideas and skills.  “Human memory and comprehension are limited, and it is easy to design processes that are beyond peoples’ capacities,” says Watts Humphrey  (Humphrey, 1989).  This is true in any situation, but I think it is compounded in the software world because time is always a scarce resource.  The pressure is high in every organization to justify process improvement dollars and increase capabilities.

Establishing and maintaining software best practices requires that you design clear processes and plan a pace of implementation that promotes lasting change.  A key component is accommodating human learning and skill development challenges.  Borrowing from a training class I developed 14 years ago (yes, implementing best practices is still a challenge), let’s follow a team of water bugs as they progress through Watts’ four stages of Human Methods Adoption to understand what good pacing requires.

Software Process Improvement

Blog Post Categories 
Process Improvement

Process Improvement and Farm Robotics

Process Improvement and Farm RoboticsA recent article in the New York Times about farm robotics, of all things, made me think about process improvement.  In the article, dairy farms in New York are beginning to use robotic milkers to feed and milk cows without the use of farm hands.  The solution was born out of several issues for dairy farmers, first, manual labor was hard to come by, and second, dairy prices were soaring.  What farmers needed was cheap, reliable labor; the solution was farm robotics.

Blog Post Categories 
Process Improvement

When You Plan Your Projects Impacts the Bottom Line

In my previous blog post, I discussed the similarities between software and home improvement projects, and how the planning process greatly impacts the project lifecycle.  Better planning in and of itself is a great way to streamline the Construct & Test Phase of development.  However, when you plan is equally important to the development process.

While watching home improvement shows, like Discovery Home’s "Flip That House," one of the primary concerns of the project manager is often how quickly the team can get started so that they can meet their target deadline.  One cringe-worthy line that I distinctly remember was “as long as we have activity, we have productivity.”  Unfortunately, activity and productivity do not necessarily go hand in hand.  

For instance, in software development a project manager may tell a developer at the beginning of a project to start building a system.  If the requirements have not yet been determined, it’s challenging for the developer to build anything.  Yes, it’s possible for the developer to start building something while the project manager decides what should actually be built.  However, once the requirements are finalized it’s very likely that the developer will have to go back and rework the code so that the system will have the desired functionality.  

Blog Post Categories 
Benchmarking Process Improvement

How to Improve Your Software Project at the Foundation

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.  

Blog Post Categories 
Process Improvement Project Management

Webinar Replay: Using Benchmarking to Quantify the Benefits of Process Improvement

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!

Blog Post Categories 
Webinars Benchmarking Process Improvement

Achieving Goals Begins with Successful Measurement

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

Webinar - Using Benchmarking to Quantify the Benefits of Process Improvement

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.

Blog Post Categories 
Webinars Benchmarking Process Improvement

Process Improvement and the "Normal" Project

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.

While there is nothing earth shattering in these numbers, I saw a disconnect between the typical, relatively small project and massive lifecycle methodologies and process sets, such as CMMI, that are designed for BIG projects.  These processes and methods usually make some effort to be scalable; but the time and effort required to understand and scale them appropriately is a significant endeavor all by itself!  

Blog Post Categories 
Function Points Process Improvement