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!