Your Ad Here

Monday

A new look at extracting value


HP of late has enjoyed stunning growth under its new leader Mark Hurd. However, as with any big company, growing revenues is always a challenge. With $100 billion in sales, it is hard to keep growing at 10% every year. One of the drivers for HP's growth is its research labs. The new head, Prith Banerjee, has an interesting way to ensure that the HP labs generate value add ideas to generate growth. Basically he is narrowing the focus, getting resources allocated on high impact projects and making projects justify their value. "Value methodology" as I call this is the same justification for the business case and benefits management process. Realize the benefits by focusing on high impact areas thereby maximizing the utilization of the scare resources.

Here are some relevant excerpts from the article:

- "HP Labs today does a lot of cool things — about 150 research projects – but it does so many things that none of the projects get enough resources to have a high impact," says Banerjee. "My message was, let's try to narrow the focus."

- Banerjee's vision borrows heavily from the culture of Silicon Valley venture capital firms, which fund fresh new ideas and try to nurture them into the next Intel (INTC) or Google (GOOG). Traditionally, HP Labs scientists have had little incentive to transform concepts into products. But in the future, research efforts that fail to meet benchmarks won't get more funding, according to HP executives; instead, more resources will go to larger projects that are meeting goals and are likely to mature into profitable new businesses.

- Likewise, it will take years before investors can be sure whether HP's revamp of its labs is bearing fruit. Many of the research areas that the company identifies in 2008 won't yield products until 2013, though the new model could produce some benefits sooner. For instance, HP's personal computing group has set up a team called the Innovation Program Office that seeks to grab good ideas from inside and outside the company and turn them into products more quickly.


The full article can be found at : http://bigtech.blogs.fortune.cnn.com/2007/12/17/turning-an-idea-farm-into-a-hit-factory/?source=yahoo_quote

Tuesday

Involving IT and articulating the benefit


There was an article in the WSJ today talking about the importance of the IT department in companies and why they should be involved in the strategic decision making process. Most big companies realize the value of "IT" and how they can enable the successful operations of a company. Whether they are leveraging this is another matter. I think how effectively "IT" is involved is the key differentiating factors of successful companies. It is also just as important for IT to keep showing how they can benefit the company and one of the best ways to articulate this is via the business cases process. The business case is essentially the first contract between IT and the "business" to demonstrate the value (benefits) being achieved and how much (cost) it will take to get this. It is normally written in business terms without all the "IT" jargon so that business executives involved can easily understand, evaluate and buy in to the proposal. If they don't, it will more than likely result in the change effort not delivering value (real or perceived) even if meets schedule and cost targets.

Here are some excerpts from the article I mentioned that talk about the value of IT and the outline some of the pitfalls as seen by business executives. Sound familiar?

- According to a study by Diamond Management & Technology Consultants Inc., of Chicago, 87% of business leaders say they believe that IT is critical to their companies' strategic success. The study finds that few businesses have yet positioned IT in a way that allows it to achieve this. Only 33% of business leaders say IT is very involved in developing their company's strategy, and 30% say the business executive in charge of strategy works closely with IT, according to the Diamond study. That has an impact on performance: 76% of companies say they have had to abandon a tech project, including 29% that say they have abandoned more than 10% of these projects, according to the Diamond study.

- At Walgreen Co., the Deerfield, Ill., pharmacy chain has included its CIO on its management team since the late 1990s. That has helped Walgreen connect all its pharmacies via a single software system, which the IT department updates several times a year. The IT department depends on feedback and suggestions from pharmacists and other store employees in order to make changes. Jeffrey Rein, Walgreen's CEO, says having the CIO on his leadership team sends a message to employees that they need to make providing this feedback a priority. "If you don't involve the CIO in strategy meetings, you end up with systems that don't serve the needs of your employees or customers," says Mr. Rein.

- One reason many companies haven't worked closely with their IT departments is because IT professionals often struggle to explain what their departments do in language that business leaders understand, says Jerry Luftman, a professor at the Stevens Institute of Technology, in Hoboken, N.J. That has made it hard for non-techies to see the value that an IT department contributes to a company and creates the impression that IT leaders are too focused on bits and bytes. < This is where the business case comes in as a key channel for clearly documenting the business value to be delivered>


 
 

Thursday

Business Case Overview


From Wikipedia, here is a good definition of a business case and how it should be developed:

A business case is the concept of having a non-technical reason for a project or task. The logic of the business case is that any time resources such as money or effort are consumed, they should be in support of the business. An example could be that a software upgrade might improve system performance but the "business case" is that better performance would improve customer satisfaction.

Business cases can range from comprehensive and highly structured, as required by formal project management methodologies, to informal and brief, such as the example above. Information included in a formal business case could be the background of the project, the expected business benefits, the options considered (with reasons for rejecting or carrying forward each option), the expected costs of the project, a gap analysis and the expected risks. Consideration should also be given to the option of doing nothing including the costs and risks of inactivity. From this information, the justification for the project is derived.

At various stages in the project, the business case should be reviewed to ensure that:

- The justification is still valid,
- The project will deliver the solution to the business need.
- The result of a review may be the termination or amendment of the project. The business case may also be subject to amendment if the review concludes that the business need has abated or - changed, this will have a knock on effect on the project.

Formal Business Cases

Formal business cases are evaluated to ensure:

1. the investment has value
2. the project will be properly managed
3. the firm has the capability to deliver the benefits
4. the firm's dedicated resources are working on the highest value opportunities
5. projects with inter-dependencies are undertaken in the optimum sequence.

Objectives

The principal purposes of the formal business case process are:

- Introduce a way of thinking that causes people with the authority to recommend projects to firstly consider their value, risk and relative priority as a fundamental element of submitting the project proposal - Require those proposing a project to justify its value to the firm and to self-cull any proposals that are not of demonstrable value
- Enable management to determine if the project proposed is of value to the business and achievable compared to the relative merits of alternative proposals.
- Enable management to objectively measure the subsequent achievement of the business case's benefits.

The Business Case Process should ensure:

1. the required issues have been thoroughly considered and documented
2. sufficient information to facilitate fair evaluations of different proposals is available
3. both the value and risks inherent in the proposed project are clear
4. the project is sponsored by, and has the commitment of, an executive with the capability and authority to deliver the benefits
5. the delivery of the outcomes and benefits can be traced and measured.

The Business Case Process should be designed to be:

> adaptable - tailored to the size and risk of the proposal
> consistent - the same basic business issues are addressed by every project
> business oriented - concerned with the business capabilities and impact, rather than having a technical focus
> comprehensive - includes all factors relevant to a complete evaluation
> understandable - the contents are clearly relevant, logical and, although demanding, are simple to complete and evaluate
> measurable - all key aspects can be quantified so their achievement can be tracked and measured
> transparent - key elements can be justified directly
> accountable - accountabilities and commitments for the delivery of benefits and management of costs are clear.


Generating a business case

Generation of the Business Case should not be mechanical. Indeed, the case must demonstrate that: the issues have been thought through, the full benefits will be realised on time, any technical aspects have been thoroughly evaluated and costed, and track and measure their achievement. For any IT project it is unlikely that any significant proposal would be submitted to the Executive Management Team for approval without both the business sponsor and the head of IT agreeing on the merit of the proposal.

A business case should contain some or all of the following information types (depending on the size, timing, scale and availability of information:

> Reference - Project name/reference, Origins/background/current state
> Context - Business objectives/opportunities, Business strategic alignment (priority)
> Value Proposition - Desired business outcomes, Outcomes roadmap, Business benefits (by outcome), Quantified benefits value, Costs/ROI Financial scenarios, Risks/costs of not proceeding, Project risks (to project, benefits and business)
> Focus - Problem/solution scope, Assumptions/constraints, Options identified/evaluated, Size, scale and complexity assessment
> Deliverables - Outcomes, deliverables and benefits planned, Organizational areas impacted (internally and externally), Key stakeholders, Dependencies
> Workload - Approach, Phase/stage definitions (Project (change) activities, Technical delivery activities, Workload estimate/breakdown, Project plan and schedule, Critical path)
> Required resources - Project leadership team, Project governance team, Team resources, Funding
> Commitments (required) - Project controls, Reporting processes, Deliverables schedule, Financial budget/schedule

Monday

Instilling Business Case Discipline Into IT


Found a great Power Point presentation from Forrester while doing a search on benefits realization. I was surprised it was available for free, but happy that it was. Here is the link:

http://www.forrester.com/Events/Content/0,5180,1738,00.ppt

Some highlights are:

- When someone asks the question why do business cases, here is a good answer from the presentation title, "Business cases enable governance, bring discipline, and prove the value of IT"

-  There are a number of graphs, surveys, tables and figures to back up the value of a business case and why it is needed. With appropriate references you could use this in management presentations.

-  Provides some good ideas for the key content to include in a business case through 7 core components to include in a good business case.

-  And finally it provides the linkage between business cases and the benefit realization process in the section titled "The business case — tracking business benefit realization"

All in all a very informative presentation which can be used as a basis for generating ideas and selling the business case concept. I have added to my list of references.

Shop the world's largest on-line marketplace at Ebay or direct at Amazon.com


Thursday

Good Office (Word, Excel) Templates

If you are looking some good Word, Excel, PowerPoint Templates, then check out the following site which contains various Microsoft Office templates

Wednesday

Best Practices for Managing IT to deliver business value


Forrester Research has come up with a comprehensive list of best practices you can use today to get better results from IT that add value to the business. In an effort to help CIOs struggling to justify IT's business value to their bosses while, simultaneously, reducing waste and cost, Forrester Research analysts Phil Murphy and Andrew Bartels decided to put together a list of the best practices they, and their peer analysts at Forrester, think would offer the most help.

Here are some that I think are relevant from a benefits/value standpoint - reducing costs and/or increasing revenue:. Note - I have left the original ranking number so you can see where it rated in the Top 20 List. Below the list is a reference to the full article. You can use some of the ideas here to build your next business case.

1. Adopt ITIL and other frameworks like COBIT and ISO 17799 to bring discipline and efficiency to IT operations. Having efficient and transparent operations will significantly reduce costs (and add value) to the organization.

2. Use IT systems performance management audits and software to increase application throughput and manage costs.

4. Implement data center automation to reduce operating costs.

5. Install server virtualization to lower hardware costs and reduce administrative burden.

6. Embark on application rationalization to help IT shed duplicate applications and infrastructure.

8. Use application portfolio management (APM) tools to develop metrics to drive maintenance effort and cost reductions.

10. Undertake IT asset management initiatives to optimize usage of software and hardware.

12. Employ enterprise architecture groups to drive standardization of the software portfolio.

13. Use your vendor and contract management teams to squeeze more value from vendors.

14. Utilize contract life-cycle management tools to help optimize the savings from supplier contracts.

15. Use formalized and aggressive IT sourcing practices to cut ongoing depreciation and maintenance fees.

16. Employ eSourcing and services procurement tools help secure more competitive vendor bids.

17. Keep selective outsourcing options on the table that may lower costs and improve IT.

18. Implement IT operations scorecards to track and drives improvements and reduces cost.

19. Give IT leaders dual roles as business relationship managers and IT activity managers.

The full article can be found at : http://www.cioupdate.com/insights/article.php/3710291


Tuesday

Benefit Definition Workshops - Ideas on how to manage them,


One method I have found very useful to try and determine the benefits for a particular project is to have a Benefit/Business value workshop where you invite the relevant stakeholders to brainstorm about the potential benefits from implementing the proposed change. You will be amazed at what you can get out of these sessions. The key for these sessions as the Project Manager or Business Analyst is to provide structure and a strong agenda to keep the meeting on track and to get the information you are seeking. Also for preparation have a few ideas of your own incase of those "silent" moments.

The key things to keep in mind are:

1. It is a brainstorming session so everyone can have their opinion. You are to take notes, encourage discussion but not make judgements. When all the information is gathered you can then analyze, ., prioritize and make recommendations. Ensure you set Ground rules at the beginning of the meeting.
2. Make sure you involve the right people and the relevant people.  Avoid too many executive type people. It is the people who do the day-to-day work that have the best ideas at times.
3. People will more likely complain about what is wrong. Use this as a basis to work out the benefit. Ie, The benefit would be what would arise from fixing the problem. It will be your role to quantify this.
4. Provide some background reading prior to the meeting and have a quick recap at the beginning of the meeting.
5. Have a follow-up meeting to discuss your recommendations and to solicit feedback and get buy-in. Make sure you send out post meeting minutes/action items as well.
6. Encourage discussion and ideas but stay on the Agenda. You want to get the most of the meeting in the limited time you have.
7. Lastly, provide some refreshments for the meeting. It is amazing how some chocolate or muffins get the ideas and conversation going.


Let me know if you have any more ideas?

Thursday

Benefits Management Frameworks and the Importance of Sponsorship


Just completed putting together the benefits management framework for my current client. It has now gone to senior management for approval and endorsement. This is probably the most critical part of the entire process. Without senior management sponsorship for the framework, it will most likely fail when it comes to adoption. I have seen this happen many times and now I tell my clients, that getting management sponsorship or "buy-in" for a benefits or any governance framework should be done from the outset and should be actively managed throughout the development and implementation process.

Here are the Three key stakeholder items to keep in mind  when considering the implementation of a Benefits or Governance management framework:

1. Seek appropriate senior management sponsorship before starting the work effort. Make sure you have a strong advocate (C Level is the best) who will be able to influence others and assist in getting over the resistance you will most likely encounter when trying to implement the framework. To get sponsorship you need to also show why the framework is adding value to the organization - ie make sure the business case for implementing the framework is tight. Don't do it just because it is the "latest" trend or a competitor is doing it.

2. Make sure you have regular meetings the sponsor and department/division area champions to let them know your process. You should have executive presentations available to summarize what, why and how you plan to do things in 2-3 Power point slides. Use company specific examples or areas for improvement to make the presentation more effective.

3. Do not spend months coming up with a framework. It should take you 5 - 8 weeks to come up with a working Benefits Management Framework, depending on the size of the organization. Leverage the extensive information available on-line - this blog has a lot of good references on the right pane - and tailor it to the company needs. If you take too long, you will lose momentum and sponsorship. It is important to solicit opinions from the stakeholders or people impacted, but do not expect consensus. You want to ensure senior management and the sponsor are happy with the value the framework and it will be their role to manage middle management resistance over its adoption.

There are various other factors to consider around implementation and adoption (eg start small with a pilot), but sponsorship and stakeholder management are key. Let me know your comments.

Tuesday

Defining Benefits for Regulatory projects - Cost Avoidance

Had an interesting discussion with a colleague today - how do you define real benefits for regulatory projects - ie projects that have to be done due to external regulatory or legal reasons . These are the projects that must be done and do not reduce real costs or generate additional revenue. Normally it is very hard to determine the benefits for these types of projects because there are no obvious ones. However we did find one type of benefit - cost avoidance!

So how would you do this? Well here is a breakdown of a hypothetical example that supposes company ABC has to comply with regulation RC 12. With any regulatory/legal type of compliance there is always a potential cost of non-compliance - eg a fine or inability to do business under current operations which could result in potential lost revenue (estimated to be around x% of total monthly).

Assuming the fine or potential lost revenue can be estimated/determined, which should be as they will be stipulated by the legal folks in the compliance documents. the (hypothetical) breakdown for implementing the project would like:

- Cost to Implement
- Benefits are Avoided cost in future years from implementing this solution = Expenses from implementing the solution (ie normal costs without fines) minus Expenses from not implementing the solution (the fines or lost revenue costs)

The NPV should then be calculated based on the above cash flows (this can be done in a simple excel spreadsheet. Check out the NPV resources on the website). Remember the aim is to get to a Zero NPV for cost avoidance type of projects This is because the avoided costs are not revenue and so if they are incurred you get negative cash flows. That is why you must do 2 NPV, IRR and payback calculations - One for the do nothing scenario and one for the one in which you implement the project.

The goal is to try an minimize your costs so that your payback in terms or avoided costs is the quickest for these types of projects.

Wednesday

Benefits Management Pictorial Overview

Benefits Management is a continuous and dynamic process that requires active management and sponsorship from the sponsors to deliver the business benefits/value. The VAL IT diagram explains the benefits paradigm within the IT governance process per the diagram below. Most organizations have controls/methodology's in place for Strategy/Planning, Architecture and delivery, but little in the way of benefits management to answer the "Value Question". The key criteria described under the value question are what feed into the benefits register and process - see post on this here. I have and am using the process depicted below as a starting point for a number of my clients. It is a great picture to include in benefit management related presentations to senior management.


Source : Val IT

Monday

Who is responsible for defining the benefits?


Came across an interesting problem today - which I have encountered at other clients with whom I have worked. Who is responsible for defining the benefits as part of the business case development process? The answer would normally be the "business" or "senior management" that are funding the project and will be the beneficiaries of the benefits/business value realized.

However, as I have seen, IT normally ends up developing the business case because that is how they get money to keep doing their work. Normally during the annual planning process a high level allocation of funds is made by the senior management and finance, of which some goes to IT. If the CIO has a lot of influence, the more he/she gets. What then happens is that when the business complains or the IT people have resources available. a business case is thrown together (normally by the IT employed business analyst or project manager) and then given to a business executive to sign-off - who only cares that the dollars to be spent are within the allocated planning budget. Can you see the problems with this? No wonder the business keep complaining that the IT Project did not deliver the value they thought.

What should really be happening, and the basis for my process map, is that the business initiates the project request and owns the business case process. They can ask for IT to provide a resource to help build the business case, but the business sponsor must play a very hands on role when the business case is being developed. They should especially be involved in developing the benefits and outcomes from the project. IT should also play a pro-active role to ensure that they have the capability to deliver and support the recommended solution. Ultimately, the business case is a contract between IT and the business to deliver a solution for a certain cost to provide a return on investment. It is an important document to set the expectations of all stake holders so that they are not disappointed down the road.

Friday

Benefits and Outcomes


Here is another part of the article from  Larry Cooper talking about Benefit Realization:

First let's define the key terms in Benefits Realization:
- Outcomes: the results sought, including either intermediate outcomes in the chain, those outcomes that are necessary but not sufficient to achieve the end benefit, or ultimate outcomes, the end benefits to be harvested.
- Initiatives: actions that contribute to one or more outcomes.
- Contributions: the roles played by elements of the Results Chain, either initiatives or intermediate outcomes, in contributing to other initiatives or outcomes.
- Assumptions: hypotheses regarding conditions necessary to the realization of outcomes or initiatives, but over which the organization has little or no control. Assumptions represent risks that you may not achieve desired outcomes. Any change to an assumption during the course of the benefits realization process should force you to revise your map.
- Results Chain Technique: used to build simple yet rigorous models of the linkages among the four core elements of the benefits realization process: outcomes, initiatives, contributions and assumptions.

Benefits realization is used at the beginning of a project to determine what benefits will accrue to an organization should they choose to execute the project. As all of the potential benefits from a project do not accrue at the same time, or may do so without going through intermediate steps or outcomes, it becomes critical to understand what will be achieved at each project stage, and especially whether any benefits will accrue if a project is cancelled either partially or in its entirety.

The genesis of the benefits realization approach was due to the large number of IT projects that were getting cancelled without delivering any real value (or benefit) to the sponsoring organization. Benefits realization helps you to identify the benefits of doing something and the initiatives that would be needed to be executed to achieve them.

As the initiatives that are needed to be carried out on a project get structured as discrete entities that deliver either a direct benefit or an intermediate outcome, it thus becomes possible to determine, in later project stages, the effects of the cancellation of a specific initiative - i.e. what benefits will we not get if we cancel it. This is a powerful business tool for protecting project investments.

An important point to note with benefits realization is the recognition that not all benefits are accrued upon project completion – many may take years before they can be fully reaped by the organization. To track the benefits accrual, a 'benefits register' is set up which usually contains the following kinds of information about each outcome:


- Description of outcome
- Contribution – what/to whom does it contribute
- Metric/Frequency – how do measure its realization
- Measurement method
- Baseline value
- Target value/date
- Tolerance limits
- Action if outside tolerance limits
- Accountability
- Benefits profile – i.e. increase, decrease, ratio, etc.


This register then becomes like a dashboard that can be used to determine if the results of having conducted the project are in line with the expectations that were established at its inception.

CSF’s, KPI’s and Metrics

Read an article by Larry Cooper which talked abut CSF’s, KPI’s and Metrics. He makes some good points - but the key thing I want to share here are the distinctions he makes in some of definitions of these terms. The full article can be found here.

Critical Success Factors

Critical success factors were first introduced by D. Ronald Daniel in a 1961 Harvard Business Review (HBR) article. Daniel highlighted the types of information needed to support top management activities. He said that an organization’s information system should be selective and center on providing detail around three to six success factors that help the organization achieve success.

Metrics

When we use the term metric we are referring to a direct numerical measure that represents a piece of business data in the relationship of one or more dimensions. A simple metrics statement is the “number of CI’s in error each month”. In this case, the measure would be the number CI’s found to be in error and the dimension would be time (month).

Metrics are not the KPI’s themselves; rather they are needed in order to determine if our KPI’s have been satisfied. The KPI that might use the above metric could be “% reduction in CI’s in error each month” – you need the number actually in error in order to determine the % of reduction over the previous month’s # of CI’s in error.

Key Performance Indicators

Key performance indicators represent a particular value or characteristic that is measured to assess whether an organization’s goals are being achieved. They reflect the critical success factors, stakeholder needs, and the expectations of the organization. For KPIs and their measures to be effective, the organization’s goals need to be specific, measurable, agreed, realistic and time-based. KPI’s can use both financial and non-financial metrics. "KPI’s…need to specific…measurable, realistic, and time based." KPIs must be constructed by people with different viewpoints on the service or process being measured.

KPI’s are used in conjunction with CSF’s and must have a target that is to be achieved. The target for a KPI can be expressed as a percentage, a simple ratio, an index, a composite average or in a statistical context. Whatever is chosen as a KPI and a target must be actually measurable though. At the outset, keeping the number of KPI’s for a single CSF in the range of 3-5 is recommended.

A KPI is a key part of a measurable objective, which is made up of a direction, KPI, benchmark or target and a timeframe. For example: “5% reduction of CI’s in error each month" where “reduction of CI’s in error each month” is the KPI.

Metrics are used in conjunction with KPI’s to measure CSF’s. A KPI then, is simply a metric that is tied to a target to determine if we have met our CSF. Most often a KPI represents how far a metric is above or below a pre-determined target. In the examples above, you are able to determine whether the target for CI’s in error is being met by comparing the metric to the target for the KPI.

Wednesday

Benefits Realization a Key IT Challenge for Fortune 1000 companies

A study by Planview (a provider of IT Portfolio Management solutions) found that Fortune 1000 Companies Say Benefits Realization a Key IT Challenge. Some points to note from the study when you are looking at Benefits realization in your organization. I found a number of parallels with some of the clients/projects I have worked with/on:

- 90 percent said prioritizing projects to align with business strategies and quantifiably measuring and reporting the benefits of those projects were their most pressing initiatives. Accountability is leading to real cultural changes in IT organizations

- Benefits realization is a key component to the clear communication of IT's contribution to the overall objectives of the organization. It begins with the strategic initiative and is reviewed in a disciplined cycle through funding, project definition and execution and product or service deployment to provable benefit realized.

- Seventy-seven percent of respondents stated that IT project benefits are identified at the outset of a project but not at the strategic level and seldom is evaluated during or after project completion. This is the number one problem at the client I am currently working with!

- Implementing a successful benefits realization process includes creating an atmosphere of acceptance throughout the organization so that every project initiator understands the importance and benefit of determining ultimate ROI for the business. The organization should continue to measure benefits long after the IT development work is complete, and that standard metrics are in place and consistently used by every line of business.

Further details on the study can be found at planview.com

Tuesday

IT @ Intel

Found a informative blog overall at Intel which talks about all things IT and in particular about how Intel looks at benefits realization. I have added the blog link on the right pane under "recommended blogs". The post I was talking about can be found here. To summarize, this is what the authors are saying :

- IT managers just don’t want to put in the effort to determine the ROI of an IT solution. If I had a fraction of the ROI I’ve quantified after being told it was too hard to measure, I’d be sitting on a beach in Barbados drinking beer for the rest of my life. Everything is measurable; it is more a question of the reliability and validity of what you decide to measure.

- What this typically comes down to is getting the right metrics identified and operationally defining them. We use metrics called business value dials to document the value of our IT solutions. Value dials (e.g., employee productivity, days of inventory, factory uptime, etc.) represent a standard set of metrics; each has a definition and standard calculation.


- Operational definitions are a core element of measuring business value. It is the step that translates the concept of business value into some type of measurement. For example, if eight people are asked to measure aggression and report their findings, the likelihood that we would see agreement among them is very low, as each person will define and measure aggression in their own way. The solution, use an operational definition. Give the same eight people the following instructions: “Today you are going to measure aggression. To do this you will go to Washington Elementary School, from 1-2 pm, go the sandbox in the northwest corner, and, using this form, count the number of times one child either strikes or pushes another child.”

- When the reports are in, there will be some discrepancies, a concept known as inter-rater reliability, but overall the data will be similar. Operational definitions are necessary to measure business value. Without operational definitions in place, everyone may be measuring, but it is highly unlikely they are measuring the same thing. Operational definitions make measurement independent of a person or group, repeatable by others, and standardize results.

A very interesting and valid perspective.

Monday

Measuring and Managing IT's Contribution to Business Value


Got an email from my Information week subscription asking me to participate in a IT Business Value Management (IT BVM) study. I think it will be worth participating and to see how our clients compare to other organizations. Details and link below.

Most companies have made significant progress measuring and managing IT performance and controlling IT costs. However, the capability to measure and manage IT's contribution to business value is far less
mature – despite the fact that delivery of measurable business value is now a strategic imperative of most IT organizations. In collaboration with The Hackett Group, InformationWeek is seeking your participation in an extensive research study to assess the level of maturity of IT Business Value Management (IT BVM) and its relation to company performance.

You can participate in the study by going to:

https://www.thehackettgroup.com/portal/site/hpublic/menuitem.5c8b16b9612010ca46d1b710b7f069a0/?id=1012865

Participation in the study is free of charge. Participants in the research study will receive a customized report that allows comparison of their individual IT BVM performance to their peers and to World-Class performers.  The report of approximately 30 pages will consist of a general analysis of IT BVM capability maturity and performance, and a customized section. The Hackett Group will also conduct a free webcast to present the general analysis results, accessible exclusively to survey respondents. Both the custom report and the webcast are expected to be delivered around January 2008. Other than your own personalized report, no individual company information will be released. All responses will remain confidential and will only be reported in aggregate.

Saturday

A benefits register for benefits realization


Next week I am starting on developing a benefits register for the project I am on. A benefits register is the primary tool for facilitating the benefits realization process. It should be created prior to the project/change commencing and the primary input to the document would be the business case or investment proposal. You should primarily capture benefits information, but could also use it to capture Critical success factors (CSF's), or other KPI's. Also, as a project may start sometime after the business case development and approval process, the benefits register should have a separate review and approval process. It is key that the accountable party for the benefits accepts the benefit targets being set.

The benefits register could be developed as an Excel spreadsheet - this is just as effective as any fancy tool. The key thing is to ensure it is actively managed and kept straightforward. For the project I am on now we are piloting Sharepoint as the tool to use for the benefits register.

The key items I think you should include in the benefits register are:

- Description of Benefit : The description should be written after completing the other fields described below and should reflect the baseline and target metrics. eg. Improve customer response time from 3 minutes to 1 minute, thereby allowing servicing of more customers. This is equivalent to additional revenue of $10,000 per month
- Link to Objectives : How does the benefit to be delivered link to or deliver on the business objectives
- Accountability : Who is accountable for realizing the benefit. Should always select the executive responsible for the project to deliver the benefit (most likely the business sponsor on IT projects). The project manager is accountable for delivering the project, not the benefit. While the benefit will not be delivered until the project is successfully delivered, the benefit will only be realized if the business adopts the change (eg delivering a new system is the project objective, using the system is where the business will get the benefits
- Stakeholders/Beneficiaries: These are the groups responsible who have an input into defining/realizing the benefit or the beneficiaries from the benefit value to be delivered
- Baseline : What is the current state of measure of the benefit metric (eg the current process takes 3 minutes). Supporting details can be referenced but should not be included in the benefits register
- Target : What is the target state for the benefit to be achieved (response time to 1 minute). If the target is to be achieved over multiple periods, then divide the targets up by the periods.
- Approach and method : How will be benefit be realized (eg implement CRM system) and what method will be used to determine if the benefit has been achieved (measure response time 3 months after project implementation).

For tracking the project, have a couple more columns to check the status and what issues/action plans are in place to resolve issues. More on this later.

See the links on the right pane for some additional references on the benefit realization process.

Tuesday

NPV Definition and Sample Spreadsheets

On my current engagement, where I am developing the business case process and benefits realization process, I am now trying to develop the Net Present Value (NPV) spreadsheet. Excel has a good NPV calculator, thought I was not able to find many free NPV templates/spreadsheets online (most are $50 or greater). So I am going to customize one of the one I used for a past project and will upload it soon. Here is one I found that may help for now : Straight NPV & IRR and graphs

Per Wikepedia, NPV is defined as standard method for the financial appraisal of long-term projects. It measures the excess or shortfall of cash flows, in present value (PV) terms, once financing charges are met. As a formula this can be expressed as :




Where
t - the time of the cash flow
n - the total time of the project
r - the discount rate
Ct - the net cash flow (the amount of cash) at time t.
C0 - the capital outlay at the beginning of the investment time ( t = 0 )

Generally speaking, a project with a positive NPV is accepted, whereas negative NPV projects should not be accepted on a financial basis - however there may be other reasons for doing the project, eg regulatory.

For IT Projects, the Net Cash flow is generally the difference between the cost of implementing the solution (initial and ongoing) and the financial benefits

verification

Monday

Why developing good business cases and capturing real benefits is getting more important

Worldwide information technology spending will surpass $3 trillion this year, according to market researcher Gartner Inc. IT spending in 2007 will reach $3.1 trillion, an 8 percent increase from last year. Spending for 2008 is forecast to grow 5.5 percent to reach $3.3 trillion.

"On a worldwide basis, IT spending continues to grow at a rapid pace in developing countries," said Peter Sondergaard, senior vice president and global head of research at Gartner, in a statement.

"In fact, one-third of IT spending now occurs outside of North America, Western Europe, and Japan. This development will create new innovation in IT, new competitors, new usage patterns, and continued cost improvement benefits for users," he added.

This makes it especially important for organizations to develop good business cases and understand the value they are getting from their investment. IT spend is now a core and growing expenditure for most companies - so like any investment they need to know what they are getting for it. The business case is where this should be defined and understood.

Friday

Business cases and value realization survey

Saw an interesting survey by Forrester research available on the web. It is in line with my experiences to date, though I always question firms that use ROI and NPV as their primary justification - because NPV numbers and underlying assumptions can always be adjusted to reach a "suitable" figure. NPV is a great quantifiable metric, but it should be evaluated in context of other metrics and the underlying figures/assumptions should always be validated by an independent party.

Thursday

Some more decent and FREE business case templates

Here are some more templates I found on-line. These links have been added to the links on the right hand pane as well. Surprisingly a lot of these were local or state government IT organizations. A number of these have content or sections specific to the organization that created them, so you need t o filter out what you need for your organization's purposes.

Texas Government IT Business case and Instructions

New York State Office of the CIO

Office of Government Commerce (OGC) Detailed and Summary business cases

WA Government IT

JISC

Alberta Government - Infrastructure and transportation business case

NSW Department of Commerce Detailed business case with instructions

If you have any more good ones let me know.

Wednesday

Business Case Templates

Started on a new activity in my current project - putting together a business case template. I have done a few of these in the past so have a good idea of what needs to be done. The key sections are Executive Summary, Background/Case for Change, Cost/Benefit Analysis, Approach and alternative solution analysis. Off course each client will have unique requirements and constraints for which you must tailor the business case.

I also thought that I would check out the web to see what is out there and I ended up finding some useful templates. For example I found one by the CIO office of the South Carolina Local Government. It is quite detailed (more than I needed) - but has some good explanations of each of the sections.

Going forward for the blog, I have created a Free Business Case Templates list on the right pane, within which I will put the links to good (and free) business case templates I find on the web. One day I hope to post the templates I have developed, but client confidentiality agreements prevent me from doing this right now.

If you see any good business cases or benefit register templates let me know and I will post it and credit you for it!

VAL IT Methodology - a useful reference framework

A colleague of mine pointed me to a very useful site today which has some great information on benefits and business cases from an IT Governance perspective. The site is the ISACA website and the section you want is a methodology called VAL IT . I have added this under the Benefits Management resources on the right page and will be discussing some of the articles from it in the next few posts. It has some paid and free content so if your organization is embarking on a IT governance effort it is worth a look at this value/governance driven methodology – which is tied into the COBIT framework.

Tuesday

Critical success factors vs benefits

One thing I have noticed at the organization I am currently consulting at (see previous post), is that a lot of stakeholders use Critical Success Factors (CSF) or Key Performance Indicators (KPI's) as viable alternative to benefits. I don't agree with this.

Here is the difference as I see it:

A benefit is used to justify why an investment makes sense. Eg implement this new system as it will reduce support costs by $X through retirement of legacy systems and reduction in FTE's.

A CSF or KPI is for measuring the performance of an initiative (project, change etc) once it has been justified via building the business case where you state the financial/non-financial benefits and determine the NPV, ROI etc. A CSF/KPI is used to measure how the initiative is tracking in terms of meeting the stated benefits and objectives. Off course it is based on the benefits to be realized - but should not take their place. When a benefit is clearly measurable, then the CSF/KPI will be very similar to the benefit target. A CSF/KPI is very useful for intangible benefits, where it can be used as a good proxy to provide a measure for determining if the benefit has been achieved (eg Train 1000 users by MM/YY date).

Any thoughts?

Sunday

New project

Starting a new project this week around defining a business case template for a client - this includes defining a benefits management framework. Thorough this process I will hopefully find a lot of public information, which I will post on this blog. If you know of any please let me know.

It's interesting, I always here the classic - I cannot define my benefits because they are too intangible or regulatory! Well, if you cannot define the benefit, at least define a KPI to know you will achieve it! I also really think that all projects can define some tangible benefits. The problem is getting senior management stakeholders/sponsors to be accountable for these benefits.

Thursday

Gartner - Building Great Business Cases

Found a great document on the web which talks about building great business cases from a benefits perspective. It is Gartner's Business case development article. Definitely worth a read. It is attached below - let me know your thoughts on it and happy reading!

Note - if you are having problems accessing the document or cannot see it, drop me a comment with your email and I will send it to you.

Cost-Benefit Analysis

Saw a good article on Cost/benefit analysis at Solution matrix. You can even download a free spreadsheet if you subscribe to their news letter.

Here are some highlights from the article.

- The term Cost benefit analysis is used frequently in business planning and decision support. However, the term itself has no precise definition beyond the idea that both positive and negative impacts are going to be summarized and then weighed against each other.

The term covers several varieties of business case analysis, such as:

Return on investment (ROI analysis)
Financial justification
Cost of ownership analysis
All of these approaches to cost benefit analysis attempt to predict the financial impacts and other business consequences of an action. All these approaches have the same structural and procedural requirements for building a strong, successful business case. They differ primarily in terms of:

Wednesday

An interesting post..

Saw an interesting post from by Terry Doerscher on September 13, 2007 that talked about Benefits Management

Some interesting items of note:

- I (Terry) have to admit that at first I didn't key in on its true significance, but have since come to really appreciate Benefit Management as an essential ingredient to achieving high levels of business performance, but one that is too often missing from the process repertoire. If you can employ this function with some degree of competence, it will drive the improvement and integration of many other main-line processes such as strategic planning, portfolio analysis, scope control, and product and service management.

So, what exactly is Benefit Management, or Benefit Realization as it is sometimes referred to? It is a formal mechanism for making sure that someone is keeping a watchful eye on business value versus cost and risk as a program or initiative is proposed, analyzed, approved, developed and deployed, and the methods applied to accomplish those functions.

The Benefit Owner is the central figure to employ Benefit Realization techniques, working in conjunction with portfolio, program and project managers, sponsors and other common roles. Uniquely, the benefit owner is responsible for maintaining a consistent and detailed long term line-of-sight focus on results relative to risk and cost. They ensure benefits are defined, cataloged and quantified as programs or initiatives are created and developed, and challenge ROI, NPV, or IRR assumptions for accuracy. The benefit owner also ensures that benefit metrics are established integral to program approval.

During execution, the benefit owner is responsible for monitoring underlying projects to ensure they stay on track to deliver program objectives at defined cost-benefit values as they face scope changes, delays and technical challenges. If at any time it becomes apparent that achievement of benefit is compromised or in serious jeopardy, the benefit owner has the authority to recommend replacing under-achieving projects or killing the overall effort.

Post-deployment, and long after the project managers are on to other assignments, the benefit owner stays on point to measure how actual program results track to initial projections, recommend adjustments and communicate lessons learned. In some cases, they may remain engaged over the life of the product or service, assisting in continued evaluation of benefit and making end-of-life assessments.

The role of the PMO in benefit realization

The PMO's role in all this is to help sponsor the program and establish processes, train participants, assist the benefit owners with information gathering and analysis, and facilitate reporting. They are also a natural liaison between benefit owners and project managers to help develop a collaborative partnership.

While there are a lot of underlying details that go into this process, I think you
can begin to appreciate how Benefit Management acts as a magnetic force to couple strategic intent with actual results. It fosters methodical analysis of investment portfolios relative to business need, and goes a long way towards countering a fire-and-forget mentality that sometimes takes root after the funding decision is made. By providing active value-based management oversight of deliverables as they are designed and developed, it mitigates the potential for a program or project to go on needlessly, or inadvertently lose the essential elements that deliver true business benefit when stresses arise.

Finally, it addresses the age-old problem of who will measure the value that a new
product or service actually delivers compared to those fantastical promises of 4-digit ROI on the front-end. In business management, like most skill sports, a seamless follow-through is frequently the hallmark of proper form.

Great post Terry!

The information paradox - great book for understanding the benefits process

One book I have on my reference list, is
The information paradox. This is a great resource I recommend you get.

The book discusses the following mindset underlying the Benefits Realization Approach and is based on the following premises:

Benefits do not just happen - They don’t just automatically appear when a new technology is delivered. A benefits stream flows and evolves over time as people learn to use it.

Benefits rarely happen according to plan. A forecast of benefits to support the business case for an investment is just an early estimate. It is unlikely to turn out as expected, much like corporate earnings forecasts. You have to keep checking, just as you would with a financial investment that fluctuates in value on the securities market.

Benefits realization is a continuous process of envisioning results, implementing, checking intermediate results and dynamically adjusting the path leading from investments to business results. Benefits realization is a process that can and must be managed, just like any other business process.

Purpose of this blog

Hi - this is my first post on this blog. I have been in the technology industry for over 10 years as a consultant, business analyst and projects manager. I moved into the IT Strategy and Governance (ITSG) space after about 5 years ago, where I was more in the delivery space. The ITSG area exposed me to the business case development process and the topic of benefits management. Most organizations struggle to define good benefits and that is why business case value propositions are some times very subjective. If you can't define and then quantify benefits, all the financial calculations (like NPV, IRR) will be pretty meaningless. Also, poor benefits definition will make the whole benefits management process redundant and hence no way of objectively saying that beenfits were realized.

This is a blog for professionals to share their views, questions and ideas around the Benefits Management process, in terms of defining benefits during the investment or business case process, managing and measuring benefits to eventually realizing the benefits when the solution is delivered. We will touch on various related topics and good resources. My focus, per my background, will be on benefits from technology or process solutions, however there is no reason other types of projects cannot use the same rationale.

If you know of any good links, resources or information you would like to share please share it with me and I will put it on this site.