Estimation

Estimation

New Article: Leveraging the Power of Historical Data Through the Use of Trend Lines

Size vs. Staffing

Developing software within the DoD presents a unique set of challenges, including but not limited to budget cuts, Congressionally mandated changes, changing software requirements, and so on. It should come as no surprise, therefore, that cost estimators have faced significant challenges when estimating systems in the Defense arena. A recent initiative put forth by the DoD was to improve its estimation process by leveraging historical data collected from forensic analyses of recently completed software development efforts. This article by Taylor Putnam-Majarian and John Staiger, discusses (1) some of the challenges faced throughout this initiative, (2) the data collection process, and (3) how one can leverage data to improve cost estimates. This article was originally published in Crosstalk Magazine.

Read the article!

Blog Post Categories 
Articles Data Database Estimation

Selecting the Right Software Estimation Tool for Your Business

Estimation Tool CHecklist

Organizations often come to us in the early stages of shopping for a software estimation tool and, oftentimes we find that they could be asking some additional questions. They often focus on the tool’s operating system, database structure, and architecture, when they could also be focusing on the quality of the data behind the tool. They also ask a lot of questions about inputting detailed information when really it would be in their best interest to focus on solid project-level information since detail-level inputs are often not available early in the planning lifecycle. Instead of focusing on the number of hours allotted to each individual person, it would be more beneficial to focus on how much work the overall team needs to finish.

In our 30+ years of experience in this industry, we've found that, no matter what tool an organization ultimately chooses, they need to be asking the right questions. Here is the criteria they should consider.

Tool Capability

As with any tool, it is important to match the tool with the job at hand. Using a screw driver to perform the task of a chisel will yield poor results. The same is true with trying to use a detailed planning tool in place of a software estimation tool. Make sure that you consider at what point in time formal estimates are required and how the resulting information is used to support negotiation and business decision making. Here are the main issues that should be taken into consideration when assessing an estimation tool.

Blog Post Categories 
Estimation

Not Just for Software: How Estimation and Sizing Can Help You Plan a Successful IT Infrastructure Project

Estimation and Sizing for Infrastructure

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

While creating technology is about solving everyday problems, the act of creating technology is about solving design problems. This applies to any type of technology project, regardless of its purpose or size. Organizations must put as much thought and consideration into the design of their underlying IT infrastructures as they do in the design of their software projects. Both require careful sizing, estimation and planning.

Of course, installing, configuring and testing IT infrastructure is different than developing a piece of software. A typical IT infrastructure project could include:

  • Server room buildout (clean power, fire prevention, disaster recovery, cabling, etc.)
  • Network connectivity (local and wide area network)
  • Installation of computer server hardware (can be physical or virtual)
  • Configuration of system software on the servers (operating system, database, email server, web server, security template, etc.)
  • Configuration of computer desktops, laptops, smart phones. peripherals and other Internet of Things (IoT) devices 

Together, the hardware and software formulate a truly complex system where all of the parts are interconnected.

Blog Post Categories 
Estimation Sizing Infrastructure

AI and Automation Make Software Reliability More Important Than Ever

AI and Automation Software Reliability

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

If you were thinking about purchasing a driverless car, and the salesperson told you that there’s a “slight” chance that the car will fail during transit, would you still feel comfortable laying down your money? Or, if you faced an emergency, would you trust an automated robot to perform open-heart surgery, rather than the hands of a skilled physician?

While these questions might seem like the stuff of a science fiction novel, they’re quickly becoming a part of our normal, everyday world. We’re hearing a great deal about artificial intelligence and how it is replacing tasks that were once done by humans. AI is powered by software, and that software is becoming increasingly vital to our lives. This makes ensuring its reliability more important than ever.

But here’s a sobering thought: right now, IT operations teams are building software that is, on average, 95% reliable out the door. That’s right; today, a 5% unreliability gap is considered “good enough.”

Blog Post Categories 
Estimation Quality

How Can We Leverage Summary Level Analytics to Support Enterprise Planning?

What if you could leverage summary level cost, duration, and productivity data to support estimates for future projects, at the release and enterprise level? C-level executives, development managers, and project stakeholders are all involved at some level in project planning. They want quick access to information on a regular basis and they want web-based solutions to make it happen. So how does it all work? There are web-based analytics tools that allow you to create a centralized database for all of your projects. These tools store the data, leverage it to generate project and portfolio estimates, and then provide a communication vehicle throughout the organization to ensure that everyone involved is on the same page. It all starts with having the data in one place. 

Software Project Database

Once you have all of your project data in one place, then you can focus on analyzing the completed projects. You can compare them against industry trends and leverage a 5-star report to show how they rate on performance in the industry. The initial measures to focus on would be size, duration, effort, reliability, and productivity. A project's productivity will be calculated automatically once you have entered the size, duration and effort. We call this measure a Productivity Index. This measure can be compared to industry and used as a benchmark to measure process improvements over time.  These numbers give you a quantitative picture of your current project environment.  

Software Project Closeout

5 Star Report

New Article: Big Rock Estimation in Agile

Agile Big Rock Sizing

Big Rock Estimation: Using Agile Techniques to Provide a Rough Software Schedule / Resource Estimate is the third article in the QSM Agile Round Table series.  The QSM Agile Round Table was formed to discuss the role of estimation in agile environments.  QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment.  The Round Table spent several meetings on the key topic of sizing an agile release. The discussion centered around two main questions:

  1. How can you determine the size of a release early in absence of a “big upfront requirements phase,” and thus when the requirements are only known at a very high level and subject to refinement and change?
  2. How can you determine size in a consistent way across multiple products, projects, and agile teams so that you have good historical data on which to base an estimate?

This and the next article in the QSM Agile Round Table series are based on those discussions. Aaron Jeutter, a participant in the Round Table from Rockwell Automation, presented the technique of “Big Rock Sizing.”  This technique is used at Rockwell Automation for early sizing and estimating based on high level requirements that will be refined using agile techniques as the work progresses.

Read the full article!

Blog Post Categories 
Articles Agile Estimation

Agile Development and Software Estimation: Two Processes That Go Great Together

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

New approaches to software development can sometimes seem at odds with the needs of business customers. For instance, ardent practitioners of the agile development methodology continue to advocate for rapid response approaches and the need for constant iteration to solve complex problems. On the other hand, companies and customers are demanding a strategic approach that provides insight into process, timing, and costs.

So, which of these yin and yang scenarios should developers employ? The answer is “both.”

Enter scope-based software estimation, which I maintain can be a powerful tool to ensure that projects remain on course and on budget. It is possible for schedule and budget estimation to be achieved without sacrificing any of the things that make agile development so potent.

Not everyone feels the same. Some would argue that there’s simply no place for estimates in an agile development world; that estimates cannot coexist with agile or “lean” methodologies like Scrum, which encourage teamwork, speed, and communication without constraints.

The More Things Change: The Evolution of Software Estimation and Development Over the Past 35 Years

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

The term “true original” is used to describe someone who is a trailblazer -- and it describes my father to a T. My dad was an early architect of software estimation, the process of predicting the time, effort, and manpower it takes to complete a software development project.

Thirty-five years ago, my father was a budget director for the Army’s computer programs. He had the unfortunate experience of having his funding significantly reduced when his IT team failed to properly articulate its software development goals in ways that were relatable to leaders. As a superior put it, “Whenever I talk to the IT guys, I hear about bits and bytes, programming languages, and bandwidth, but nothing that relates to time, effort, and cost.”

That comment sent my dad on a mission to develop a software estimation frameworkthat addressed the three points that his boss was most concerned about. He sought to expose what he called “a fundamental law of nature in our software production equation.”

Blog Post Categories 
Estimation

New Article: Estimation Center of Excellence

Estimation Center of Excellence

Why do so many companies fail at software development projects? More often than not, they haven’t built a foundation of process, people and tools to accurately plan and estimate. An Estimation Center of Excellence is a great starting point to bring these components together and maximize their benefits. In this article for Projects at Work, Larry Putnam, Jr. describes how all of these components work together to help organizations achieve software project success.

Read the article!

Blog Post Categories 
Articles Estimation

Eliminating the 18-Hour Work Day in Software Development

Software Development "Death March"

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

It may seem absurd to think about working an 18-hour day, but it happens all the time in the software development community. If managers don’t accurately estimate project schedules based on a clearly defined scope of work, managers and their development teams may find themselves working long days to deliver on promised deadlines and deliverables.

Being overworked in an environment where a project is running over schedule can also lead to the delivery of a defective or flawed product, which is bad for both the development organization and the business unit for which the product is being developed. One article that I read recently states that time pressures cause employees to cut corners and that the 18-hour workday does not allow for forward or creative thinking. This can be disastrous to an organization that values both the quality of work and the out-of-the-box thinking of its development team.

Blog Post Categories 
Schedule Estimation