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.

As we embark on 2017, which is also the 30th anniversary of IFPUG Bylaws, there are reports that the software development industry is making progress. The 2015 Standish Group CHAOS report cited that agile projects are, on average, three times more likely to be successful than waterfall projects (based on their survey of over 10,000 projects.) The not-so-good news, however, is that the percent of successful projects (defined as on-time, on-budget, and with a satisfactory result) hasn’t changed much since the first CHAOS report in 1996, and hovers around 40%. The top three success factors in the 2015 report were not technical: 1. Executive Support, 2. Emotional Maturity and 3. User Involvement (agile processes ranked #7.) The need for software sizing measures to support project estimating remains just as critical as it was 30 years ago, yet IFPUG function points are not used as extensively as they could be to support software sizing. Rather than “throwing the baby out with the bathwater,” so to speak, or creating new metrics to solve old problems, Carol Dekkers and Joe Madden suggest a new way to repurpose function points to achieve estimating successes today. This article was originally published in IFPUG's Metric Views.

Read the full article!

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