Practical Software Measurement
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.
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.
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.
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).
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.