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.
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.
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 20th 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.
On Oct. 2, 11:00 AM EST, QSM's Phil Armour will present "A Practical Approach to Measuring Software Development Productivity" as part of the ITMPI Webinar Series.
Most measurements in software development are notoriously difficult and assessing productivity is no exception. There are an enormous number of factors that could or do affect productivity, and it is challenging to identify and characterize what they might be. The effort involved often deters organizations from even attempting to quantify how effective they are at building systems. This webinar will present a useful and practical approach to productivity measurement based on a mathematical model of systems development and over thirty years of research. It will also describe the core mathematical functions that relate to the major attributes of systems development, show how a useful productivity metric can be calculated from project history, and demonstrate how QSM’s database of over 10,000 projects support this view of software development productivity.
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.
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.