In our recent webinar, Function Point Analysis Over the Years, presented by Don Beckett, we received some great questions from our audience. Here are the highlights from the Q&A:

Q: The advice in recent years is to break large projects down into smaller ones to make them more likely to "succeed" by whatever measure. Is the advice now to make projects bigger?

A: I don't know if it's advice, but the data seemed to indicate that there is a benefit to grouping projects by larger size than the projects that are 50 or 100 function points. So I would say, where it's possible, where they can be grouped together, it would be a good idea.

Q: Why do you use the PI (Productivity Index) as opposed to the industry standard hours per function point or function points per person month?

A: Well hours per function point and function points per person month are ratios that take the ratio between effort and size and what we have found is that the schedule has a huge impact on how productive a project can be. The PI incorporates three major things: the size of the project, the amount of effort leveraged against it, and the time required to do it, so in a sense, it accounts for schedule, which function points per person month does not do. So that's why we use it.

Q: How do we convert a project from SLOC to function points to find the PI for a specific project?

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 Ask Carol!

Dear Carol: 

I’m a systems analyst working for a telecom company and I have several projects on the go at the same time.  Our PMO (Project Management Office) told us that now we have to start tracking the size of our projects both at the beginning and at the end.  I can’t believe this – it’s just more metrics and (redundant) data.  I already track project size because I do time reporting (by project) and all they need to do is add up my hours at the end and voila, you’ve got the project size: the more hours it took - the bigger the project.  They don’t seem to get it and I’ve asked for an exemption from this overhead task. Their response was to enroll me in a two day sizing course!  What can I do to prove to them that they already have the size because I keep track of my hours? 

- Frustrated in Seattle

Dear Frustrated:

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.

In her recent blog post titled Customizing SLIM-Suite Workbooks, Katie Costantini discussed how the default workbooks in SLIM-Estimate, SLIM-Metrics, SLIM-MasterPlan, and SLIM-Control can be customized.

I applied the techniques outlined in her post to one of the Sample Files to give my presentation slides a more modern look and feel.  Below is a ‘Before and After’ view of a sample SLIM-Metrics Workbook View. 

Before:

After:

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

First introduced by Victor Basili as an approach to measurement, and later the subject of a book by the same name by Rini vanSoligen and Egon Berghout, GQM is a straight-forward, stepwise approach to measurement.  While it has applicability to measurement in any industry, Basili created GQM specifically to address the chaos in the software world.  GQM involves three steps:

1. Establish the Goals for measurement.
2. Ask the Questions that will answer whether the goals are being met.
3. Design and collect the Metrics to answer the questions.

The Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh, PA expanded Victor Basili’s GQM approach to GQIM, the “I” being indicator, but that is the topic of a future post.

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.

But, how do we determine the most appropriate staffing profile for a software project?  Parametric estimation models suggest a way: these models have determined that there is a relationship between the functionality that a project delivers (called size in the software estimation vernacular) and staff.  Fitting a regression line through hundreds or thousands of software projects determines an average and deviation from that average. The regression is a reflection of how software projects have performed.  This is what has worked.  This capability is built into estimation software like SLIM-Estimate.  A wise approach is to take the average as a starting point, then adjust the modeling parameters that would increase or lower the staff.  A word of caution here: if you find that your adjustments cause staff, effort, or duration to be more than 1 standard deviation above or below average, you are probably being either too optimistic or pessimistic.  Don’t do it! 

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 Ask Carol!

Dear Carol:

I am a seasoned software project manager who continually gets blamed when my projects come in late and over-budget.  I’ve worked the last 8 weekends with my team to deliver software for my customer and no matter what we do, we can’t seem to catch up or curtail the spending. Now my team is even turning on me saying I should have known that management would get angry, when they were the ones who imposed unrealistic deadlines and keep changing their minds about what functions they want delivered first.  We’re all ready to throw in the towel, but we love our jobs and are doing the best we can.  Help!

– Overworked and Frustrated in IT land

Dear Overworked:

The first thing I can tell you is that you are not alone!  I know that this might not make you feel better, but even the best and highest paid project managers face the same issues on a day-to-day basis.  The best piece of advice I can give you is “if it’s important (as IT projects are!) – always get a second opinion.”  This is what we do in life – if you go to a doctor and he tells you that you need knee surgery, you always get a second opinion.  We need to apply the same life lessons to our work life!  

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.

Andy Berner is a software engineer and methodologist. He came to QSM in 2012 after over 25 years in both large and small software organizations, including, among others, EDS (now HP), Rational Software and IBM. Based on his experience in almost every role in software development, Andy has consulted with numerous organizations on using software development methods and tools to improve productivity and quality.

Read the full article!

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.

Watch the replay!