QSM is pleased to announce the release of SLIM-Suite 10.0, the latest version of our flagship software estimation, tracking, and benchmarking suite of tools.  With new quadrant chart visualization features, the updated version of the SLIM-Suite allows users to gain visibility into multiple projects at once and, as a result, easily identify high-risk projects, improve demand management, and address project feasibility issues early in the process. Additionally, users can now map staff capacity to portfolio demand to ensure that development resources are utilized across projects and available when needed.

In addition to the new visual capabilities, highlights of SLIM-Suite 10.0 include:

• Updated 2017 industry trends: Estimates now leverage the latest project data from 2017 to provide better metrics for more accurate portfolio planning.  
• New skills aggregation capabilities: This new feature expands upon the existing functionality to include detailed breakouts of effort, staffing, and cost by skill by month for subsystem tasks beyond Excel to include custom and SLIM-Control tasks in addition to SLIM-Estimate tasks.
• Better database management features: SLIM-Suite 10.0 allows easier detection of duplicate projects and improved data importing capabilities. 

“We designed SLIM 10.0 to make it easier for project managers to estimate projects, understand which projects are at risk and share this information within their organizations,” said Doug Putnam, Co-CEO for QSM. “SLIM’s new visualization tools make it possible to see an entire project portfolio at a glance, which we believe will lead to improved project success for our customers.”

QSM is pleased to announce our Function Point Workshop is now IFPUG-certified! This 2 day course focuses on building function point analysis skills to measure software development work products. Students will learn how to express the result in a standard, accurate, repeatable way based on the logical view of required functionality in the business and the end user's perspective. This standard technique promotes consistent sizing across multiple project types, and can be used to support project estimating, application maintenance, and portfolio analysis. Ultimately students will gain an initial understanding of the purpose, context, and rules for counting function points. This course is targeted to attendees with interest levels ranging from high level familiarity with the process to those who are beginning to prepare for certification. 

Learn more about about QSM's workshops and function point offerings.

No one got into software development to budget. Developers love to code and create. If they wanted to create budgets, they’d have become accountants. Still, creating a development plan for 2017 is essential and will inevitably require budgeting and estimating, a process that should be done in partnership with business teams. This will ensure the creation of software that cost-effectively meets their needs. In this article, originally published on SD Times, Doug Putnam identifies three strategies for better budgeting and planning in the new year.

Read the article!

The most effective project portfolio planning brings IT managers and business leaders together to prioritize, scope and staff initiatives as a single team with common goals. In doing so, the process fosters better working relationships — and provides a roadmap for delivering value to the organization. In this article for Projects at Work, Larry Putnam, Jr. outlines best practices on how to determine the maximum capabilities that can be delivered within the confines of budgets, resources, and time. 

Read the full article!

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.”

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. 

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 plays an increasingly vital role in our everyday lives. It powers everything from autonomous cars and aircraft, life-saving medical equipment, and the data that allows the government to protect our country. When companies develop software, there’s no room for error. 

That’s why software predictive analysis and estimation are still extremely important. Last year, with the release of the 2016 Software Almanac, we learned that the last 35 years of predictive analytics and estimation principles were still incredibly relevant for providing reliable and applicable business intelligence for implementing successful software projects.

This year’s version of QSM’s annual Software Almanac further strengthens those findings. The 2017 Software Almanac builds on the principles identified in last year’s publication and highlights the dangers of not applying predictive analysis and estimation processes.   As stated by Angela Maria Lungu, Almanac Editor and Managing Director at QSM, these principles can be a “double-edged rearview mirror.” If you move forward without applying the historical principles of estimation and analysis correctly, their value is diminished.   Here’s what else you can expect from this year’s Almanac:

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!

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.

I am a big sports fan and since I work for a software metrics company, I started thinking about the similarities in productivity measurement in both industries. From draft picks to game planning decisions, managers in sports measure their team’s productivity to help them make better decisions in the future. Software executives and product owners do the same thing; they measure productivity in order to make better planning decisions regarding upcoming projects.

To measure productivity in baseball, we look at measures like batting average, on-base percentage, slugging percentage, and earned run average. When measuring the productivity of agile software projects, we often look at the velocity, which takes into account the number of user stories completed in each sprint. This type of historical data helps us plan effectively at the detailed level.

As part of our work at QSM, we are often asked to provide plans at the release and portfolio level. To provide these plans reliably, we use a macro level, empirically-based productivity measure that encapsulates a number of project-related factors. This measure is called the Productivity Index, an integral part of the Putnam Model.  Also known as the SLIM Model, the Putnam Model was invented by Larry Putnam Sr. almost 40 years ago and is having a big impact on software measurement more than ever today.

Once we know the total number of user stories (or any size measure), the release level effort, and the duration, we can calculate the Productivity Index of a project. The Productivity Index also takes into account the project environment including: the experience level of the team, the complexity of the software, and the quality of the tools and methods being used on the project.