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!

Recently the correlation between seeking the best gasoline prices and software project overspending collided for me.  On one hand, IT projects will easily outspend their budgets, and on the other hand, in our private lives, we are doing all we can to save pennies in our personal budgets.

From time to time I have found myself pondering whether to drive the extra 5 miles out of my way in order to beat the system and enjoy the best gasoline price in my area.  I don’t believe I am alone in this quest as evidenced by the websites that publish the lowest gas prices within a certain radius.  Typically the competing stations have very small differences between their prices.  If I play my cards right, I may be able to save a total of $.50 - $.75 for a fill up.  In almost all other walks of life $.75 is not even worth a second thought.

The story of QSM and software application estimation begins during my time in the Army. I was assigned to Sandia Base, NM to research methods for protecting soldiers from the effects of nuclear explosions.  I had to do several calculations to determine the impact of an explosion (blast calculations) on soldiers using a slide rule, which was very tedious.  Sandia National Laboratory was next door to my office, and they had just gotten the biggest and best engineering computer available at the time.  They offered computer time for anyone needing it and even offered to teach me programming, so I decided to take a course in FORTRAN programming over my lunch hour so I could do my blast calculations quicker. These lessons aided me in completing my work at Sandia and followed me to my future assignment at the Pentagon. 

For my tour at the Pentagon in the 1970s, there was not a lot of need for my nuclear experience so I was assigned to the Army’s computer program. We had to defend our program budget to the Department of Defense (DoD) budget review authority (OSD). One system, SIDPERS, the Army enterprise personnel system, had been in development for five years and after having a peak staff of 110, we were projecting 93 people for the next five years. The analyst looking at the budget asked what should have been a simple question, “What are these people going to do?” I did not have a good answer, and later, going back to the project team, neither did they. Because of this we lost $10M in our budget.

The time has come, once again for QSM’s annual March Madness tournament.  As we enter our 6^th year of friendly office competition, I looked back at some of my previous strategies to help me figure out how I wanted to go about completing my bracket this year.  In doing this, I realized that many of these concepts can be applied towards IT project management.

Three years ago, I built my bracket around an emotional desire for my preferred team to win.  I paid very little attention to their previous performance that season, or any of the other teams for that matter.  Needless to say, I did not do as well as I had hoped that year.  Unfortunately, this strategy is applied fairly frequently in software estimation, with stakeholders committing their teams to unreasonable schedules and budgets for projects that are “too big to fail.”  Committing to a plan based off of the desired outcome does not produce a good estimate, and often results in cost overruns and schedule delays (or in my case, quite a bit of ridicule from the Commish).

I recently came across this blog post by David Gordon and I believe it nicely summarizes the problem many C-level executives find with the #NoEstimates agile view. At the end of the day, they need realistic numbers in order for their organizations to make a profit and remain competitive in their markets. It's simply not enough to start development without some sort of upfront plan as to how much the overall project will cost. Gordon gives a nice analogy:

Now, picture a carpenter who has been asked to bid on framing a group of houses. He replies that he can’t tell how long it will take, because his crew hasn’t built that model before. But if the home builder gives them, say, $400,000, they will work diligently, and when the money runs out, they can decide together whether to put more money into the construction. You’re probably thinking that the builder won’t ever do business with that carpenter, and neither will anyone else in town. But that’s because the carpenter isn’t an employee—he has competition. This helps explain why certain software developers think #NoEstimates is a fine idea—they don’t perceive that they have competition.

Unfortunately for developers, this is not a sustainable way of operating - as many organizations continue to outsource more and more positions, developers will need to be able to justify their work as a business case. Gordon argues it's worthwhile for developers to learn software estimating best practices and to "...take some time away from learning the newest cool development tool to become viable as a contingent worker." I have to say that I agree.

In software estimation, some discovered relationships turn out to be true primary principals of software development.

Way back in 1978, Larry Putnam, Sr. discovered that the relationship between project duration and project effort was exponential.¹  His equation equated to:

Duration in months = 2.15 times the cube root of effort in manmonths

In his 1981 book, Barry Boehm described the nominal relationship in COCOMO² as:

Duration in months = 2.5 times the cube root of effort in manmonths

Very similar results.  Is that something specific to the way projects were managed way back then?  Or, is this a true fundamental law of software project management?

Sometimes, it is fun and also informative to revisit pioneering work to see how things have (or have not!) changed over the decades since.  I have used updated benchmarking data to check this staffing relationship and found it to be surprisingly persistent. 

I took project Main Build (Design through Test) effort and Main Build duration from the QSM database, for projects that have competed in the 21^st century.

The following graph has duration in months on y axis, and effort in personmonths on x axis.

The exponential regression shows that the “nominal” duration of these projects = 2.0 x cubed root of effort.  

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.

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.

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.