Practical Software Measurement
On Thursday, Dec. 4 at 1:00 PM EST, QSM's J.D. Ottenbreit will present "Organizational Success: A Practical Guide to the Estimation Center of Excellence."
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.
Webinar - IT Demand Management and Capacity Planning: Why Estimation Is Vital to Balancing the Scale
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.
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.
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.”
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.
QSM's recent webinar, From Proposal to Project: Getting Resource Demand Early, presented by Andy Berner and Keith Ciocco, featured a thoughtful Q&A session from our audience. Here are the highlights:
Q: Which PPM products does SLIM work with right now?
What does a typical software project in the QSM historical database look like, and how has “what’s typical” changed over time? To find out, we segmented our IT sample by decade and looked at the average schedule, effort, team size, new and modified code delivered, productivity, language, and target industry for each 10 year time period.
The QSM benchmark database represents:
- 8,000+ Business projects completed and put into production since 1980.
- Over 600 million total source lines of code (SLOC).
- 2.6 million total function points.
- Over 100 million person hours of effort.
- 600+ programming languages.
During the 1980s, the typical software project in our database delivered 154% more new and modified code, took 52% longer, and used 58% more effort than today’s projects. The table below captures these changes:
Some years ago, the large systems integrator I worked for brought in a new CEO in an attempt to jump start the company. We had lost our position as number one in the industry and leadership had become stagnant and ingrown. The new CEO, who did not have a software background, liked to promise that we could deliver our projects “Faster, Better, and Cheaper." That sounds wonderful, but is rapid process improvement in three dimensions really possible? The short answer is “No” – at least not in the short term. Here’s why.
To deliver a software project faster one of two things has to occur:
A replay is available for this webinar, From Proposal to Project: Getting Resource Demand Early, presented by Andy Berner and Keith Ciocco.