If you were unable to attend our recent webinar, "Making Better IT Cost & Scope Decisions with Top-Down Estimation," a replay is now available.

This year thousands of software, cloud migration, and IT development managers will spend long hours developing very detailed, bottom-up plans. Unfortunately, many of these plans will be unreliable, because they don't take into account the big picture. Generating top-down estimates, before detailed planning occurs, allow managers to see the overall development and delivery targets for cost and scope. This allows for managing project expectations and even negotiation before work gets underway.

This presentation includes a Q&A session with the audience and covers such topics as:

• How to generate top-down estimates early in the decision-making process
• Best practices for IT estimation
• How to leverage historical data to improve estimation

Keith Ciocco has more than 30 years of experience working in sales and customer service, with 25 of those years spent with QSM. As Vice President, his primary responsibilities include supporting QSM clients with their estimation and measurement goals, managing business development and existing client relations. He has developed and directed the implementation of the sales and customer retention process within QSM and has played a leading role in communicating the value of the QSM tools and services to professionals in the software development, engineering and IT industries.  

Register now to reserve your spot for this webinar presented by Keith Ciocco on Sept. 15th at 1 PM EDT.

This year thousands of software, cloud migration, and IT development managers will spend long hours developing very detailed, bottom-up plans. Unfortunately, many of these plans will be unreliable, because they don't take into account the big picture. Generating top-down estimates, before detailed planning occurs, allow managers to see the overall development and delivery targets for cost and scope. This allows for managing project expectations and even negotiation before work gets underway.

In this session, you will learn:

• How to generate top-down estimates early in the decision-making process
• Best practices for IT estimation
• How to leverage historical data to improve estimation

About the presenter:

In most organizations, spreadsheets play a vital role for a variety of uses, from time keeping to budgeting to even estimating software development releases.  They offer a level of familiarity - most of us cut our technical teeth on spreadsheets from a young age and have grown with them as we advanced our careers.  When it comes to estimating software development, spreadsheets are a common “go-to,” but an estimation tool offers more flexibility, timely “what-if” changes and far less complexity for new and seasoned estimators alike.

Have you ever been in an organization in which the estimation spreadsheet was so complex and cumbersome that only a select few knew how to use it?  This leaves an organization vulnerable to perhaps a single link of institutional knowledge upon which they are making vital business decisions.  And if that one project manager, analyst or architect leaves the organization, switches roles, or retires, what then?  Even if they go on vacation for 2 weeks, you’re left with a spreadsheet that may have an impossible learning curve for anyone else hence delaying or possibly negating the estimates being created at all.

In talking with many organizations about their IT estimation practices over the years, I’ve noticed a recurring theme has been their self-perception of immaturity when addressing the use of a commercial estimating tool. Estimates in the workforce are typically generated via the Delphi method, multi-tabbed spreadsheets, and uncalibrated guesses.  When recommending a top-down tool approach, the feedback can be: “we aren’t mature enough to use a tool or model.” 

I’ve actually seen the opposite.  The top-down approach offers an on-ramp to more formal estimating by its very nature of needing few inputs, rather than the myriad of cells, rows, and columns required to be populated in a spreadsheet.  A top-down tool approach leads us away from relying on the institutional knowledge of a few people that may have relevant experience, but one day may retire or move on from the organization taking that knowledge -with them.  Also, a parametric top-down approach leveraging relevant historical data is much better than a wet thumb in the air.

In agile development, it's not unusual for software teams to have a fixed schedule or budget before any work begins. This is great information for stakeholders, but what if those targets are unrealistic? What if there were a way to evaluate trade-offs early in the decision-making process, before any detailed planning occurs?

With a top-down estimation tool like QSM's SLIM-Estimate, your scrum teams can quickly determine how much functionality they can deliver in a planned release schedule. If that target schedule turns out to be unrealistic, you can leverage SLIM-Estimate's time-tested models to calculate the impact of trade-offs. What happens if you add more people to the project? If the schedule is non-negotiable, how much functionality can you deliver in that period of time? SLIM-Estimate provides you with visualizations that are powerful when presenting to senior-level management and stakeholders. Plot your estimates against relevant agile trendlines from QSM's database of over 13,000 projects (the largest of its kind) and you can see how your estimates check out against the industry.

The video above shows how to use this powerful tool to generate defensible agile estimates you can present to stakeholders early in the planning process. Having data-driven information like this at your fingertips will allow you to plan and negotiate, and maybe even avoid disaster.

When a project goes over schedule, costs too much money, or doesn’t deliver the desired functionality, business leaders may wonder what could have been done differently. Why not ask a professional estimator? Often, these are the people holding the crystal ball - those charged with planning and assessing the project before it even gets off the ground.

We recently polled our own seasoned estimation experts at QSM to find out their thoughts. With many years of forecasting, tracking, and benchmarking software projects under their collective belts, everyone from our consultants to our support and sales teams chimed in to compile a list of what estimators consider to be the most critical software development management issues. In this article, Don Beckett shares these lessons learned (and methods to solve them), which are invaluable to both project managers and C-level business leaders alike.

Read the full article!

Early project decisions, when not much is known, are easily the hardest. They're also often the most critical. Maybe you've found yourself in a position where you need to communicate to stakeholders what your work is going to cost and how long it will take to deliver. Feeling the pressure to deliver, you might have to make decisions based on gut feel instead of past performance. This can lead to setting unrealistic targets and often results in projects going late or over budget. 

At QSM, this is when we recommend turning to historical data. Whether it's your own data or trendlines from the 13,000 validated projects in the QSM industry database, leveraging actual completed projects can make your estimates more reliable. 

Believe it or not, collecting your own project history isn't as difficult as it sounds. We recommend capturing just a few basic metrics: Functionality Delivered, Total Effort, and Total Duration. Once you have this information, you can calculate a Productivity Index, which is the measure of productivity for the overall project or release. Then all of these metrics can be leveraged by any of the other project lifecycle tools in the SLIM-Suite for estimating, tracking, and benchmarking.

In the video above, you can see how easy it is to gather your own completed projects to use early in the planning process and determine if your estimates are reasonable or not. This helps you understand the big picture before you make any important project or portfolio decisions. 

How large is your project?
It’s projected to cost $2,000,000.
That’s cost. not size!

How large is your project?
We believe it will take 14 months to complete.
That’s schedule, not size!

How large is your project?
It’s going to be a 25-person project.
That’s staff, not size!

Software estimators often think of project size as what a project produces (features, stories, requirements, function points, or code). These are what a project has to create or account for in order to fulfill its mission. Business leaders, understandably, are more likely to visualize project size in terms of resources expended (cost, time to market, or FTE staff).  These competing definitions of “size” can produce confusion and ambiguity. Which leads us to Tip #1.

Tip 1

Be prepared to explain to business leaders how quantifying project size (as seen by an estimator) helps business leaders get more accurate estimates of the things that matter to them: cost, schedule, quality, and staffing. I find a graphic like the one below from SLIM-Estimate can be useful to illustrate the relationship between a project’s size (primarily of interest to development staff and project managers) and the major project management metrics of interest to the C-suite.

Background

No two software projects are exactly alike. So, one way to find out what a “typical” software project looks like is to take a large sample of completed projects from the QSM historical database of over 13,000 completed software projects and look at measurements of central tendency for staff, effort, size, schedule duration, and productivity.

For this study, QSM looked at validated projects that completed beginning in 2010. We eliminated 1 person projects and those that expended less than 1 person month of effort. The eliminated projects accounted for 13% of the sample. About 80% of the projects fell into the Business IT application domain, many of which were from the financial services sector. This domain includes projects that typically automate common business functions such as payroll, financial transactions, personnel, order entry, inventory management, materials handling, warranty and maintenance products. We determined both a median and an average for each metric. With the exception of schedule (project duration), these differed significantly which indicates that that the sample metric values were not normally distributed. To minimize the effect of unrepresentative projects (those that comprise a small part of the sample, but whose metric values are very large or very small), we decided to use the medians – values with 50% of the projects above and 50% below the “average” as a better measure of central tendency.

The "Typical" Project

If you were unable to attend our recent webinar, "How to Estimate Reliability for On-Time Software Development," a replay is now available.

Software development is a major investment area for thousands of organizations worldwide. The negotiation and early planning meetings often revolve around major cost and schedule decisions. But one of the most important factors, reliability, often gets left behind in these early discussions. This is unfortunate since early reliability estimates can help ensure that a quality product is delivered and predict if it will finish on-time and within budget. In this webinar, Keith Ciocco shows how to leverage the QSM model-based tools to estimate and track the important reliability numbers along with cost, scope, and schedule.

This presentation includes a lively Q&A session with the audience and covers such topics as: