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.

I work for QSM, a leading software project estimation and demand management company. We focus on top-down estimation, meaning we figure out the total project duration and effort before any detailed planning occurs. We use SLIM-Estimate also known as the Putnam Model. Larry Putnam Sr. introduced SLIM in 1978. It is one of the leading software estimation tools in the world, validated with over 35 years of industry leading research and updated regularly with the latest technologies. 

Many people call us for help with team size software project estimation, they want to see how many people it’s going to take to deliver a specified amount of functionality within a certain duration and budget. At the time they call us they are often using task level planning tools to try to figure this out. 

The problem is that it’s tough to allocate people and the number of hours they will work when they haven’t figured out the specific requirements of each task and when they haven’t estimated the total duration and effort for the overall system. A manager could spend days creating a task level plan that doesn’t add up to the overall project duration and budget that is needed to deliver the functional requirements. When it doesn’t add up then re-planning has to take place costing more time and money. This is why QSM recommends estimating the big picture first, the scope level.