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

What if you could leverage summary level cost, duration, and productivity data to support estimates for future projects, at the release and enterprise level? C-level executives, development managers, and project stakeholders are all involved at some level in project planning. They want quick access to information on a regular basis and they want web-based solutions to make it happen. So how does it all work? There are web-based analytics tools that allow you to create a centralized database for all of your projects. These tools store the data, leverage it to generate project and portfolio estimates, and then provide a communication vehicle throughout the organization to ensure that everyone involved is on the same page. It all starts with having the data in one place. 

Once you have all of your project data in one place, then you can focus on analyzing the completed projects. You can compare them against industry trends and leverage a 5-star report to show how they rate on performance in the industry. The initial measures to focus on would be size, duration, effort, reliability, and productivity. A project's productivity will be calculated automatically once you have entered the size, duration and effort. We call this measure a Productivity Index. This measure can be compared to industry and used as a benchmark to measure process improvements over time.  These numbers give you a quantitative picture of your current project environment.  

Big Rock Estimation: Using Agile Techniques to Provide a Rough Software Schedule / Resource Estimate is the third article in the QSM Agile Round Table series.  The QSM Agile Round Table was formed to discuss the role of estimation in agile environments.  QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment.  The Round Table spent several meetings on the key topic of sizing an agile release. The discussion centered around two main questions:

1. How can you determine the size of a release early in absence of a “big upfront requirements phase,” and thus when the requirements are only known at a very high level and subject to refinement and change?
2. How can you determine size in a consistent way across multiple products, projects, and agile teams so that you have good historical data on which to base an estimate?

This and the next article in the QSM Agile Round Table series are based on those discussions. Aaron Jeutter, a participant in the Round Table from Rockwell Automation, presented the technique of “Big Rock Sizing.”  This technique is used at Rockwell Automation for early sizing and estimating based on high level requirements that will be refined using agile techniques as the work progresses.

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.

New approaches to software development can sometimes seem at odds with the needs of business customers. For instance, ardent practitioners of the agile development methodology continue to advocate for rapid response approaches and the need for constant iteration to solve complex problems. On the other hand, companies and customers are demanding a strategic approach that provides insight into process, timing, and costs.

So, which of these yin and yang scenarios should developers employ? The answer is “both.”

Enter scope-based software estimation, which I maintain can be a powerful tool to ensure that projects remain on course and on budget. It is possible for schedule and budget estimation to be achieved without sacrificing any of the things that make agile development so potent.

Not everyone feels the same. Some would argue that there’s simply no place for estimates in an agile development world; that estimates cannot coexist with agile or “lean” methodologies like Scrum, which encourage teamwork, speed, and communication without constraints.

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.

The term “true original” is used to describe someone who is a trailblazer -- and it describes my father to a T. My dad was an early architect of software estimation, the process of predicting the time, effort, and manpower it takes to complete a software development project.

Thirty-five years ago, my father was a budget director for the Army’s computer programs. He had the unfortunate experience of having his funding significantly reduced when his IT team failed to properly articulate its software development goals in ways that were relatable to leaders. As a superior put it, “Whenever I talk to the IT guys, I hear about bits and bytes, programming languages, and bandwidth, but nothing that relates to time, effort, and cost.”

That comment sent my dad on a mission to develop a software estimation frameworkthat addressed the three points that his boss was most concerned about. He sought to expose what he called “a fundamental law of nature in our software production equation.”

Why do so many companies fail at software development projects? More often than not, they haven’t built a foundation of process, people and tools to accurately plan and estimate. An Estimation Center of Excellence is a great starting point to bring these components together and maximize their benefits. In this article for Projects at Work, Larry Putnam, Jr. describes how all of these components work together to help organizations achieve software project success.

Read the 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.

It may seem absurd to think about working an 18-hour day, but it happens all the time in the software development community. If managers don’t accurately estimate project schedules based on a clearly defined scope of work, managers and their development teams may find themselves working long days to deliver on promised deadlines and deliverables.

Being overworked in an environment where a project is running over schedule can also lead to the delivery of a defective or flawed product, which is bad for both the development organization and the business unit for which the product is being developed. One article that I read recently states that time pressures cause employees to cut corners and that the 18-hour workday does not allow for forward or creative thinking. This can be disastrous to an organization that values both the quality of work and the out-of-the-box thinking of its development team.

Recently a friend of mine sent me a link to a YouTube video featuring Jeff Sutherland and Ken Schwaber, the founders of Scrum, discussing the latest update to the 2016 Scrum Guide.  The updates to the guide were comprised of survey feedback from the Scrum community, with the goal to understand what is important to them that should be included in the updated Scrum guide.  

The most compelling part of this discussion for anyone contemplating whether estimating belongs in Scrum happens at the 32:10 point.  Jeff and Ken are posed the question, “what is the difference between a forecast and an estimate?”   They answer with the idea that many people confuse the word estimate with commitment, which plagues any development effort regardless of method.  Subsequently Jeff and Ken changed the word “estimate” to “forecast” in the latest Scrum Guide to reflect the ever-changing growth and reduction in project scope, i.e., the estimate will show our best commitment and what we think is going to happen.  That can change once the project starts, BUT, we can measure that too through forecasting, essentially re-estimating throughout the project.  

There are so many questions around agile planning, one of the biggest being: do we need an estimate? Project managers and scrum masters will spend months developing a system either for internal use or for their clients, yet some of them say that estimates are not needed. Some recommend starting the project without an estimate. They say they will see how the first few weeks go before they generate an estimate. Others say not to worry about an estimate at all; they are a waste of time.

The problem with those recommendations is that there are business decisions that need to be made regarding whether or not to even start the project. Reliable estimates for cost and duration are needed to make these decisions. Also, for the projects that do move forward, there is usually limited information available early in the lifecycle, not enough to provide a detailed plan. Product owners need to see the big picture before a reliable detailed plan is generated.

There is also the IT manager that needs to figure out how they will allocate their resources. There is the vendor manager that needs to evaluate multiple bids for a large software system that could cost the company millions of dollars. There is the proposal manager that needs to write a proposal that must be cost competitive to win business. And, there is an annual budget at stake and the CIO needs to know how much money their development organization is going to spend over the next 12 months. You can’t support these decisions in the best way possible without reliable release level estimates.

No one said IT budgeting was easy. It seems like you just finished last year’s budget and now it is time to start all over again. Not only is this task difficult, it is made worse by the fact that most organizations do it in an overly simplistic way. This often results in up to 40% of the projects grossly missing the mark, which wreaks havoc on the enterprise resource plans and results in disappointed business stakeholders.

A large part of successful IT budget planning is identifying grossly unrealistic projects – the ones that are likely to fail and the ones that are ultra conservative and wasteful. Our solution is to perform a basic feasibility assessment on each project as it enters the budgeting process. Ultimately, we will want to make adjustments to these projects, making them more reasonable and improving the overall project performance.

So how is this feasibility assessment done? Start by creating a set of historical trend lines for schedule, effort, and staffing versus size of functionality produced. The trend lines provide a basis for the average capability that could be expected. It also gives us a measure of the typical variability that can be expected. Next, position the initial budget requests against the trend lines. The intention is to identify whether or not the projects are outside of the norm and typical variation; i.e., projects that are high risk or poor value. Figures 1 through 3 highlight some of the techniques used to identify those types of projects.