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.

QSM recently announced a major update to the QSM Software Project Database, a large and robust body of data that helps software and IT professionals estimate the cost, time and effort requirements for their software and systems projects. As a result, QSM clients and SLIM Suite users can benefit from the most up-to-date and expansive software project benchmarking data, particularly in the agile domain.

With this large update, we’ve validated and added more than 2,500 new projects across nine major application domains (Avionics, IT, Command & Control, Microcode, Process Control, Real Time, Scientific, System Software, and Telecom) and 45 sub-domains. The result is a database with more than 13,000 completed projects, extending what is already the largest continuously updated software project metrics database in the world.

With these enhanced data insights -- all gathered from real-world projects -- SLIM Suite users have access to the most up-to-date software project benchmarking data and can quickly and easily sanity-check estimates against industry data.

IT and Agile Projects Get a Boost

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.

Register for this webinar!

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!

QSM is pleased to announce a major update to the QSM Database, the largest continuously-updated software project performance metrics database in the world. With this update, we have validated and added more than 2,500 projects to the database in 9 major application domains (Avionics, IT, Command & Control, Microcode, Process Control, Real Time, Scientific, System Software, and Telecom) and 45 sub-domains, resulting in a current total of more than 13,000 completed projects.

With this update, the number of agile projects in the database increased by 340%, resulting in some changes to the agile trend line. Specifically:

Managing vendors has become increasingly important in recent years.  In my account management role at QSM, I see both sides of the vendor management relationship.  The client wants a proven vendor that will partner with them in achieving their IT goals; and the vendor wants to win that business, employ their workers, and hopefully earn more work.  Unfortunately, that state of client/vendor Zen is not often achieved, usually due to legitimate (and sometimes not) misunderstandings on both sides.

On the client side, they are concerned with selecting a vendor with whom they are confident their tasks and deliverables will be achieved on time, within budget, and of the best possible quality.  After a round of RFI’s, then RFQ’s, then a final down select process, the vendor is chosen and work begins.  Often, at least in my experience, the overriding decision criteria comes down to cost, which makes sense, to a degree.  But in many cases, cheapest, I mean, least expensive bids often rule the day.  This kind of decision-making comes with its own set of risks; the most obvious is you get what you pay for and it’s often an ill-prepared vendor.

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.

Often within technology organizations there is a general belief that increasing staff increases the amount of production. But what if there were better options? Wouldn’t it be great to see some additional management options using predictive analytics? This type of analysis could save organizations millions of dollars by showing how to hit their goals by just planning more effectively.

Where do you start? First, we recommend centralizing your project data so your information can be easily accessed. These projects can be completed, in-progress, or getting ready to start. The best way to do this is with a tool that lets you store the data and that also lets you generate the forecasts, all in one convenient place.

The next step would be to run built-in forecasting models to see if you can complete the required amount of work with the existing number of resources.  These models also provide other options to consider, like adjusting the number of resources on a software release or extending a project schedule to save money. The best models are empirically-based and time-tested. To generate the analysis, you need to enter some basic project level goals and the models then leverage historical data to forecast a reliable duration, effort, cost, and staffing assessment for each release.

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.