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

Why?

Over this span of time a host of solutions have been attempted with very modest results.  Only the elephant in the living room has been ignored:  since project schedules are chronically and habitually underestimated, why not allocate more time to them at the outset?  The reasons for doing so are compelling:

image via Techwell

A large part of software estimation is dealing with the unknown. At the earliest stages of a software project, the uncertainty surrounding schedule and budget is at its highest and diminishes as a project reaches completion. In the estimation community, we refer to this as the "cone of uncertainty." Of course, it is at the widest point of this cone where estimation is typically needed. So how can organizations keep their customers feeling secure and informed when requirements are still being flushed out and budgets aren't yet established? In his recent a blog post on Techwell, Noel Wurst identifies strategies for flattening the dreaded cone of uncertainty.

Read the full post here!

You may not be aware that in 1837 when Robert Southey published his popular retelling of the Three Bears story, the U.S. experienced the “Panic of 1837,” a financial crisis that touched off a decade long recession featuring unemployment, pessimism, lowered profits/prices/wages, and blamed on domestic and foreign origins. While we might consider 1837 a simpler time - it was without modern conveniences like indoor plumbing, the internet, and supersonic travel – some aspects of human behavior and communication aren’t that much different today. I thought about this when I was keynoting the 20^th anniversary EuroSPI2 conference (software process improvement) in Ireland, the same week that I read the following in the British press: 

“The Department for Work and Pensions has dropped a coalition government scheme to avert software disasters from its £2bn Universal Credit programme” forecasting the cancelation of the largest ever agile software development project – a project now four plus years behind schedule with potentially billions of taxpayer funds at risk.  

Watch the webinar replay for Bringing Estimation and Business Intelligence to the Enterprise, presented by Keith Ciocco.

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.

As Vice President of QSM, Keith has more than 25 years of experience working in sales and customer service, with 17 of those years spent at QSM. Keith's primary responsibilities include managing business development, existing client relations, customer retention and response.

Watch the replay!

Software projects often commit to unrealistic schedule and budget expectations due to little or no information about the size and scope or productivity. Yet the business reality is that projects must be estimated early in the life cycle to support business goals and strategic planning. These challenges can be overcome with a transparent and collaborative estimation process. It depends on metrics collection, analysis, risk comparison, and a structure for sharing the right information with the right people at the right time.

In an article recently published on Projects at Work, Laura Zuber explores the benefits of collaborative software project estimates and identifies best practices for implementing them.

Read the full article!

In the recent Washington Post article How the Obama Campaign Won the Race for Voter Data, Joel Kowsky writes about how the 2012 Obama campaign used analytics to improve their campaign strategy, and to ultimately secure the presidential victory.  

Regardless of where you stand on the political spectrum, it’s hard to argue that Barack Obama’s campaign strategy was anything short of impressive.  As soon as Obama took office in 2009, his team began preparing for his 2012 campaign.  From the start there was a strong emphasis on measuring the campaign’s progress.  Jim Messina, Obama’s 2012 campaign manager, stated 

“There’s always been two campaigns since the Internet was invented, the campaign online and the campaign on the doors.  What I wanted was, I didn’t care where you organized, what time you organized, how you organized, as long as I could track it, I can measure it, and I can encourage you to do more of it.”

The team began by conducting a postmortem study on their 2008 campaign where they analyzed the number of homes visited, phone calls placed, and voters registered by each field organizer and volunteer.  The result was a 500 page report which highlighted areas of improvement for the 2012 campaign.  

The suggestions led the Obama campaign to invest in building customized software that would integrate all the data the campaign had collected on voters, donors, and volunteers and link to individual voter profile.  This software analyzed previously collected data to calculate the likelihood of candidate support, the likelihood of election day turnout, and the degree of persuasion for each voter.  

Function point analysis has played an important role in software measurement and analysis for 30 years, but what will be the role of function points in the future? Will they have staying power? Expanding off of a recent article for IFPUG's Metrics Views, Don Beckett looks at the QSM software project database and examines a set of validated projects counted in function points that have completed since the year 2000 to see what they tell about productivity, schedule, and staffing. We are fortunate to have several thousand projects in this sample to work with as this allows us to parse the data many different ways and still have enough projects to be statistically significant. For this study only unadjusted function points were used.

Read the full white paper!

It's no secret we're advocates of smaller teams, but it's always nice when others agree. Baseline's Tony Kontzer leveraged some of our most recent data for an informative slideshow about team size.

At one time or another, almost all information technology professionals have heard cries for more resources. They may even have been the one asking for help. "If only there were more people available for this project," they've said, "then maybe it would get done on time." Well, it turns out that more staffing is not the equivalent of optimal staffing. In fact, smaller project teams are more productive and can complete projects cheaper and faster than larger ones, according to a recent study from software life cycle consultancy Quantitative Software Management. That should be good news for IT departments that have seen their ranks depleted in recent years.

To see more results from QSM's recent study, read Don Beckett's post on the correlation between staffing and schedule.