I have found that a major key to successfully and effectively estimating software projects is to make sure that expectations are properly set. And what should those expectations be? Depending upon where and when in the lifecycle you estimate and how much information you have available to you at the time of the estimate, it is more likely that an estimate is going to provide you with a ballpark figure. However, the expectation is often that the resulting estimate is pure and represents what is actually going to occur. It becomes the yard stick from which performance, schedules and costs are measured. 

In previous blogs I have talked about viewing an estimate as data to be used in managing the risks associated with a project, or, providing a range of values when producing an estimate so as to not give the sense that there is one absolute value – at least not until the end of the project. Here I want to make the point that part of your overall estimating strategy should be to properly set expectations up front.

Setting expectations means that there is a discussion before the estimate is even calculated. What is management looking for in regard to the resulting estimate? What are they going to do with the information that comes with the estimate? How accurate do they think the estimate is going to be given the current availability of input data? These are some of the questions that should be asked and discussed prior to estimating.

When we are asked to provide an estimate for a client, even before we send them a proposal we have this dialogue. There is no point (at least for us) to go through the effort of producing an estimated value only to have the client misuse or even worse, abuse, the information. No one wins.

Be sure to sign up for Estimation Experiences Exchange group on LinkedIn.

What typically happens in most software project estimating endeavors? It plays out something like this – a project manager is given a high level requirement and is asked to produce a level of effort, cost and schedule estimate based on the best information available. Everyone agrees that there is not much information available, but everyone is assured that the estimate given will not be cast in stone. The PM then goes about the business of producing an estimate. And let’s assume here that the estimating process in this case is pretty good. So the estimate is developed and provided to the requesting party and the development lifecycle continues on. Oh, and by the way, the initial estimate has now been cast in stone. (I am sure you saw that coming).

For the sake of argument we had assumed that in the above scenario the estimating procedures were mature and typically produced good results if there were no significant changes to scope, resources, priorities, etc. However, how many times are projects executed without changes in scope, resources, priorities, etc.? And when change occurs a new estimate is requested – hopefully, but not always! Often, original estimates become immovable objects (or barriers) and the project team has to figure out how to manage to original schedules and costs.   

I think at this point the conversation changes from one of estimating to one of risk management. Senior management does not want to hear that new estimates have to be generated that will now most likely show an increase in costs along with schedule delays. And besides, anyone can argue the validity of an estimate. However, senior management is typically in tune with the notion of risk identification and mitigation. Rather then continuing to present estimates that result in debates as to their validity, why not use the estimate as a tool to have a conversation about project risks.

As projects pass through the development lifecycle changes occur. And as changes creep in new risks are introduced. These risks need to be identified and responded to. Rather than debate whether the project is going to take two more weeks or two more months, the fact is that the original schedule is at risk. It’s really the same issue only the conversation is different. You are not defending your estimates you are communicating to management that there are risks to be managed.

Be sure to sign up for Estimation Experiences Exchange group on LinkedIn.

I thought it appropriate to write a few short blogs regarding the basics of software project estimation. This is the first one (hence the #1). These narratives are the result of observations and lessons learned from recent client engagements. The names have been changed, of course, to protect the guilty. It should be further noted that the usual client profile that forms the basis of these musings is that of an IT shop within some sort of commercial line of business.

The One Number Experience

We all know that there is no perfect answer; however, there does seem to be an expectation that an estimate should reveal not only the right answer, but an answer whose result is expressed as a single value.

The typical estimating model assesses a series of variables that define the project. These can range from skill levels, to practices to environment to technology and so on. Within each of these elements there are certain degrees of variability, naturally. And so depending on a few key variables the estimating model will produce a projected range of probable values.

It is common place for the estimator to then take one of these estimates – perhaps the one with the highest probability or the one that politically sounds the best (which is usually the one with the lowest probability) – and then present it to the customer or end user. The problem with this approach is that when we provide only a single value it gives the impression that it is the ‘right’ answer.

The solution (and strong recommendation) is to provide the customer or end user with a select range of probable values. This in turn will most likely result in a discussion of the resulting ranges and therefore a deeper understanding of estimate and the inherent risks of this particular project.

Be sure to sign up for Estimation Experiences Exchange group on LinkedIn.

A recent CIO magazine article, CFO + CIO = ROI, D’Auria, 6/09, focused on the fact that IT budgets will continue to be carefully scrutinized as the recession rolls on. The article discussed how the CIO and CFO need to work together to stay strategically on target while managing financial performance. CFO’s and CIO’s offered such advice as shortening payback time on IT projects and focusing on ROI. Certainly good advice.

While reading this article, it struck me how important it was to have an effective process for accurately estimating project costs and schedules. Now more than ever, we need to manage projects to arrive on time and within budget. Additionally, we need to be able to accurately evaluate the cost (and benefit) of future projects.

Perhaps now is the time to learn a lesson from the government and consider using third party cost experts to evaluate and estimate those mission critical projects. Why not mitigate the risk of cost overruns and missed deadlines by having a cost expert provide a qualified ‘second opinion’.

We’ve all heard the expression, “less is more”. Certainly our experience with the myriad of products IT organizations have purchased, all with good intentions, only to end up as shelfware should speak to the need to heed the advice inherent in the ‘less is more’ phrase.

To make the point, allow me to present the following example. The problem or challenge that we are addressing is an organization’s need for a practical approach in establishing a project portfolio management and IT governance process. The company in question knows they need these project management capabilities and governance practices but they can not afford the time or money to purchase a tool, install the tool, train on the complexities of the tool and develop the procedures to ensure the effective utilization of the tool. Never mind the cost with keeping up on the maintenance of the tool.

It should be noted that we are talking about a small to mid-size company that has a modest sized IT organization.

Our suggested solution, in the ‘less is more’ mindset, is a Software as a Service solution that can provide the basic project portfolio management features and functions. One such tool is PieMatrix (www.PieMatrix.com).

PieMatrix provides a very basic and necessary feature set for the IT development manager. It is an easy to use project portfolio management tool. Setting up a project with definitions, resources and timelines couldn’t be easier. The technology is in the Software as a Service framework so there are no installation and maintenance issues. And because it is economical to use, it makes it a very favorable choice for the small to mid-size IT shops.

Yes, that’s the memorable quote from the movie A Few Good Men, but I wonder if it doesn’t apply to some senior IT managers as well. It is a constant source of amazement to me how often I find organizations unwilling to collect even the basic level data that they need to make more informed decisions. I am thinking specifically about performance measures that would demonstrate to an IT organization their level of performance relative to productivity (cost), defect removal efficiency (quality), and delivery time (performance).

How is it possible to make key decisions without some data points relative to the performance of the organization? For example, an organization may embark upon a software process improvement initiative (e.g., CMMI) requiring an investment of thousands of dollars in resources. Without the proper data points along the way, how does the senior manager know what the return is on that investment. How do they make the decision to continue the program or where the program many need certain tweaks and fine tuning.

Are they assuming that all is well? Do they not want the information for fear of what they may learn? Can they not handle the truth!? It’s hard to say. One thing for certain though is that they don’t have all the information they need to properly make the decisions they will invariably be making.

How many times has your company purchased a software product only to find it becoming ‘shelf-ware’ before anyone really has had a chance to understand and actually use the product? I think we have all experienced this somewhere in our past. Sometimes it is the result of the wrong software at the wrong time in the wrong place. Sometimes it is the right decision but the skill levels or the commitment levels are just not strong enough to manage the successful deployment of the software solution.

As equally counter-productive is developing a set of well documented procedures that will improve the overall maturity of selected development practices only to have the execution of the newly created procedures fall by the way side. This scenario is usually accompanied by someone making the comment that if the manual procedures had been an automated solution and not a manual one it would have gotten more attention and acceptance. You can’t win!

This is a case where two halves clearly make a whole; a whole solution. An automated software solution and a documented procedure are each one-half of a solution but when combined present the whole of what is really needed. The ideal really is to have both automation and a well defined process. Automation has a certain amount of aesthetic charm in addition to being more efficient (faster results) and effective (accuracy, consistency) in most cases. But few automated solutions prosper without the added support of a well defined process or methodology that incorporates the use of the software tool into a best practice procedure that ensures proper skills training, planned implementation, follow-through, proliferation and measures of success.

I have to admit, that I am not much of a social networking kind of guy. Yes, I have teenagers who spend an inordinate amount of time on Facebook and searching YouTube for the latest videos and God knows what else. They text and twitter their friends continuously and I am convinced that they have forgotten about all other means of communication. So I certainly see that social networking has become ingrained in the fabric of our society, at least around my house.

As I travel about the country talking with various CIO’s I’ve come to realize this is a hot topic in the business world as well. When I ask CIO’s what they are considering for the future, it seems as though social networking is always on their list. They don’t know how, when or even why necessarily, but they know that it is something they need to be thinking about.

In order to keep pace with the times I have made an effort to occasionally read some of the many articles on the subject of social networking, particularly as it applies to the business world. I found one such interesting article in the March 23^rd edition of Information Week. The author, Andrew Conry-Murray, had an interesting article titled – Can Social Networking Pay Off. What caught my attention were his five best practices of social networking in business.

In summary, Mr. Conry-Murray suggested the following –

1.  Test the Waters – typically, in the absence of any company-provided tools, employees will take it upon themselves to integrate social networking into their lives. Companies may find it useful to set up a low-cost pilot with open source tools. That way they can guide, direct and monitor some of the social networking activities.

2.  Set Modest Expectations – don’t over state the benefits of social networking. Set reasonable goals for adoption, and engage a few teams eager to use theses kinds of tools. Be sure to consider ways to measure the business value since sooner or later corporate management will want to know the payback of future investments in these tools

3.   Don’t Let Fear Strangle Growth – Many organizations are concerned with giving the employees a voice and fear what they may say. That may tempt companies to police employee-generated content. Resist that temptation and let the employees grow comfortable with speaking up and sharing ideas.

4.   Resist Exclusively – Teams may want to build gated communities but that approach defeats the purpose of social networking. Push back on such requests and in time people will come to see the value of exposing discussions to the broader community.

5.   Don’t Forget About the Search – A good search capability is critical to making social applications useful. Be sure the search engine allows for user-generated feeback such as tags and content-rating systems.

When did estimating become an exercise in producing results with the expectation that they would be pin-point accurate? There are very few services that I can think of in my personal life where I would expect an estimate to be any more than just that – an estimate, an approximate calculation. When I take my car in for repair or when a service man initially looks at my broken hot water heater, I get an estimate and my understanding is that this figure is in the ballpark of what I should expect to pay; with the exception of any unforeseen circumstances. I don’t write them a check then and there because I know the actual amount is going vary from the estimated amount. Why should our expectations be any different when estimating a software deliverable?

How many times have we heard stories and/or personally experienced a scenario whereby IT takes all the heat for a project that was late and over budget. Typically the measure for a project being late or over budget is based on comparison of actuals to plans (estimated of course). So if the estimate is not ‘accurate’ then there is a penalty to pay; most often by IT. I realize that there are many extenuating circumstances in such a scenario; however, if we assume that the IT department took the task of estimating seriously and applied the skill and rigor necessary to produce their best estimate then where do we lay the blame? Is it on the user for changing scope mid-way through? Possibly, but not likely since we can always do another estimate. Is it some unforeseen circumstance either business related or technology related? It’s a possibility. Regardless of the situation, my experience tells me that the heart of the matter is that our customers (users) do not have their expectations properly aligned with what an estimate actually represents. Therefore, I believe it is the responsibility of  IT senior management to ensure that the business partners understand the estimating process and understand what an estimate represents. An estimate is to provide an approximation based upon best information available at that time.

What will you read about in these blogs, besides interesting thoughts, observations and shared experiences relating to IT decision making at the project, process and enterprise level?

Since I am not really sure how to answer that just yet, I guess you will just have to stay tuned to find out. What I can tell you is that these blogs will include discussions on how folks are using Software as a Service technology to manage and monitor their process improvement initiatives. There will be blogs covering the age-old  problems that IT commonly has with estimating the delivery of software. And for sure, we will be talking about what data is needed by management to make more informed decisions and how is that data best displayed and reported.

I hope this will be a two way street and that I will be hearing from you with comments and some of your own observations and experiences. Stay tuned!