I am excited about the resource demand management capabilities in our newest SLIM-Estimate release (8.2). Software project estimates can now provide a breakout of Full Time Equivalent (FTE) staffing requirements by role by month. The staffing profile below shows how different roles, or skills, are required at different points in the schedule, based upon a particular development methodology. You can see that 6 FTE Programmers are needed by the month of May. Producing a high-level, scope-based estimate early in the software development lifecycle with detailed resource demand data helps the PMO and portfolio managers determine the best timing for project resource allocation, and setting project start dates that maximize productivity and reduce bottlenecks.

Once the estimate and resulting project skills allocation plan has been approved, resource demand management has not ended. Tracking actual staffing at the skill and task level for in-flight projects not only ensures the right people are working on the right things, meaning that product development is on track, it also allows timely resource plan adjustments to address unforeseen staffing needs.

It is no coincidence that this year’s release of the 2014 QSM Software Almanac has been coined the Research Edition. The data, research, insights, analysis and trends packed into the 200+ page book truly make it the ultimate resource for software development and estimation. That said, I thought I’d share just a few of the highlights from this year’s Almanac as a little teaser to what you’ll find when you download the full (and free) resource.

QSM's recent webinar, Organizational Success; A Practical Guide to the Estimation Center of Excellence, presented by J.D. Ottenbreit, featured a lively Q&A session from our audience. Here are the highlights:

Q: You mentioned that data is critical to an Estimation Center of Excellence, what if we don’t have any good data yet?

I like to ski.  I mean really like to ski.  I've done it for a long time and I fancy I'm quite good at it.  I Iike to have the latest gear too.  So I have this Ski Tracks app on my iPhone see.  It's very cool.  When I start skiing for the day I set it going and it records every run I make: the altitude, the speed.  Heck, it even tracks your runs on a map that you can export and relive on Google Earth.  Really. 

Ski Tracks also summarizes your days' efforts showing the total number of runs, the total vertical skied, the maximum altitude, the time spent skiing, the distance traveled, the angle of the slope…

A Hard Day on the Slopes

Sitting in the condo at the end of a hard day on the slopes of Breckenridge Resort in Colorado, I checked my Ski Tracks for the day.  "Woohoo!" I said.  "Glenn, come check this out!"  My ski buddy Glenn ambled in from the kitchen; we've skied together for several years, ever since our respective spouses decided that for some reason they didn't want to ski with us anymore. 

"Look at this," I exclaimed holding up my iPhone showing the summary of my day's skiing.  "Just check out this top speed!!"

Glenn squinted at the screen.  "Hmmm, 54.8 mph," he observed.

"How about that?" I asked rhetorically, "have the ol' legs still got it or what?"  I was inordinately pleased with myself.  I mean, 54.8 mph is FAST.

After many months of research, I’m pleased to announce that today QSM has released the 2014 version of its Software Almanac.  A follow-up to the previous version released in 2006, this 200+ page book includes more than 20 articles on topics such as metrics, agile methodology, long term planning, and trends in software development.  

The Almanac is one of the few research compendiums that studies how software development has evolved since 1980.  The source of this research is the QSM Metrics Database, which contains data from over 10,000 completed software projects from North and South America, Australia, Europe, Africa, and Asia, representing over 740 million lines of code, 600+ development languages, and 105,833 person years of effort.  

The field of software development has long focused on finding predictable and repeatable processes that improve quality and productivity, which is why many organizations are taking an interest in agile methodology. As such, this year’s Almanac focuses on this topic, which has generated increased interest since the 2006 release. Specifically, it takes a close look at projects that have been based on agile methodologies and successfully completed within the past five years.

On Wednesday, Nov. 13 at 11:00 AM EST, QSM's Larry Putnam, Jr. will present IT Demand Management and Capacity Planning: Why Estimation Is Vital to Balancing the Scale, a PDU-approved webinar for ITMPI.

Estimation is critical to IT demand management as today's senior IT executives deal with a familiar challenge - how to balance the size of the development team with the company's software wish list. Modern estimation techniques offer critical insight into this challenge. In this webinar, you will learn the ins and outs of estimation and how to effectively utilize estimation to ensure project success.

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 measurement tools and customer care programs. 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.

Register now!

Software project benchmarking and estimating leverages the power of historical project data to do solid project estimates, yet the concepts behind such processes are often not well understood.  Benchmarking and estimating rely on productivity comparisons with completed (actual) projects in a historical database and on parametric equations that mimic real life.  I find that technical concepts such as software estimation or benchmarking often can be explained by using analogies that work in other industries.  As I was thinking about benchmarking and estimating this week, the popular children’s book, Dr. Seuss's Green Eggs and Ham, came to mind.

I was talking about data mining, benchmarking, and the SLIM Suite of software estimating tools with QSM’s research director, Kate Armel. It seems that many project estimators believe that creating microscopic slices of project data is the key to precision in estimating and benchmarking, when, in reality, bigger chunks of data take less time to assemble and provide greater value.  Projects are never exact duplicates of each other, however, there are valuable trends and patterns that come out of a few common characteristics.

How is baseball analysis like software project management?  One way is the ability to continually update estimates and forecasts, as the situation and our knowledge change.  As Larry Putnam Jr recently wrote, “project estimation should continue throughout the entire project lifecycle”. 

Walter Shewhart, the father of Statistical Process Control, explained it like this:

“…since we can make operationally verifiable predictions only in terms of future observations, it follows that with the acquisition of new data, not only may the magnitudes involved in any prediction change, but also our grounds for belief in it.”

Here is a baseball example that should appear very familiar to software estimators who are familiar with the often quoted cone of uncertainty.  The following graph is taken from Curve Ball: Baseball, Statistics, and the Role of Chance in the Game, by Jim Albert and Jay Bennett.

The above model is based upon only a few simple items:  The number of homeruns hit so far; the number of games played so far and number remaining; and the total number of games in a season.  We could try to improve the model, especially early in the season, by incorporating more information.  For example:  

A common misperception is that an estimator’s job is done after a software project’s parameters are set. On the contrary, software estimation should be conducted throughout the project lifecycle to reflect inevitable changes and to improve estimates on other projects. In this article, originally published in Projects at Work, Larry Putnam Jr. identifies three ways to maximize estimating efforts — before, during and after your project is complete.

Read the full article!