The concept: Agile Projects Need Budgets, Not Just Estimates, from an article in the Harvard Business Review Agile Projects Need Budgets, Not Just Estimates makes a great point about preparing estimates. Their basic assumption is that to perform estimates one needs to break everything down to tasks of a few days. And that is too much work. We couldn’t agree more. The article goes on to show how for budgeting one needs not just a single point estimate but a risk curve and the number associated with a probability…. That a budget is a commitment, not just an estimate with no responsibility along with it. Again, that is right out of SEER’s playbook.
Imagine when needing to budget, going to SEER-SEM, answering a few questions, using one of the quick scope methods, and geting a risk driven estimate for an agile project. Then mapping that to a budget based on probability. Again that is exactly what SEER-SEM does, along with schedule risk, reliability, and more.
The HBR author linked to a general purpose ballpark estimating (budgeting) tool. But for software systems SEER-SEM is specific to the domain. In the example below the risk chart shows that there is a 70% probability of not exceeding a budget of $400,000. If the budget is $200K there is only a 20% probability of success… that is an 80% probability of overrunning, or not providing minimum required functionality, or deploying software that is not fully tested. This 20% probability project should probably not be attempted as is. This kind of information, along with the anticipated value to the organization, makes for better decisions.
This is exactly one of the SEER use cases. In addition to helping people make proper decisions and deliver projects on time, SEER sometimes alerts people to the infeasibility of a project before it is attempted.Go Back
Galorath’s Director of Operations and Systems Analysis, Ian Brown, digs into Agile development. This software development method is at the forefront of discussions amongst technologists these days, warranting a deeper dive by our resident expert. In his paper, he also introduces a concept called Agilons, a sizing method similar to function points.
Read his full paper here.Go Back
Galorath’s Ian Brown will be presenting this paper at the Canada ICEAA conference this week” Too often, organizations that contract for software development services are at the mercy of vendors for cost and schedule estimates. Once a program office releases a request for proposal for software development, it must somehow evaluate the validity of cost and schedule estimates that come back with the proposals. Or a program might have a limited budget or schedule but not a clear understanding of what amount of development is actually feasible within these limitations. This presentation proposes an approach that can help buyers of software take control of this situation by providing the ability to objectively evaluate software development proposals, select the best value for their needs, and effectively manage acquisition costs from kickoff to product delivery.
Ian points out the following major considerations:
- The software acquisition process is often loaded with uncertainty
- Two maxims are critical to effective estimation on software development projects
- Estimation should facilitate communication between developer and customer
- Scoping is important
- Objective, transparent methodology serves as your roadmap through the fog of software acquisition
- Watch your step in the fog –avoid pitfalls and bad decisions by considering other key factors
- Keep the fog away with periodic re-estimation throughout the project life cycle
- Examples of viable estimation approaches with SEER for Software (SEER-SEM)
Read the full paper here.Go Back
As one of the nation’s largest privately held third-party benefits administrators, Total Administrative Services Corporation (TASC) was experiencing rapid growth of over 20% every year along with the company’s product development capabilities and capacity growing at a similar rate. TASC needed to measure productivity improvements within the software development team as they improved their development processes and implemented a new continuous software delivery model.
The number one challenge for CIOs is defending and demonstrating how much software development costs. Because software is activity-based, you can’t just deliver a bill of materials. The costs to write software have a lot to do with the amount of functionality the project is designed to deliver, its level of complexity and the desired level of quality, as well as the capabilities of the software development personnel, the processes, tools, and other project environmental factors that can influence productivity.
“We develop most of our product administration software internally and we wanted to be better able to measure our productivity within the software development function. It can be maddeningly hard to measure software development productivity, and you can’t improve what you can’t measure”, explained Karl Richards, CIO of TASC. “Our goal is to be able to measure our results, so we can clearly understand the impact of our actions and demonstrate the value we are contributing to the organization,” said Richards.
After considerable research and exploration, a consultant suggested that Richards look at SEER for Software. While Richards had heard of these estimation methods being used by government agencies and large development shops, at the time, he didn’t think that it would be useful or applicable for midsize businesses like TASC. After working with Galorath to better understand the SEER solution, TASC decided to implement SEER for all new software development projects. TASC was able to achieve more than was originally planned and derived several important results for the organization that enhanced both the productivity and the credibility of the TASC IT team.
Richards commented, “Not only are we faster at delivering the estimates, we no longer need to have our best and most costly resources spending time on the estimation process. We’re now able to empower our Project Managers to take over that role.”
TASC has been estimating projects in SEER and then returning to review benchmark data after the project has finished. That process has allowed them to also develop a mechanism to track project execution productivity over time and therefore be able to analyze trending and react accordingly. “All that data is being captured in SEER today and we had no way to obtain that data before,” said Richards. “The data also helped us learn about the complexity of the functions we’re developing and gain a better understanding of our risk analysis throughout the Software Development Life Cycle.”
One of the most measurable accomplishments was experienced almost immediately when on a large integration project, SEER demonstrated that TASC was heading down a path of unfavorable economics. Because of the early visibility, changing direction allowed the team to deliver an 82% Internal Rate of Return (IRR) on this project instead of a negative net value, saving both time and lost opportunity cost. That kind of early visibility enhances credibility with the leadership team and has also given the team a level of confidence to look at using SEER for vendor evaluations as it contemplates full software module outsourcing for certain projects. Richards says, “I know that I will never have enough resources to accomplish everything requested of IT, so I see SEER giving me the intelligence to spend IT dollars as strategically as possible, and that’s a competitive advantage for TASC.“Go Back