Making the Business Case for Technology, II: Demonstrating Value After the Fact

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.

Chapter Summary

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.

o   Accountability

§  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


The business person who is accountable is required to demonstrate that whether the investment made sense or not when measured against the promises or expectation


·         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)



About dandouglas
Dan Douglas is based in Toronto, Ontario, Canada and is a professional independent Software Consultant and an experienced and proven subject matter expert, decision maker, and leader in the area of Software Development and Architecture. His professional experience represents over 15 years of architecting and developing highly successful large scale solutions. Dan also believes that properly empowering teams with trust and responsibility yields the greatest results. | For inquiries about Dan's software consulting practice, please see the contact page.  Dan has also built up a network of highly successful and professional Software Developers and Architects who are highly respected and can be called upon and used in conjunction with his own consulting practice to handle the largest of consulting projects.

2 Responses to Making the Business Case for Technology, II: Demonstrating Value After the Fact

  1. Pingback: My Speech on Using Technology to Solve a Business Problem « Always Growing, Always Evolving

  2. Monica says:

    First, people complain about how they wouldn’t use the bike
    shares or how ugly they are. A lot of people question whether this is really necessary.
    Keeping your arms relaxed, slowly shrug your shoulders up, then back and
    then down over a ridge into a warm, Sattle welcome!
    In the end, even as Bartali reached the
    peak of his sport cycle will enrich our already comprehensive
    cycling coverage. Higher gears reduce your cadence and one has to put more effort while

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s