Voices » HBR Voices » Susan Cramm » New Year's Resolution: Do Experiments, Not Projects
RSS Feed
9:27 AM Tuesday December 30, 2008
Recently, I asked some business executives for their top three IT wishes. Across the board, their responses echoed a common plea: "I wish IT projects would come in on time and on budget."
Funny thing is - this very reasonable sounding request is actually quite unreasonable.
You see, we are no longer simply automating existing manual processes. We are trying to change the way people think and behave. Who really knows what's going to happen when...
Innovative applications of information technology begin with someone asking, "What if?" Innovative people and teams guess or hypothesize about how new capabilities will change behavior to the benefit of the organization.
Hypotheses are tested via experiments. While the inputs to experiments are known (in terms of the approach and resources necessary to figure out if A+B impacts Z), the outcome of experiments, by definition, is unknown, and more often than not will be along the lines of, "Back to the drawing board."
To obtain resources for IT-enabled experimentation, our inventors have to invent a business case that, in terms of outcomes, sounds deterministic not probabilistic.
Then an experiment becomes a project and, in this transformation, expectations shift to assume that there are more knowns than unknowns. The false assumption of precision - that when we do A+B, the outcome will be Z - is used to drive the project plan and functional requirements.
In the course of the project, in the quest to deliver Z, the inventor is forced to perform experiments. This frustrates IT to no end, for as the inventor goes through multiple iterations of replacing A with C and adding D, in order to get the desired outcome, the Z, scope changes and project costs and time lines escalate.
The inability to deliver against time, budget and scope is disheartening for all involved and, left unchecked, will eventually inhibit innovation. The inventors are less likely to ask the, "What if?" type questions and IT learns to pad their budgets and time lines. This makes it more likely ideas will be killed at inception, which in turn makes the IT investment board jaded about IT-enabled projects. So the board demands additional justification, thus reinforcing the negative cycle.
There is a better way. And executives who wish IT projects would come in on time and on budget should make a New Year's resolution to try it: Approach IT projects not as projects at all, but rather as experiments:
One caveat: assuming that the experiments prove out, the resulting system will be a good working prototype, but will not address enterprise needs for scalability, reliability, and integration. In order to plan for this eventually, include rebuilding costs in the business case. Doing so will give IT the incentive to use the cheapest means possible to prove out viability of a concept without being saddled with trying to make the system industrial strength during the experimentation process.
Weigh in and share your resolutions on how you get your IT-enabled initiatives to come in on time and on budget.
Stay up to date on the latest HBR articles, podcasts, blogs, and more. Sign up for the HBR Email Newsletter today.
Never miss a new post from your favorite blogger again with the HarvardBusiness.org Daily Alert email. The Alert delivers the latest blog posts from HarvardBusiness.org and HBR.org directly to your inbox every morning at 8:00 AM ET.
TrackBack URL for this entry:
http://blogs.harvardbusiness.org/cgi-bin/mt/mt-tb.cgi/3374
No trackbacks have been made to this entry.
Posting Guidelines
We hope the conversations that take place on HarvardBusiness.org will be energetic, constructive, free-wheeling, and provocative. To make sure we all stay on-topic, all posts will be reviewed by our editors and may be edited for clarity, length, and relevance.
We ask that you adhere to the following guidelines.
Susan Cramm is the founder and president of Valuedance and a recognized industry expert on information technology leadership and coaching. She is the former CFO and executive vice president at Chevy’s Mexican Restaurants. Prior to Chevy’s, Cramm worked with the Taco Bell Corporation and held the positions of CIO and vice president of the Information Technology Group and Senior Director for Financial and Strategic Planning.
ADVERTISEMENT
If you can't read a balance sheet, you'd better read this. This specially priced set gives managers mastery of the financial basics they need to plan, budget, forecast, and control resources with confidence.
This specially priced set will show you how to plan and execute a course of action that will carry you and your employees through the current economic upheaval and help everyone maximize their performance.
ADVERTISEMENT
Comments
One of the other reasons that these types of projects are unsucessful is that there is no clear definition of the actual desired outcome - the Z. Often the outcomes are loosely defined an are not documented in a way that can be effectively measured by the results of the experimentation above.
Even worse thought is the source of the desired outcome. Why is the outcome worth achieving? How has the outcome been determine? If the outcome is also a guess then, even if the overall IT project suceeds, the project may flop because the outcome was invalid from the start.
I have seen more projects run aground because of misguided outcome definition than death by scope creep, except where the scope creep is due to the poor objective definition.
--nick coster
Brainmates - product management people
- Posted by Nick Coster
December 30, 2008 4:26 PM
This is a great approach. I think a big problem with trying to use agile methods (and real options theory, etc.) is that no one wants to cancel the projects that are proving to be too expensive in comparison to their benefits. Reversing the decision, so it's a default to cancel and a decision to extend makes a lot of sense. It is difficult from the budgeting aspect, however. The projects that lock in budget for the year are going to try to grab all of the future funds and it's harder for the experiments to grab that budget back from them.
- Posted by Matt McKnight
December 31, 2008 10:46 AM
Matt - Love your "reversing the direction" observation. You are absolutely right that this process doesn't work very well when budgets are locked in for the year. Smart financial types understand that budgets earmark, rather than allocate, funds and move budgeted dollars around based on the need to reflect reality.
Happy New Year! Susan
- Posted by Susan Cramm
December 31, 2008 1:12 PM
Yeah really great article & comments!
Getting IT project that come in on-time, within budget AND produce RESULTS is hard! If you need any help i know with company do it really well http://www.beyondcomputers.co.uk. Using experiments is exactly what you suggest!
Best Regards
Lauren
- Posted by Lauren
January 6, 2009 2:20 PM
Nick is right on that many, many projects fail due to questionnable business cases and vague objectives. Try value driven development if you are interested in rectifying this issue....http://blogs.harvardbusiness.org/cramm/2008/11/valuedriven-development.html
- Posted by Susan Cramm
January 8, 2009 5:54 PM
There is a fundamental issue with calling projects with a technology component "IT Projects". That places ownership at the wrong level of ownership. All projects must get policy, process, people and tools aligned -- and in that order. Technology is a tool. All too often we start with the tool and then attempt to retrofit the rest. The retrofit aspect is a component of cost and time overruns.
I agree with the idea of "experiments". Structuring a project with appropriate check points, not only for status but further funding, is crucial. I rarely give a project full funding because it will take on a life of its own. I think of it more along the lines of venture capital.
Active business unit leadership in all projects will go a long way to address many of the items discussed.
- Posted by Jim Thie
January 14, 2009 1:22 PM
Followup on the first comment, I did publish a while ago an article on why projects fail. Unclear project objectives is the first one on the list. I do think, however, that the reasons of why projects fail is highly subjective, as I have several articles on the subject, and none have the same #1 culprit.
- Posted by PM Hut
January 14, 2009 2:10 PM
Followup on the first comment, I did publish a while ago an article on why projects fail. Unclear project objectives is the first one on the list. I do think, however, that the reasons of why projects fail is highly subjective, as I have several articles on the subject, and none have the same #1 culprit.
- Posted by PM Hut
January 14, 2009 2:11 PM
I agree with Matt that the implications surrounding the budget process make the experiment approach more complex.
As someone who has worked on both the business side and the IT side I fully agree that incomplete or vague understanding or presentation by the business of the actual need is a significant contributor to project failure.
However I am of the firm belief that the primary reason most IT projects fail is insufficient commitment by the requirer, and usually their implicit assumption that once the decision to start a project has been made, they can move on to their next issue and the project will continue without their involvement.
In terms of presenting the experiment idea, its an unfortunate perception by the business that IT already doesn't have enough business sense to meet their needs, and using a term like experiment might reinforce this perception.
- Posted by Greg Mills
January 15, 2009 8:06 AM