Would you say it's resource capacity planning? Building continuous integration? Knowing if vendor bids are competitive? As a follow up to a recent post I shared on reducing uncertainty in digital transformation, I posed this question to my LinkedIn connections in a poll, giving them options I sourced from respected colleagues with experience in digital transformations. I also asked for suggestions not listed, in case there were challenges I might not have considered.  I appreciated the great feedback I received and wanted to share the valuable insights I gleaned from the poll.

42% voted for “Capacity Planning” as their biggest challenge, 29% voted for “Continuous Integration,” 10% voted for “Vendor Bid Evaluations,” and 19% voted “Other."

How many times have you been in a situation when plans for cost, quality, staff, or duration have been confirmed, but a few weeks later the program veers off track? Maybe the targets were unrealistic, the requirements changed, or there were communication disconnects along the way. Unfortunately, these issues happen all the time with digital transformation, often times after the delivery roadmap has already been set!

Digital transformation is a big topic these days and the benefits can be huge. Many organizations are re-examining the way they do business from rebuilding in-house systems, to moving to the cloud, to changing how they interact with their clients. They are trying to answer questions like: how can we improve our decision making processes? And how can we better support our clients? Building the technology to support changes can be a complicated road.  Wouldn’t it be great to be able to leverage a navigation system for these challenges? A system that provides a big picture view and also the necessary details to help guide your team as they move forward. At QSM, we provide this type of solution for our clients. It’s called SLIM-Control, a data-driven adaptive forecasting tool that curve fits to the actual data that directly reflects what’s happening throughout the transformation process.  The cost, schedule, and quality forecasts are generated by the actual data and QSM's empirically-based models.

Estimation can be time-consuming. Whether it's gathering initial requirements from stakeholders, performing risk trade-off analysis, or reworking estimates when plans change, these processes can take days or, worse, weeks that you simply don't have.

We hear that. And at QSM, our goal has always been to make the estimation process as quick and painless as possible. For almost 45 years, we've refined our tools to provide accurate project predictions with very few inputs required. Leveraging the power of industry data and proven mathematical models, you can generate defensible estimates within minutes and examine alternative scenarios without tedious rework. But as with any tool, there is a learning curve and we recognize how hard it is to find time in a busy schedule for training. We want to get you set up and reaping the benefits of our tools so you can get back to working with your team to ensure that your clients and stakeholders are happy with the overall product delivery. This is why we're introducing the SLIM Pilot QuickStart, a training and coaching program with flexible delivery designed to work with individual client schedules.

We believe the best way to learn is to learn by doing. The SLIM Pilot QuickStart program is an online, instructor-led live session that focuses on applying QSM's SLIM estimation tools and best practices to your current measurement problems. This "learn as you go" approach allows you to improve your estimation process quickly to improve the bottom line. The program centers around a 2-hour intro session filled with a wealth of information including: 

Moving to the cloud is big business these days. With any type of digital transformation; managing the migration, integration, and development work can be a stressful experience with a lot of risk. Wouldn't it be great to have a crystal ball that allowed you to make these big cost, staff and schedule decisions early in the planning process? I'll propose the next best thing: a database of completed and validated projects spanning multiple industries and development methodologies that can help you predict the way your project will behave.

The QSM Industry Database can provide this type of knowledge. With over 40 years of research and development, it includes metrics from thousands of completed technology projects from various application domains and industries. By leveraging this type of database, you can access industry benchmarks that can help you navigate the uncertainty that comes with planning IT transformations, software engineering, and cloud migrations.

What should this cloud migration cost? How long should it take? How many people will you need? What level of quality and productivity needs to be achieved to have a successful delivery? What are the chances of finishing within a 6-month time frame versus a 10 month? The secret to finding these answers is in the historical data. The way to bring that data to life is to use good scope-based estimation methods. In a view from QSM's SLIM-Estimate tool below, you can see some examples of how you might measure the size of a particular cloud migration to get started with an estimate.

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.

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. 

The short answer is with an estimate! Early decisions are a big deal when it comes to software development and delivery. Whether its agile or waterfall, we need to figure out what the work is going to cost and how long it’s going to take, oftentimes without detailed requirements confirmed. Estimates give managers a good way to start the conversation with internal stakeholders and with clients. Should we take this project on? Is this going to cost 5 million dollars or 10? Do we have the resource capacity to fulfill the demand? Should this take 6 months or 12? Management needs to know the answers, ideally before spending major resources and before detailed planning takes place. 

By looking at thousands of completed projects, QSM has found that big money can be saved by taking a quantitative approach to finding those answers. Early data-driven estimates give us the ability to set realistic targets and manage the uncertainty that goes along with early decision making. I am referring to “Big Picture” data-driven estimates, before sprint level planning takes place.

With the SLIM-Collaborate analysis below, we can see a staffing profile that shows a gold estimate along with a more conservative green one; a two column chart showing a comparison summary; a scatterplot showing a risky effort target compared to a more reliable alternative and an industry trendline; and we see a risky gold cost estimate compared to a green high assurance one. The data shown here is saving this company from making a bad decision, a decision that could cost them a lot of money, time, and quality.

Imagine a software development process where “Big Picture” estimates can be generated before detailed planning takes place, where the estimates can be accessed on the web, and where only three or four inputs are needed to generate reliable information. This process would include intelligent models that take into account historical data and there would be a back office team that specializes in software customization available to do the heavy lifting. Finally, there would be business analytics and industry data (plenty of both) to help with project target negotiations and risk trade-off analysis.

Thankfully, there are science-based estimation solutions available that include the capabilities mentioned above. These packages can make estimation easier, more transparent, and help manage the uncertainty that can come with early planning. There are technology organizations that are using these types of tools to improve their time to market and the accuracy of their software development estimates.

But there are many organizations that still struggle with estimation. They spend millions of dollars each year developing and delivering software. The planning usually starts with senior management asking tough questions about cost and schedule targets. The project leads then try to come up with effort estimates for each person on the project based on experience and gut feel. These effort numbers are tallied up in spreadsheets to come up with an overall estimate, the numbers are usually negotiated and then a final estimate is born. The problem with this process is that it takes a long time to carry out and the estimates are usually inaccurate. This is because the methods don’t take into account the non-linear relationships, integration, and overhead that we often see in software development.  When the estimates are off, millions of dollars are spent trying to change course. The rest is history. 

It happens time and time again. Clients look to their vendors to provide software development or configuration services and both sides are often left with big questions. Is the price fair? Can we really get the project done within our duration and resource goals? How can we negotiate for a successful outcome?

There are estimation solutions available that can help. The good ones will leverage empirically-based models, historical data, and industry analytics to uncover which proposals are feasible and which ones are risky.

In the first view below, there are two columns: the “Desired Outcome,” which is one vendor’s proposal and the second column, which is the data-driven “Recommended Estimate.”  The vendor is promising to complete the work in 3 months with a $750,000 price tag. You can see that this proposal is “Risky” and that the vendor will probably finish late and will either have to ask for more money or lose money in the long run.  The charts in the view provide a graphical representation.

In the second view for the same project, you see a second vendor’s proposal compared to the “Recommended Estimate.” The vendor’s bid is for 8 months with a $1,000,000 price tag and there is a “Moderately Conservative” rating. In other words, this vendor has a much better chance of achieving what they are promising. 

In many agile environments, the budget, team size, and schedule are fixed based on an organization’s predetermined targets for sprints or iterations. This leads many project managers to question if software estimation is even necessary. The problem is, without a reliable size estimate, the amount of functionality promised within the time and money constraints could be difficult to achieve and could cause the product delivery to be short on features, or late and over budget.

This is where scope-level estimation tools come into play. They can help evaluate whether targets are reasonable and, even if the schedule and budget are both set in stone, they can help figure out how much work can be delivered. This type of analysis helps set customer expectations and provides data driven leverage for negotiations.

The best estimation tools leverage empirically-based models, industry analytics, and historical data. They can even be used before iteration level planning takes place. They ensure that the overall goals are reasonable before detailed plans are developed. 

In the three views below, we see an estimate generated from a “Time Boxed” method. This is where the product manager was able to input the predetermined time, a productivity measure (PI), and a team size, to see how many story points could be completed within the set constraints. The analysis also includes a “sanity check” of the estimate, comparing it to an agile industry trend from the QSM Industry Database and their own agile historical data.