Practical Software Measurement
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:
Registration is now open for QSM's upcoming webinar, From Proposal to Project: Getting Resource Demand Early, presented by Andy Berner and Keith Ciocco on Oct. 2 at 1:00 PM EDT.
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.
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 cap
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.