Since I work for a software metrics and estimation company, many people ask me questions regarding capacity planning and demand management. Most of the project managers that I speak with are using project portfolio management tools for very detailed, task-level resource capacity planning. They spend a lot of time planning the person hours for each task and then these task-level plans are prioritized and viewed across the organization. These are useful tools and methods and they usually require a sizable investment.

The problem is that many of these project managers don’t have a good way to support demand management. That is to say that they aren’t able to accurately estimate the key drivers that go into their PPM tools.  They need to be able to answer key questions like: Should we commit to 6 months or 9 for the project duration? Do we need 10 software developers or 20 to finish in 9 months? How much is the overall project going to cost? What alternatives do we have? Has anyone ever achieved that duration in the past? Should we even go forward with this project; what is the risk?

Oftentimes the project manager comes up with this information informally based on experience. Unfortunately, when they don’t use a scientific approach to estimating, they leave out key factors that affect the estimate and project success, like project complexity, team efficiency, and overall project uncertainty.

In agile development, getting the backlog ready and grooming it take serious consideration and work. You need to plan, budget for, and track this work. In a recent interview with Cameron Philipp-Edmonds of StickyMinds, Andy Berner talks about his upcoming presentation for Agile Development Conference East, the importance of keeping a well-groomed backlog, the pitfalls of the impossible zone, and why it's vital that you and your team keep your tools serving you and not the other way around.

Read the full interview transcript here!

Client organizations who are considering investing in SLIM^® (a top-down, scope-based, parametric software estimation tool) often ask us for return on investment (ROI) case study examples which we gladly provide to help them with their business case. However, one question that has never been asked but I have always wondered is: does ROI accelerate with increased investment or does it follow the law of diminishing returns?

To answer this question, we looked at seven software estimation ROI case studies that included a variety of small, medium and large clients, from a single seat of SLIM all the way up to an enterprise Estimation Center of Excellence (ECoE).

On the above chart we plotted the investment in SLIM tools and consulting on the X axis vs. the return (actual cost savings) on the Y axis for each case study using a logarithmic scale. We then drew a trend line through the data points.

Following the trend line, small engagements (~$30K) had an average ROI of more than 13:1.  Medium engagements (~$300K) had an average ROI of 33:1.  Large ECoE engagements ($3M) had an average ROI of 67:1.  So not only is the ROI compelling, but it also accelerates with increased investment.

The actual cost savings (return) as reported by, or observed while working with, our clients include:

This case study for Agile Connection by QSM's Taylor Putnam serves as an example of how adopting agile can be extremely beneficial to an organization, as long as situational factors are considered. Adopting a new development method is a strategic, long-term investment rather than a quick fix. As this article shows, making deliberate, fully formed decisions will ultimately lead to better outcomes.

Read the full article!

Function points are proven to be effective and efficient units of measure for both agile/iterative and waterfall software deliveries. However, inconsistencies come to light when comparing function points counted in agile/iterative development with those counted in waterfall or combination development . These inconsistencies can create confusion for cost, productivity, and schedule evaluations that span multiple software delivery methods. This paper, recently published on IFPUG's Beyond MetricViews by QSM Consultant Carol Dekkers, seeks to marry International Function Point Users Group (IFPUG) definitions with equivalent concepts in agile/iterative processes in order to create a basis for consistent comparison. 

Read the full article!

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.

Installation – Initial installation of the methods and training in their use.  Process documentation and training should answer questions like:

In the software project management field, projects go badly about 43% of the time and fail completely 18% of the time. While there are several reasons for this, and plenty of blame to go around, one of the easiest ways to reduce the risk is to start at the beginning – with the proposal. In a recent interview with Cameron Philipp-Edmonds of StickyMinds, Larry Putnam, Jr. talks about the importance of the proposal when executing a successful project. He identifies five key questions that should be answered before any project starts and how software estimation ties into the proposal process.

Read the full interview transcript here!

I am a professional software project estimator.  While not blessed with genius, I have put in sufficient time that by Malcolm Gladwell’s 10,000 hour rule, I have paid my dues to be competent.  In the past 19 years I have estimated over 2,000 different software projects.  For many of these, the critical inputs were provided and all I had to do was the modeling.  Other times, I did all of the leg work, too: estimating software size, determining critical constraints, and gathering organizational history to benchmark against.  One observation I have taken from years of experience is that there is overwhelming pressure to be more precise with our estimates than can be supported by the data.  

In 2010 I attended a software conference in Brasil.  As an exercise, the participants were asked to estimate the numerical ranges into which 10 items would fall.  The items were such disparate things as the length of coastline in the United States, the gross domestic product of Germany, and the square kilometers in the country of Mali: not things a trivia expert would be likely to know off hand.  Of 150 participants, one person made all of the ranges wide enough.  One other person (me) got 9 out of 10 correct.

A recent article in the New York Times about farm robotics, of all things, made me think about software 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.

Enough already with Healthcare.gov and the many (many) other high-profile IT project failures; let’s talk about government software projects that actually worked. Successful software projects are no accident. Best-in-class government IT projects share common traits that agencies can use to ensure success. In a recent article for Government Computer News, QSM's Larry Putnam, Jr. leverages data from from the QSM Database to identify best practices for successful government projects.

Read the full article!