The staff build-up plan defines how many, what kind, and when staff are needed for the entire project. Too many or too few, bringing them on too early or late, employing the wrong mix of expertise or experience - avoiding all these pitfalls with a staff build-up plan will ensure a successfully staffed project. Reviewing proposals for a complex project, such as major software development or support, is a challenging activity. Since labor is the major cost and feasibility determinant for such projects, requiring the submission of a "staff build-up plan" and verifying its realism is crucial in determining whether a proposed project can realistically succeed. In this article for Contract Management Magazine, QSM's Gene Shuman identifies the key components of an effective staff build-up plan.

Read the full article!

QSM is pleased to announce we have recently been selected as one of the 20 Most Promising Productivity Tools Solution Providers by CIO Review. In the last few months, CIO Review has analyzed hundreds of productivity tools solution providers and shortlisted the companies that are at the forefront of tackling challenges in the arena. A distinguished panel comprising of CEOs, CIOs and analysts including CIO Review’s editorial board has selected the final list of Productivity Tools Solution Provider of 2015. In their selection process, they looked at the vendor’s capability to fulfill the need for cost-effective and flexible solutions that add value to the productivity tools landscape.

QSM establishes a productivity baseline for its customers’ projects, identifying immediate opportunities for improvement, while providing the ability to measure the return-on-investment (ROI) once those improvements have been implemented. QSM's Software Lifecycle Management (SLIM) tools support better decision making at each stage of the project development lifecycle.

Read the full report.

Let’s face it -- times have changed since the initial principles of predictive analytics and software estimation were established. Today more than ever, we live in a time where there is an incredible dependence on software – it is the cornerstone of almost every business. Risk management and cyber vulnerabilities are now major concerns that weren’t even on the radar decades ago. 

The 2016 version of the QSM Almanac, released earlier this week, takes a truly unique look at the last 35 years of predictive analytics and estimation for business intelligence to determine if its previously developed principles are still applicable today, and, if so, how those principles apply to the current state of software projects. The results are somewhat incredible, and I thought I could share a few of the highlights from this year’s resource as a preface to the full (and free) Almanac, which can be downloaded here:

We speak to a number of scrum masters, project managers, and CIOs each month. QSM does research on software development projects - all types, including agile and waterfall. We work with a huge database of completed software projects, updated with new industry data on a regular basis. We provide predictive analytics and we study cost, schedule, risk, quality, size, resource demand management, business intelligence, and vendor management.

Within the last couple of years, we have been hearing some agile managers say that there is no need to estimate agile projects. They say that they are managing in smaller increments or sprints and that they already know how much velocity can be achieved. They also say they are constantly “grooming the backlog” so there is no need for a formal estimation model to forecast the amount of work that needs to be done. They are managing at the sprint and task level so they feel like they have everything under control.

The bottom line is that agile projects still need to be estimated to see the big picture: the release estimate. It's essential to know the release cost and effort before the project plan is handed off to the scrum master and before committing to the customer. The negative feedback we hear regarding estimation is somewhat ironic because agile processes actually lend themselves very well to formal estimation since they promote the use of size measures like user stories, story points, and epics. Having good size information is a big part of estimating successfully.

Major corporations spend millions of dollars each year writing proposals to win software and systems business. They typically have a team of people that spend hours or days in strategy meetings to write what they hope will be a winning bid. Usually these companies are responding to a “Request for Proposal” which is sent out to a number of competitors. It’s almost like a sporting event. Let the games begin! Our team versus theirs. Sometimes jobs are on the line. No one wants to have to lay off people because there is not enough business coming in the door.

As part of this process, a project plan will be created. Oftentimes the team will work out a plan based on some previous experience and the opinions of a number of subject matter experts. Usually the plan will include a detailed spreadsheet with a larger number of tasks and the hours that it will take to complete each task.

The fact is most people don’t have a way to validate whether or not the plan is reliable. They also can’t see what chance they have of achieving their overall promised schedule, quality, and budget goals. They don’t have an easy way to negotiate these proposal decisions internally or with the client.

What's missing? A top-down, empirically-based estimate. Running a top-down estimate allows the proposal team to generate a “big picture” estimate for cost, duration, risk, and quality based on historical data and time tested mathematical models. With SLIM-Estimate (shown below), the team can run an overall project level estimate, and sanity-check their proposal with industry trends to make sure that their numbers are competitive and realistic.

If you were unable to attend our recent webinar presented by QSM's Andy Berner, a replay is now available.

As companies try to innovate and at the same time keep software development costs in line, balancing the projects you plan with the resources you need becomes a major challenge. Portfolio and resource management systems, such as CA PPM (formerly known as CA Clarity), have many of the ingredients you need to meet that challenge, but a key ingredient is missing: credible resource demand for the projects you plan to do.

Andy Berner shows how QSM SLIM-Estimate’s Top-Down Resource Demand capabilities provide that missing ingredient. He explains how SLIM-Estimate predicts resource needs for your projects and why it provides the best demand estimates for resource planning. He demonstrates how SLIM-Estimate provides demand information in a way that matches your resource planning process, and how integration with SLIM-Estimate enables the successful use of the resource management capabilities of your portfolio management system.

Watch the replay!

One thing that I hear from project managers on a regular basis is that estimating a software project is a really tough thing to do. I have to tell you that it doesn’t have to be that way. Here are some reasons why project estimation can be easier than you think.

In a recent webinar on using the SLIM tools and methods in an agile environment, we showed a template for agile projects included with SLIM-Estimate. I was asked, "Since agile teams are a fixed size group that stays together throughout the work on the release, why doesn’t the agile template use the Level Load shape?" My answer was the typical short answer to a complex question, "It’s complicated and it depends." In this blog, let’s take a look at some of those complications and dependencies.

The team, the whole team, or nothing but the team?

When using SLIM-Estimate to estimate the effort required for a release, agile or not, you have to decide, "Whose effort are we interested in?" When describing a team in a scrum project, we usually talk about three major roles: product owner, scrum master, and team member. These people are, in general, full time on the project. If you are only interested in estimating the effort of these full time team members, then you may want to use the “Level Load” shape in SLIM-Estimate. The total effort of these people is based on the number of people multiplied by the duration of the work on the release.

We're happy to announce the launch of SLIM-Collaborate™ 2.0, the solution formerly known as SLIM-WebServices. The new name better represents how our customers use this "light and lean" version of our trusted software estimation, tracking, and benchmarking suite. 

As technology has become more integrated into every facet of our work and life, the number of stakeholders in software projects has grown. Collaboration among all of these parties is critical in making sure software is designed, developed, and deployed correctly. Not everyone involved needs the detail and power of our SLIM solution, but they all need visibility into project status. SLIM-Collaborate gives that transparency with an easy-to-use interface and dashboards designed with business users in mind. This transparency and involvement of all users improves estimation accuracy and ultimately achieve software project goals on time and on budget.

This update is not just a facelift; we’ve updated more than just the name. The new version includes a number of new features and enhancements that help the entire project management team estimate, implement and track its projects to avoid failure, such as:

QSM is a leading demand and vendor management company. We have many years of experience working with outsource management professionals, evaluating software project vendor bids and monitoring the development progress of those bids for our clients. We are often hired to help them with their vendor management process because their past projects have failed to meet cost, effort, reliability, and duration expectations. 

It starts with the independent estimate and bid evaluation process. Our main clients are CIOs, PMO managers, purchasing managers, software project managers, and business stakeholders. Our clients will usually have a large software development or package configuration project pending. They are initially trying to figure out which vendor to hire. Vendor A will offer them a bid of 20 million dollars with a specified duration commitment and Vendor B will offer them a bid of 30 million dollars with a different duration commitment. How do we know which vendor to choose? Can Vendor A really finish with a lower cost and shorter schedule? Is the system going to work when it’s done?

The way it usually works is the client will make a decision based on their experience or gut feel. Or if they have already worked with a specific vendor in the past they will go with that vendor again based on some personal relationships that have evolved. Then the problems start. The work that was promised doesn’t get done within the promised time or the promised budget. The vendor then comes back and says they will add people to the project and everything will be ok. The client approves the revised project plan since they don’t have a way to confirm the accuracy of the revised proposal. Then even bigger problems start. More money is wasted, the schedule slips even more, and relationships sour.