5 June 2007
5 Ingredients for the Application Development ROI Soup
Fact: The way most of us in the industry calculate Return on Investment (ROI) for software application development is broken.
As we continue to work with our partners, competitors, and clients, I am continually stunned by how companies quantify the business value gained from application development and integration work they perform. Typically, its an after-the-fact analysis on profitability/revenue derived from a Line of Business and its applications. On the surface and at the gross level, this makes sense.
However, in our opinion, there is a more fine-grained and informed method for making decisions around what to build.
No organization is perfect — that’s for sure; including us [&& See below]. That being said, we are of the opinion that there is a better way for companies to decide where to spend their application development budgets in close partnership with IT. In many places this negotiation and collaboration between IT and business has been unnecessarily adversarial and characterized by mistrust born from past disappointments from both sides. Business sins include: Feature creep, ill-formed requirements, un-responsive stakeholders, constantly shifting priorities. IT sins include: cost overruns, 80 hour work-weeks, stop-start work efforts, no sense of accomplishment or finality. And its not just the project sponsor and development teams that deal with the fallout. Whether companies “fly the flag” and live by the agile manifesto or are more traditional in their processes, CSR teams, marketing teams, and other operational groups operating in fits-and-starts to support a technology deployment that is ‘a few weeks away’ are still common in the landscape.
This does not have to continue to be the case. There are no silver bullets for the werewolf because, frankly, that’s why consulting companies like ours exist. However, we do think there is a key to making this process more collaborative, informed, fast, and ultimately valuable to the business. Agile Methodology [INSERT APPROACH OF THE DAY] aside, companies still have to decide on what they want to spend time and money. And, the faster that business and IT can enter conversations about the cost and projected return of features that are going to be built the better. Okay, this sounds great, but how does one implement it?
Here is one recipe:
- Ingredient 1: Get high-level requirements quickly and efficiently — for the vast majority of application development efforts, you can and should be able get to a body of requirements that can be used for budgeting and ROI purposes in a few hours … Yes, really — in a handful of meetings and, ultimately, a few hours.
- Ingredient 2: Use a flexible and repeatable framework for estimation that allows you to model ‘what-if’ scenarios in collaboration with business stakeholders quickly and effectively. Moreover, use a framework that allows you to do this on a feature-by-feature basis. In our experience, this is crucial. Why? because Line of Business owners think about the work in terms of trade-offs and options that allow them to drive more money to the top and bottom line. Do these sound familiar: What if I add more people? I don’t really need that feature, what if we remove it? What if the team works 50 hours a week? What if I make that feature less complex?
[&& We were/are/will not be perfect. That's one of the reasons we developed a tool, Planix, to make Ingredient 2 easier to accomplish. This is a shameless self-promotion and yes, there is a free version]
- Ingredient 3: Encourage the business to provide the expected “X” — revenue, profit, widgets, karma points, clams, etc. — that is expected to be generated by the features estimated in (2). Encouragement is key, but at some point, the executives, IT, and the business must insist that projected X be rationalized and estimated in order to justify a capital budget to build the next shiny new application.
- Ingredient 4: Divide Ingredient 3 by Ingredient 2 to determine what your return is going to be from this application/IT investment
- Ingredient 5: Discuss, negotiate, repeat Ingredients 1 through 4 until you have a set of features that business and IT believe are important
Sounds like a lot doesn’t it? It can be a lot in terms of calendar time without the right sponsorship; that is for sure. For our part, we’ve seen the process take 3 months for a 2000 hour, 3 person, 50 feature effort. We’ve also seen it take 5 days for a 21,000 hour, 10-person, 600 feature effort and everything in between.
The important thing, in our opinion, is changing the dialogue … instead of only answering the question “what were the costs to build my application and what did my Line of Business bring in,”we should be collaborating on the question “what features bring the most business value; what will it cost me to gain this value?”
Technorati Tags: estimation, budgeting, ROI, project management, user stories, use cases, agile, ROI
Comments are locked.
WorkForceInABox.com » Blog Archive » ROI of Application Development says:
ALTERthought Blogs » Blasphemy: The Case Against Ruby on Rails says:
[...] Yes, [they’re] the great pretenders …The unfortunate reality of the RoR movement and market is that there are a number of below average soloists passing themselves off as solid developers due to the level of demand. This has consequently led to both able and mediocre sole practitioners and confederations of practitioners trying to fulfill the demand. We’ve seen a number of companies and entrepreneurs write, re-write, and re-re-write Rails applications primarily due to sub-standard code quality. Without real-world experience with Rails, companies and entrepreneurs are having an exceedingly difficult time vetting “single shingle” coders. Even though they are writing this software in a “highly desirable” framework, they’re commanding between $100 – $175/hour to write throw-away software due to their lack of sophistication and, ultimately, accountability. [Note: you should be paying for features and ROI not for hours] [...]
Groovy on Grails » Blog Archive » The Case Against Ruby on Rails (AlterThought) says:
[...] Yes, [they’re] the great pretenders …The unfortunate reality of the RoR movement and market is that there are a number of below average soloists passing themselves off as solid developers due to the level of demand. This has consequently led to both able and mediocre sole practitioners and confederations of practitioners trying to fulfill the demand. We’ve seen a number of companies and entrepreneurs write, re-write, and re-re-write Rails applications primarily due to sub-standard code quality. Without real-world experience with Rails, companies and entrepreneurs are having an exceedingly difficult time vetting “single shingle” coders. Even though they are writing this software in a “highly desirable” framework, they’re commanding between $100 – $175/hour to write throw-away software due to their lack of sophistication and, ultimately, accountability. [Note: you should be paying for features and ROI not for hours] [...]
phentermine buy carisoprodol says:
chats phentermine buy to phentermine buy
GSIY … Ruby-Rails Portal says:
[...] Yes, [they’re] the great pretenders …The unfortunate reality of the RoR movement and market is that there are a number of below average soloists passing themselves off as solid developers due to the level of demand. This has consequently led to both able and mediocre sole practitioners and confederations of practitioners trying to fulfill the demand. We’ve seen a number of companies and entrepreneurs write, re-write, and re-re-write Rails applications primarily due to sub-standard code quality. Without real-world experience with Rails, companies and entrepreneurs are having an exceedingly difficult time vetting “single shingle” coders. Even though they are writing this software in a “highly desirable” framework, they’re commanding between $100 – $175/hour to write throw-away software due to their lack of sophistication and, ultimately, accountability. [Note: you should be paying for features and ROI not for hours] [...]
[...] Just read an interesting piece from Sunjay Pandey arguing that ROI measurement for application development is too soft. [...]