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?

A: We're working with customers to see what products they're interested in. It's adaptable to multiple PPM systems and we'd like your input on which ones we should deliver for you early. We can work with you so you can build a customized input to your own system. So the framework is very general and is released as part of the SLIM product. We will be providing adapters to common PPM systems and that's what we would like to learn from our design partners - which ones to deliver first. (Note: if you are a SLIM customer or prospect, you can request to join our design group by emailing Keith Ciocco).

Q: You showed SLIM-WebServices. Does that come with the desktop tool? Do you use them separately or together?

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:  

• Productivity must increase or
• More effort (cost) must be applied to the project.  

Increasing productivity is a long term strategy that entails improving how the organization works.  It has nothing to do with mandating unpaid overtime or telling developers to “work smarter.”  In fact, those strategies are usually counterproductive.  

A replay is available for this webinar, From Proposal to Project: Getting Resource Demand Early, presented by Andy Berner and Keith Ciocco.

When evaluating proposals, any good project manager knows it doesn't do any good to charter a project if the right people aren't available or if the cost and schedule are unrealistic. It becomes very important early on in the proposal process to be able to run accurate feasibility estimates that produce skilled staff outputs, matching resources needed for a project to the resources you have. This webinar, presented by QSM's Andy Berner and Keith Ciocco, demonstrates a powerful top-down approach, which allows organizations to do early resource planning and powerful what-if analysis without breaking out the work breakdown structure (WBS). This process matches the supply to the demand and is easy, credible, and correct.

Dr. Andy Berner has helped organizations improve their software development processes for over 20 years. He has "hands-on" experience with almost every role in software development. He is on the QSM software development team and is leading the work at QSM to incorporate Agile techniques into and enhance the resource demand management capabilities of the SLIM-Suite. He has recently published several articles on Agile methods and practices, focusing on planning projects to set realistic expectations. He has spoken at numerous conferences on software tools and methods, often with an emphasis on how to make sure that tools serve the team, rather than the other way around. He has an A.B. cum Laude in Mathematics from Harvard University, a Ph.D. in Mathematics from the University of Wisconsin, Madison, and has seven US Patents.

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.

The problem is that many of these project managers don’t have a good way to support demand management. That is to say that they aren’t able to accurately estimate the key drivers that go into their PPM tools.  They need to be able to answer key questions like: Should we commit to 6 months or 9 for the project duration? Do we need 10 software developers or 20 to finish in 9 months? How much is the overall project going to cost? What alternatives do we have? Has anyone ever achieved that duration in the past? Should we even go forward with this project; what is the risk?

Oftentimes the project manager comes up with this information informally based on experience. Unfortunately, when they don’t use a scientific approach to estimating, they leave out key factors that affect the estimate and project success, like project complexity, team efficiency, and overall project uncertainty.

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.

Read the full interview transcript here!

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).

On the above chart we plotted the investment in SLIM tools and consulting on the X axis vs. the return (actual cost savings) on the Y axis for each case study using a logarithmic scale. We then drew a trend line through the data points.

Following the trend line, small engagements (~$30K) had an average ROI of more than 13:1.  Medium engagements (~$300K) had an average ROI of 33:1.  Large ECoE engagements ($3M) had an average ROI of 67:1.  So not only is the ROI compelling, but it also accelerates with increased investment.

The actual cost savings (return) as reported by, or observed while working with, our clients include:

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.

Read the full article!

Function points are proven to be effective and efficient units of measure for both agile/iterative and waterfall software deliveries. However, inconsistencies come to light when comparing function points counted in agile/iterative development with those counted in waterfall or combination development . These inconsistencies can create confusion for cost, productivity, and schedule evaluations that span multiple software delivery methods. This paper, recently published on IFPUG's Beyond MetricViews by QSM Consultant Carol Dekkers, seeks to marry International Function Point Users Group (IFPUG) definitions with equivalent concepts in agile/iterative processes in order to create a basis for consistent comparison. 

Read the full article!

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 capabilities.

Establishing and maintaining software best practices requires that you design clear processes and plan a pace of implementation that promotes lasting change.  A key component is accommodating human learning and skill development challenges.  Borrowing from a training class I developed 14 years ago (yes, implementing best practices is still a challenge), let’s follow a team of water bugs as they progress through Watts’ four stages of Human Methods Adoption to understand what good pacing requires.

Installation – Initial installation of the methods and training in their use.  Process documentation and training should answer questions like: