In 1990, former General Electric CEO Jack Welch wrote a prophetic passage in the company’s annual report. “Our dream for the 1990’s is a boundaryless company…where we knock down the walls that separate us from each other on the inside.” However, large enterprises who have attempted to live by Welch’s dream remain hampered by set hierarchies: development teams and product owners exist on one level, business management and system engineers on another, while enterprise architects and portfolio managers reside atop the organizational food chain. Employing a top-down estimation approach to project management can help organizations overcome boundaries and satisfy the three V’s of corporate success – vision, value, and velocity. This article, originally published in ISV Insights, takes a closer look at how this approach can work for software companies, particularly larger organizations, to help them improve project management, team collaboration, and development practices.

Read the article!

It’s a story we hear a lot in the software business these days, especially with agile development. New functionality is needed within a certain amount of time and within a certain budget. 

Some might say, "no problem! We can figure it out as we go along." They might feel comfortable because each sprint has already been set in stone.  But there are business-related questions that need to be answered before sprint-level planning takes place and before we commit to goals that might not be achievable at the release and portfolio levels. Should we agree to do this project? Can we really get all of the work done within our constraints? Will the software be reliable at delivery? How does this project impact our annual and multi-year forecasts? 

This is where having reliable big picture numbers can be helpful. Wouldn’t it be great if senior management and the technical team were on the same page early? There are empirically-based estimation tools that can help. The naysayers might say that the technical requirements aren’t firm enough to come up with early estimates before the sprint planning takes place. But the fact is that some of these models (the good ones) allow for managing uncertainty and they do it based on historical data. The slide below shows a summary example of a release-level estimate for cost, duration, and 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.

Successful software execution has always been about having the most relevant data at your fingertips, but there are more ways to gain knowledge beyond graphs and charts. The sharing of best practices and information on the latest solutions, along with access to communities of like-minded individuals, can also be powerful tools for managers responsible for delivering development projects within budget and on-schedule.

At QSM, we strive to provide not just the tools, but also the information needed to help these individuals succeed. That’s why, as we look forward to 2018, we are excited to offer a wealth of resources that go well beyond our SLIM-Suite of estimation tools. These eight resources provide insight and knowledge into some of the most important components of software estimation, including agile development and project management, as well as information specifically for SLIM users.

Agile Development

Large-scale IT infrastructure projects require an enormous amount of planning, design, configuration and testing to ensure that everything is working correctly and properly transitioned once the work is done. This takes time and resources. Like their software counterparts, IT infrastructure projects are more likely to be successful — more efficient, secure, and reliable — when accompanied by robust estimation and planning processes. In this article for ProjectManagement.com, Larry Putnam, Jr. and Joe Madden identify best practices for applying parametric estimation to IT infrastructure projects.

Read the article!

It’s that time of year again for many C-level executives: time to figure out the IT budget for next year. This is to bring the business side of the organization to the table with the technical side to forecast how much IT is going to spend. It can be a complicated process, but there are ways to make it easier and more accurate; and there are ways to save a lot of time and money. The challenges often relate to short planning time frames, minimal information available to generate accurate forecasts, political agendas within the organization, and, unfortunately, only a small number of estimation methods in place. But there are tools and processes available to help face these challenges. Here are the basic steps that we recommend for cost optimization in the budgeting process.

Start by analyzing the historical data that is available. The process can be streamlined by focusing on the core metrics within the organization. This data can include release level size, effort, staff, and duration information. Historical data showing typical effort by role by month spending is also valuable to leverage. Ideally, this type of data should be captured on 8-15 projects.

The next step is to pull together scope level sizing data on projects that are being considered for the new year. This information can include epics, themes, user stories, business requirements, or use cases, to name a few. The goal here is to get as close as possible to determining how much work needs to be done on each release in the pipeline. Once there is a large enough sample of data, then release level estimates can be created for the coming year. There are tools available to help streamline this process and the best ones allow for risk mitigation and sanity checking with historical data.  

The Scaled Agile Framework (SAFe) has realized widespread adoption by organizations desiring to accelerate product delivery without sacrificing quality. The alignment of product vision, business value, and development velocity is an key contributor to successful large-scale agile development.  Presented by QSM's Laura Zuber on June 20 at 11:00 AM EST, this upcoming ITMPI webinar demonstrates how scope-based estimation techniques can be used to model the relationship between vision, value, and velocity at different levels of the framework and stages of implementation to guide release planning and management decisions.

Laura Zuber has 25 years of experience in software development consulting, training, and support. She has conducted training and coaching sessions for all QSM SLIM-Suite tools and helped customers implement SLIM across a wide variety of processes and platforms. Laura has managed software development projects, served as a senior software process improvement specialist, performed process assessments, designed and implemented best practices, and authored numerous training programs. She is a Certified Scrum Master and lead consultant for using SLIM with agile development.

Watch the replay!

For a number of years, the federal government has been on a mission to reduce waste and enhance efficiencies across departments, including IT. But according to the CIO Council’s 2017 State of Federal Information Technology report, 43% of the federal government’s $80 billion in IT projects cataloged in September 2016 were listed as over budget or behind schedule. In this article for GCN, Doug Putnam takes a look at some of the common pitfalls that lead to project cost and schedule overruns and how parametric estimation can help government CIOs and their teams avoid these traps.

Read the article!

With agile projects, we hear a lot about the planning benefits of having a fixed number of people with a fixed number of sprints.  All great stuff when it comes to finishing on time and within budget. But one of the things we also need to focus on is the quality of the software.  We often hear stories about functionality getting put on hold because of reliability goals not being met.

There are some agile estimation models available to help with this, and they can provide this information at the release level, before the project starts or during those early sprints. They provide this information by leveraging historical data along with time-tested forecasting models that are built to support agile projects. 

In the first view, you can see the estimate for the number of defects remaining. This is a big picture view of the overall release. Product managers and anyone concerned with client satisfaction can use these models to predict when the software will be reliable enough for delivery to the customer.

In the second view, you can see the total MTTD (Mean Time to Defect) and the MTTD by severity level. The MTTD is the amount of time that elapses between discovered defects. Each chart shows the months progressing on the horizontal axis and the MTTD (in days) improve over time on the vertical axis. 

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!

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.