Gartner Symposium/ITxpo 2016
16 - 20 October 2016 | Orlando, FL
gartner.com/us/symposium

Thinking about attending the upcoming Gartner Symposium/ITxpo 2016, October 16 – 20, in Orlando, FL? As a sponsor, we’d like to invite you to see a demonstration of our SLIM Suite project estimation and business analytics solution at the Solution Showcase. Stop by QSM booth #1056 and enter our drawing to win a free “Quick-look IT Budgeting Maturity Assessment” - a $5000 value. 

All CIOs and IT leaders have unique goals and challenges around two key areas: aligning to their CEOs' business priorities and advancing their careers, digital roadmaps and organizational influence. Gartner Symposium/ITxpo helps you address both, with a flexible, accessible agenda mapped to your top priorities and anchored in three key areas: Technology and Information, Leadership and Business Strategy. From future trends to surprising revelations about what global CIOs really think, you'll hear it first at Gartner Symposium/ITxpo - directly from the experts who devote their careers to exploring what's over the horizon. 

Register now with priority code SPSYM189 and save $550 off the standard registration rate.

IT project budgeting is a necessary evil in every organization, but it’s becoming increasingly apparent that traditional approaches aren’t incredibly effective. It is possible to make this challenging task better by breaking with tradition and thinking about budgeting differently. Today, most organizations approach budgeting in an overly simplistic manner: a manager makes a call for project estimates and receives responses based on expert opinions, task-based spreadsheets, anticipated budget restrictions, available resources, and – let’s face it – wild guesses. Most often, the estimates are nothing more than a collection of hours, with no differentiation by job role or schedule. This inefficient process can result in 40 percent of projects missing their marks, simply because they weren’t budgeted accurately. Let’s take the guesswork out of the equation. In this article for Bright Hub Project Management, QSM's Doug Putnam provides a few simple steps to ensure that your projects remain on point – and on budget.

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.

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.  

Developing early software project estimates is an industry best practice, but creating those estimates is only half the battle when it comes to improving productivity. By continually keeping the pulse of a project—measuring performance against estimates and adjusting when necessary—teams can gain valuable insight into their software development processes. This insight can be leveraged in future development cycles, leading to more efficient production and a better bottom line. Estimates are just the beginning. In this article for Project Times, Larry Putnam, Jr. explains how project tracking, reforecasting, and post project review are three valuable strategies teams can employ to monitor the development process and improve outcomes.

Read the article!

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.

The ways that enterprises handle software development have changed immensely over the past couple of years. But as many organizations are upending traditional business cultures as they strive for greater collaboration, some core principles remain the same. Business stakeholder requirements need to be delivered within a reasonable timeframe and budget, with a good user experience and solid return on investment. By implementing an Estimation Center of Excellence, organizations can ensure that their projects remain on track, even (or perhaps especially) in highly agile environments. In this article originally published in SD Times, Doug Putnam outlines best practices for establishing an Estimation Center of Excellence.

Read the full article!

Before an agile project starts, many product owners will run an early release estimate. Once the activities get started, managers or scrum masters begin to track the progress. When they track, they usually include the person hours of effort and the number of user stories within each sprint.  There are a number of agile tracking tools and methods in the marketplace for these tasks. 

But wouldn’t it be great if the tracking and estimation process could be combined, using the actual tracked effort and user stories to run new and improved ongoing estimates at the release level? At QSM, we have applied this process to hundreds of software projects. This type of adaptive forecasting can help save time and effort by showing when a software release is headed down the wrong path. It can also help organizations avoid signing up to inflated resource planning numbers that cause many companies to waste millions of dollars at the release and enterprise levels.

In the SLIM-Control charts below, we see the blue plans versus the red actuals and the new forecasts in white. We are capturing the total effort spent and the actual work delivered each week, then using that information to generate mathematical models that produce new empirically based forecasts at the release level.

Agile is about adapting to change, not completely abandoning documentation or dismissing helpful planning and estimating inputs. In this article for Projects at Work, QSM's Jay Daniel explains how the benefits of an agile approach can shine brighter when used in conjunction with a fundamental development practice such as sizing.

Jay Daniel is a Professional Services Manager with QSM's Consulting Services team. He is an IT professional that has served in a variety of consulting roles, ranging from Program and Project Management to providing Independent Verification & Validation (IV&V) support to clients. For the past five years, Jay has focused his attention on agile methodologies in the implementation of software development efforts. He is a certified project manager (PMP), scrum master (CSM), and product owner (CSPO).

Read the full article!