Making the Business Case for Technology, II: Demonstrating Value After the Fact
April 15, 2009 2 Comments
I was a member of a team of people within our work organization in reviewing and presenting different chapters in the book titled In Search of Business Value: Ensuring a Return on Your Technology Investment.
Although it required a moderate amount of my personal time, I found being a team member in this project to be very beneficial to me. I had the opportunity to read the book and summarize and present a review of Chapter 5 of the book, titled “Making the Business Case for Technology, II: Demonstrating Value After the Fact”. The summary was presented to members of our global IT team, including developers, systems analysts, business analysts, IT managers, and IT directors. One of the authors, Robert McDowell (VP of Microsoft Corporation) joined us on the conference call as well.
I found tremendous value in the ideas presented in the book, but the most value was gained in the practice of writing down key points, reviewing, sharing, and discussing these ideas on a global conference call with other reviewers of different chapters.
In this blog posting, I am sharing a modified summary and review that I came up with and presented back in December 2008.
The whole chapter deals with responsibility, ownership, and accountability. Routine follow-up audits in IT projects are critical for determining whether or not the projected results were achieved. Most companies do not do this, but the consensus is that it needs to be done. Unless we become responsible for conducting follow up audits, we cannot criticize whether or not an IT project has paid off. We need a way to determine if the productivity gains promised in the business case were actually achieved, and at the start of the project it needs to be identified who will be held accountable for achieving the projected results.
Benefits to the Organization
It will be a big undertaking to implement the ideas presented in this chapter, but as a start I believe there are some things that we could put in place in the short term to ease a transition into it:
· The project champion should be from the business unit and we also need to ensure that we assign someone in the business unit to be accountable for the project
· Usage logging can be used to verify or track that an application is being used as frequently as expected. Ex) A report that was given high priority development status and passed all of the user testing and acceptance approvals could be audited simply by looking at the report usage log to determine if the report is being used or being used as frequently as per the projected usage.
o This information could be used a lesson learned in considering future high priority projects
· User surveys could be put in place to provide information about IT projects. The questions on the survey can be geared to show how effective the project has been and indicate any actual user cost or time savings. This could easily be set up using SharePoint.
· A simple analysis can be completed at the beginning of IT projects to be used as a gate to determine the projected benefits vs development/implementation time
To fully receive the benefits of the ideas realized in this chapter will require a long term strategy and strong commitment. Here are some ideas that could be used over the long term:
· An analysis must be done to actually document the projected benefits of implementing the ideas presented in the chapter
· Forms and standardization procedures could be developed and standardized for all IT projects to document projected vs actual benefits. We could use this as a pilot in some projects and revise and complete lessons learned documentation as necessary
· Awareness, trust, and understanding of the value in this process would need to be created with IT and the individual business units at each division to truly be effective in this process
Key Points in the Chapter
· Two major core issues:
o Ensuring that an analysis is performed after the fact to determine whether the benefits promised had actually been achieved
§ This needs to be a routine practice from the largest companies to the smallest companies with only one IT person.
§ Every project with an expected business value requires the following:
· Name the business person who is accountable – this must be the business owner who will take accountability
· Most companies give a considerable amount of time on the up-front analysis of technology projects, but give little attention to any sort of after the fact evaluation
o They don’t verify if their goals were met
o Most companies are not where they want to be in this regard
· If there is a standardized process to evaluate success or failure of initiatives, a better job can be done at post-project assessments (p80)
· It is important to do a routine and vigorous after the fact cost/benefit analysis on every major technology project
o It needs to be determined if the project really paid for itself?
· We must step up to the responsibility of conducting follow up audits as a standard practice (p. 94)
· Put a formal process in place to determine which benefit was actually realized from technology projects (p. 94)
· If an audit shows a productivity gain you must go to the next step and determine what is now being done with the time that has been freed up (p. 94)
· At each milestone, measure if we have achieved the projected benefit at this time (this benefit must be something that is measurable)
o This is like a gate in the project – how well are we doing relative to the timeline of the project and how well are we relative to the expected value
· Look at technology spend not as a cost but as an investment
· IT cannot be the one to deliverer the business value, it must be done in conjunction with the business unit (p.84)
· Must have strong buy in which may be difficult as there are risks. One risk being it may show your project was a failure. (p.84)
· Some organizations apply very liberal assumptions while calculating business value just to have a project funded (approved).
o In these cases, the combination of liberal assumptions and no true accountability afford the company to fund projects that may ultimately never deliver the promised returns. (p.85)
· Look at what was spent on the technology/IT side to deliver the result (p.88).
o Analyze the time spent vs. returned value.
· Auditing gives a clearer view of how certain project managers’ teams have been more successful than other teams.
o Past results are an indicator of future attempts.
· Conducting user surveys can be used as a form of validating from the users if an IT solution has been effective or not.
o Example question: Do you feel more enabled with the new desktop software? (p.93)
· Even with infrastructure projects it’s just as important, even if it goes no further than comparing actual cost vs. original estimate.
· The lack of holding people accountable is the biggest source of failure and waste on technology projects (p.93)