Practical Software Measurement
We are pleased to announce our upcoming webinar, Function Point Analysis Over the Years, presented by Don Beckett on Thursday, Dec. 5 at 1:00 PM EST.
QSM will be hosting a new free advice column for software professionals who seek help to solve project management, communication and general software project issues. The first few scenarios are based on questions we receive all the time. Carol Dekkers is a QSM consultant and IT measurement and project management expert who speaks internationally on topics related to software development. Send your questions to
Think of a time when you gave a presentation that did not go well. Was the actual content of your presentation subpar, or was it that something lacked in the delivery? More likely than not, your answer was the latter (after all, why would you present something if it wasn’t worthwhile?).
When putting together a presentation, I’ve found that the overall aesthetics can drastically impact how your message is received. Seemingly small things, such as displaying a graph that uses clashing colors or an undesirable font can sometimes overshadow the content you are trying to deliver.
A couple of years ago at a lean software and systems conference, I delivered a “lightning talk” about software metrics. In the two-minute time span, I illustrated the folly of gathering data without a measurement plan and the audience grasped the concept immediately. “Why don’t more companies get this?” remarked several attendees, “it just doesn’t make sense to collect all the data we do without a plan.”
It doesn’t take a rocket scientist to succeed with software measurement; professionals with a straightforward plan can quickly and easily reap its benefits. Two concepts are fundamental to embrace for metrics success: 1. Goal-Question-Metric (GQM), and 2. Simplicity.
Goal-Question-Metric (GQM) Approach to Metrics
Frederick Brooks famously said that adding staff to a late project only makes it later. The reasons are readily apparent. The project is already experiencing difficulties, most of which were not caused by understaffing. The usual culprit is an unreasonable schedule constraint; but starting work before the requirements were well defined, poor change control, or weak configuration management could also be the villains (or at least play a contributing role). None of these root causes is staff related and adding staff does not fix them: it merely adds more bodies to the confusion.
QSM is hosting a new free advice column for software professionals who seek help to solve project management, communication and general software project issues. The first few scenarios are based on questions we receive all the time. Carol Dekkers is a QSM consultant and IT measurement and project management expert who speaks internationally on topics related to software development. Send your questions to
One of the most common objections we hear from companies with regard to getting started with top-down estimation is that it’s not needed, because they already have a detailed planning spreadsheet in place. Customers will concede that their estimation practices are not perfect, but that they are working “OK.” But, when it comes to spending your company’s money on software projects is “OK” enough?
In an agile project, the backlog (the prioritized set of requirements) is the main input to iteration planning. For an agile project to progress smoothly, the backlog must be groomed and ready for each sprint. That work must be included in your project plan. In this article, the second in a series recently published on Projectmanagement.com, QSM's Andy Berner gives you five points to consider when planning that work.
If you were unable to attend our recent webinar, Bringing Estimation and Business Intelligence to the Enterprise, a replay is now available.
Successful software development estimates depend upon more than just inputs, especially at the enterprise level. They require collaboration between stakeholders, consistency in estimation methods, and historical basis. It's also essential to account for uncertainty and risk. In this webinar, Keith Ciocco demonstrates how SLIM-Estimate and SLIM-WebServices work together to bring reliable business intelligence to the enterprise, while leveraging historical data to increase estimation accuracy and credibility.
“More projects have gone awry for lack of calendar time than for all other reasons combined” - Frederick Brooks, The Mythical Man-Month.
These words were penned by Frederick Brooks in “The Mythical Man-Month” over 35 years ago. Think back to that time for a moment. The first personal computers were being born as kits assembled by electronic hobbyists. Serious programmers considered them to be toys. A good knowledge of COBOL could get you a job just about anywhere. Computers and IBM were virtually synonymous. Structured programming was the process improvement silver bullet of the day. Something called ARPANet, the parent of the Internet, had come into existence. And software projects experienced serious problems because they weren’t given enough time to complete and test their work. Everything has changed except for the last item.