| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

Building a Business Case for Groupware

Page history last edited by Amantucca@gmail.com 10 years, 4 months ago

 

Business Case Working Documents

 

Building a Business Case - Outline  

 

Building a Business Case - Meeting Minutes

 

Building a Business Case - Team Info

 

---------------------------------------------------------------------------------------------------------------------------------------

Building the Business Case for Groupware

 

Introduction

     When tasked with a Groupware project, many teams may tend to directly begin the project before taking the time to develop and structure a detailed business case. This common approach is misguided, as a carefully researched and well prepared business case sets the tone for successful procurement and implementation for a Groupware application. One of the main differences between a business case for Groupware and one developed for an ERP application, such as Oracle, is the inclusion of a return on investment (ROI) analysis.  Enterprise Resource Planning (ERP) is defined as an integrated computer-based system used to manage internal and external resources including tangible assets, financial resources, materials, and human resources (http://en.wikipedia.org/wiki/Enterprise_resource_planning).  A case for an ERP system will put the most weight on the financial criteria as these systems are highly complex and have a significant tangible business impact. Conversely, a case for Groupware places more weight on business process analysis and collaboration benefits. A solid business case lays the foundation for a successful Groupware application. To demonstrate the importance of a business case resulting in a successful project, the following key statistics have been identified from a 2008 survey by CIO.com (Assay, 2008) of 800 IT Managers:

  • 62 percent of IT projects failed to meet their schedules
  • 49 percent suffered budget overruns
  • 47 percent had higher-than-expected maintenance costs
  • 41 percent failed to deliver the expected business value or return on investment (ROI)
  • 25 percent were cancelled before completion

     

     These figures illustrate the lack of stability that plagues many project initiatives and how a structured business case can help alleviate this instability. In addition, the business itself should own the business case, not the IT organization. In an application initiative, there are three primary stakeholders, all of whom must be thoroughly involved in the development.  In Denise Ganly's article for Gartner she outlines the following three stakeholder groups (Ganly, 2009):

  • Business process owners – These are the business managers most directly affected by the initiative. One or more of these managers needs to be the driving force behind the initiative and will act as its sponsor.  Primary responsibilities include defining business requirements, active participation in defining the solution, and most importantly being the advocate for communication among all involved parties.
  • Financial representatives – These are members of the finance group who are responsible for budgeting the initiative. They also provide business executives with clearly defined lines of responsibility and accountability.
  • IT organization – These individuals provide the necessary information for making IT decisions. They also ensure a proper balance of roles and responsibilities among the three stakeholder groups.  The IT organization’s primary goal is to provide value to the business customer by offering services that lead to competitive advantage, promoting a drive towards continuous improvement, and maximizing investments in technology to improve productivity.

 

     One of the first steps when building a business case is to identify the stakeholders based on the groups identified above.  Classification of the size of the project is a good place to begin; does the initiative stand to impact a single department or the whole company? If it is a company-wide initiative, then the business process owner and executive sponsor would most likely be the CEO or COO. If the project is targeted toward a specific department, then a Manager or Assistant Manager would probably be sufficient as the executive sponsor. Once the stakeholders are identified, the selection process can begin for the application initiative team.  The individuals chosen for the application initiative team must continue through the selection, implementation and post implementation phases to provide continuity to the project. This continuity provides the organization/department with a deeper understanding of the overall achievement of the project and how the defined objectives will be met.  A typical business case should contain the following sections:

  • Business Case Preparation
    • Situational (current state) assessment and problem statement
    • Project description
    • Solution description
    • Implementation timeline
    • Critical assumptions, constraints, and risk assessment
    • Conclusion and recommendations
    • Cost Benefit Analysis
      • Rules for quantifying costs and benefits
      • Project costs
      • Overview of benefits
      • Identification of benefits
      • Quantifying the benefits
      • Cost and benefit conclusion

 

     One of the main goals of every business case is to clearly illustrate how the initiative will change or improve a current business process. This is especially critical for Groupware initiatives as often times the changes or benefits associated with these projects are intangible and difficult to quantify. The main objective of a Groupware application is not just about cutting lead or production times, rather they are tools that can change internal processes and help employees collaborate.  As a result, it is important to distinguish the potential business impact that the Groupware will provide throughout the business case.  This concept will be discussed later in this chapter.

     When preparing a business case, an organization should undertake a series of tasks in four stages: Initiation, Business Impact, Option Evaluation, and Documentation and Review (see Figure 1). One key point is that building a business case should always be an iterative process. Therefore, research findings and lessons learned should be utilized to continually revisit these stages and update the business case development accordingly.

 

Figure 1. Business Case Process  

 

Initiation Stage

     There are four main items in the initiation stage. This may be the smallest stage in the business case development, but it helps set the foundation for the case. The main objective in this stage is to define the following:

  • Business case
  • Major stakeholders
  • Audience
  • Those responsible for writing the business case

 

Define the Initiative and How It Addresses the Business Strategy

     The business case initiative must be defined as clearly as possible and illustrate how the Groupware system will fit into the overall culture of the organization. This is important as the new application must drive business value; otherwise the case for changing the standard business process will not be strong enough to garner approval. The initiative should have clearly defined goals and proposed solutions.

 

Identify Stakeholders and Business Case Audience and Form the Business Case Team

     These three tasks can be discussed in tandem because they have a similar purpose; to establish the target audience of the business case and who will complete the preparation. The business case team should involve the business process owners, financial representatives and IT organization. This phase will also help identify the executive sponsor and any other key stakeholders.

     In all business cases, choosing the team is very important but it is especially important for a Groupware application initiative. As Groupware is not for all companies, the project team should include a mixture of members who understand the software and how it will impact the organization and improve business processes. Also, as Groupware generally provides initial intangible improvements, it is often difficult to provide an estimated ROI to the stakeholders.  Therefore the number of financial representatives required may be low. It is also important to ensure that some members demonstrate collaboration and facilitation skills, as these will play an important role in building the business case. Team members will not only develop the business plan for collaboration software, they will also need to use it, and this will help build a deeper understanding of the process.

     The next step in the process involves stakeholder identification.  Project stakeholders are individuals and organizations that are actively involved in the project or whose interests may be affected as a result of project execution or project completion.  The project team must identify the stakeholders, determine their requirements and expectations and, to the extent possible, manage their influence in relation to the requirements to ensure a successful project.  Roles must be developed in this stage as well, and all stakeholders should understand their purpose on the case. If stakeholders do not know the roles they will play, this could lead to internal issues and miscommunication. All in all it comes down to a very simple concept; the business must own the project.

 

Determining the Business Impact

     This stage of the business case development process focuses on accurately defining the overall impact of the proposed initiative in relation to the organization's core business processes.  A major function of the business case is to justify the need and the required expense for the initiative.  In order to effectively quantify the benefits, it is necessary to have a clear view of the current process, how the initiative will impact the process and the benefits and risks of implementing the proposed change.  In Denise Ganly's article for Gartner (Ganly, 2009) she outlines the above fundamentals into a 3 step staged approach:

  • Document the current state
  • Determine the future state
  • Quantify the benefits and risks

 

Documenting the Current State

     The goal for the first step is to define the current state of all business processes that will be affected by the initiative. This includes the identification of any existing applications that support these processes and documentation on the current IT strategy and architecture.  It is also important to determine whether there are any existing projects or initiatives that would overlap the scope of the proposed change.  As the main objective for this stage is to objectively measure the potential business impact to the overall goal of the organization; updated process maps that provide a macro view of the company are an extremely useful tool.  Although this information is often non-existent or out of date, it is worth the effort to construct or update the process maps as they provide an accurate baseline of which to measure improvements. 

     The goal of process mapping is essentially to identify each business process, which is defined as a collection of related activities or tasks that produce a specific goal for the organization.  It is extremely helpful to visualize a business process as a sequence of tasks outlined in a flowchart.  For example, the primary function of an accounts receivable department is to invoice for services or goods rendered by the organization and to collect payment in a timely manner.  The process map for this department would track the activities and tasks that are necessary in order to get the function accomplished as demonstrated in Figure 2.  The process map should not only include the specific activities, but also information pertaining to required resources, time involved and specifically for Groupware initiatives, what applications are being utilized.

 


            There is a fine line between dedicating the appropriate amount of time for proper analysis and wasting time and resources by delving into too much detail.  Keep in mind that the documentation of current processes is a small fraction of the overall business case development process and therefore only spend time on relevant procedures.  Ganly (Ganly, 2009) recommends that efforts be restricted to "processes that drive competitive advantage, support regulatory or compliance needs, or provide unique functionality" and an organization  "should not spend more than 15% of the estimated effort for the project in completing this task."

             In addition to process mapping it is also extremely important to gather traditional accounting metrics.  The metrics that should be used are highly dependent upon the processes that the organization is looking to improve.  This concept will be discussed in further detail later in this chapter, but it is important to mention in this section as the necessary metrics should be determined at this stage.  These metrics will be used to determine the Return on Investment (ROI) for the Groupware initiative.  ROI, also known as the rate of return, is defined as the ratio of money gained or lost on an investment relative to the amount of money invested (http://en.wikipedia.org/wiki/Rate_of_return).  Simply put, it is what the organization stands to gain in return for its investment in the initiative, in dollars and the standard calculation is as follows:

 

ROI = (Gain from Investment - Cost of Investment) / Cost of Investment

 

     It is important to identify the metrics at this stage in the process as the same criteria should be used to quantify improvements in the next stage of the business case development process.

 

Determining the Future State

     Once a baseline has been effectively established through defining the relevant process maps and identifying the appropriate accounting metrics, it is time to begin documentation and analysis of the proposed future state. This includes defining the specifics of the new process and the new applications that will be used to facilitate these processes.  The future state should be envisioned and developed to the same extent as the current state.  This includes process mappings for the changes to the business processes and utilizing the same accounting metrics previously selected for the baseline.  It is also during this step that the working scope for the project takes form.  Scope should be considered an objective for a project, and should be specified in terms of the results to be achieved.  The scope may be embedded in a variety of other documents, including the project requirements document, the project charter, and the project business case.  It provides a single-statement, single-paragraph, or single-page overview of the project and the boundaries it is expected to cover.  It describes the project in clear objective terms, highlighting the outcomes and any deliverables associated with the effort.  It is important to have a sense of the scope for the initiative when preparing the business case.

     It is also extremely beneficial to initiate and maintain clear communication with the people directly affected by the Groupware initiative, as they will be in a good position to discuss the feasibility of the initiative and the financial impact.  As this process is completed, proper documentation should be maintained in an effort to create an audit trail.  This documentation could prove a valuable tool for demonstrating business impact rationale to key stakeholders and assist in the financial analysis.

 

Quantifying Benefits and Risks 

     Once a clear picture of the current and future state is established, it is time be begin the comparison analysis. Identifying the gaps between the current and future state of the business process is a good place to begin the initiative benefit analysis.  The benefits of any initiative can be difficult to measure, but as mentioned earlier, this is especially true with Groupware projects. Groupware initiatives are largely new and only recently have been generating interest in the mainstream.  Any benefits identified for the proposed change should be allocated into the following basic categories:

  • Strategic Business
  • Hard Financial
  • Soft Financial

 

     A strategic business benefit is a benefit that affects the organizations core business strategy or helps provide compliance with industry regulations.  These benefits are both highly valuable but also carry a high impact of failure.  Any initiative that will potentially yield a strategic benefit will generally be closely monitored from an executive level.  One example of a strategic business benefit is a new compliance package that consolidates all the reporting documentation for an organization into one centralized area for department wide review.  This initiative would allow for easier sharing of knowledge and collaboration on monitoring and submission, thus providing a strategic benefit.

     Hard financial benefits, also known as tangible financial benefits, are the easiest to quantify as they can be directly measured in monetary terms.  Although these types of benefits are technically the easiest to compute, it is important to analyze the entire financial impact when quantifying this type of benefit.  This analysis should not only include the potential financial gain that the initiative may provide, but also consider the total project cost.  This includes any consulting fees, transition and implementation costs, hardware, training, etc.  Some examples of hard financial benefits include reduced head count due to increased collaboration, reduced travel cost or reduced office locations due to telepresence.  

     The last and most difficult type of benefit to evaluate is the soft financial benefit.  This benefit is of an intangible nature that is exceedingly hard to quantify. They do not lend themselves easily to any established metrics and are often subjective.  Examples of this include improved collaboration or decision making.  Although these benefits are qualitative in nature, they are often times highly important to the organization and provide the potential for long term hard financial benefits.  Soft financial benefits are quite common for Groupware initiatives and therefore have been involved in an effort in recent years to develop a better measurement for these types of benefits.

     Regardless if your benefits are hard or soft, it is critical that you develop specific metrics to measure the benefit that you indicate will be achieved in the business case.  Hard benefits are usually easy to measure since they equate to a tangible or material savings.  Soft benefits are more difficult to measure since they are usually very subjective in nature.  Although difficult to measure, a clear baseline must be established to measure the benefits against.  It may be as simple as a survey to measure the difference in customer satisfaction or employee moral but regardless of what the benefit is, there must be a corresponding measurement.  Remember, if you can’t measure it, you likely won’t be able to effectively manage it

     Gartner, Inc bills themselves as the world's leading information technology research and advisory company (www.gartner.com).  Their research arm, Gartner Research, endeavored to create a framework to correlate IT function improvement to more traditional business metrics.  The result of this endeavor was The Gartner Business Value Model.  Within this document they created several new performance metrics which have been grouped into aggregate categories depending on initiative, which is illustrated in the below table (Figure 3).  Although many of these performance indices may not directly relate to a specific groupware initiative, many of these metrics can be adapted to be included in the business case.

 

Figure 3

 

 

Source: Gartner (September 2009)

 

 

     After benefits are thoroughly identified and defined, it is necessary to evaluate the potential risks.  Risks should be reviewed from two standpoints:  the likelihood of occurrence and the potential impact to the business or initiative should the risk materialize.  A standard project management risk matrix can be used to facilitate risk assessment and analysis.  As demonstrated in the below graph (Figure 4), the y axis builds out the likelihood of the risk occurring and the x axis builds out the potential impact.  Each identified risk is then plotted on the graph plot to achieve a visual representation of the overall risks.  Risks identified with the highest likelihood and highest impact are considered to be the most important to monitor and develop contingency plans.

 

 

Option Evaluation

     The next stage of the business case development process consists of a series of evaluations to determine various application options and select the appropriate criteria for weighing them.  The model parameters should also be created with a variety of factors to determine success.  These include but are not limited to payback, non-financial assessment and associated risk and costs.

 

Determining Groupware Options

     The first step is to determine the various relevant application options that the initiative may present.  This step can be divided into two separate phases:

  • Evaluation of how the option may appeal to stakeholders and other relevant parties
  • Evaluation of how the option may appeal to employees and fulfill the collaboration requirements 

 

     Available options are determined by a number of other factors beyond the beginning evaluations.  These include resource availability, office politics and an umbrella category that includes other external factors.  These external factors may include anything from how risk-averse or innovative a company culture to factors such as spending freezes, collaboration with certain vendors etc.  When building a business case to justify a new initiative, there are several factors that can provide guidance in picking the best available option:

  • The option should either save the company the most money or provide a profit
  • There should be multiple reasons that support or promote the chosen software option
  • The option should support other company initiatives
  • Associated risk should be low

 

     If your options have survived phase one of the vetting process and appeal to stakeholders, the potential Groupware option then needs verification that it fulfills the requirement to improve collaboration within the organization. A white paper by Socialtext.com (Socialtext, 2009) has identified five criteria for this sort of evaluation:

 

  • Integrate social networking.  Most importantly this means that it should help employees get to know each other and keep each other updated automatically.  It should also help employees collaborate on ideas in a more efficient manner or match employee talent to various projects.
  • Very high adoption rate.  Members of the organization should be on board and ready to adopt the proposed Groupware, to the tune of approximately 99.9%.  Applications that are user friendly, easy to install, and have a high value proposition generally retain a high adoption rate.
  • Fits in with workflow.  The Groupware initiative should easily integrate with email and mobile devices to promote real time updates.  A good option is to make it available offline so the user can read messages and work on files in places such as airplanes or areas without data service. 
  • Aggregates information universally.  Other commonly used enterprise applications, such as Outlook calendars and work blogs should easily integrate into the solution for ease of use to the user. 
  • Total Cost of Ownership.  The cost to implement and maintain the application should be low with a high rate of return.

 

Determining the Evaluation Criteria and Weightings

     Once an application option has been selected it is necessary to determine additional items within the software that require evaluation and their order of importance.  The same guidelines used for determining various options should be used to determine evaluation criteria.  However, in this stage it is important to identify what is of most importance.  Where the last phase was focused on “what” questions, this phase asks the “how”.

     The first set of criteria that requires evaluation is identifying how the Groupware software assists the company mission as a whole.  Some factors to evaluate are how the collaboration software improves productivity, cost reduction, business continuity, and revenue growth.  Productivity and cost reduction should hold a higher weight than that of business continuity and revenue growth.  One argument for this thought is if productivity increases and costs are reduced it will promote business continuity and revenue growth.  The tools that increase productivity and reduce costs are generally the tools that should receive the highest rating (Kelly, B, and Marty Parker, 2009).  

The second set of criteria is to select an application tool that has the best ability to meet the following seven critical factors.  (Osterman Research, Inc, 2005):

  • Contact Aggregation:  The ability for the software to grow with the company through mergers and acquisitions and change management.
  • Presence-enablement:  The user should easily be able to identify the online presence of other users.  This adds value by making impromptu meetings easier to initiate.
  • Support for multi-presence sources:  The average corporation uses an average of 3.1 instant messaging systems in the office.  This collaboration system must be able to use multiple systems also, or consolidate the varying systems into one. 
  • Security:  As sensitive corporate information is shared, a firewall and best practices in information and network security management is a must.
  • Ease of use: The easier the application is to use the more likely it will be adopted. 
  • Ease of Administration:  Groupware should be easy for IT to support and maintain the software. 
  • Flexibility:  The software should be flexible to handle large and small meetings, work online and offline and allow customer access.

 

Documentation and Review

     After the above analysis has been completed, it is now the time in the business case process that the actual writing begins.  At this point in the process, there should be a clearly defined initiative and the associated business impact and potential effects to the overall business strategy have been indentified.  The current baseline should be clearly documented and thoroughly compared to the potential future state.  All associated benefits should be quantified and weighed and risks identified.  Various application options should be gathered and evaluation criteria should be developed and weighed.  The final Groupware option should be determined and now the foundation is complete to construct the actual business case.

 

Writing the Business Case

     As Ganly points our in her article (Ganly, 2009) a business case should be written and presented in a simple and logical manner.  The goal of any well written business case should be for any member of the process department to be able to pick up the document and clearly understand the concepts within.  Business cases are often evolving documents and utilizing a clear and simple writing approach helps the process run smoother and is easier to maintain.

     The beginning point for the business case is arguably the executive summary.  The executive summary consists of exactly what the title states.  It's a summary of your business case of which the executive staff will be introduced to the initiative and start their review.  It should contain all the pertinent conclusions but without the support data and rationale used to achieve them.  It should be concise and clearly worded.  Borrowing from the journalism world, it should include who, what, when, where, why, and how.  Lastly, it is helpful to use reference marks within the text when presenting any financial conclusions so that the supporting data in the detailed business case is easily identifiable.

     Next, the business case should focus on the problem statement and why a solution is necessary.  It is difficult, if not impossible; to develop a solution if one cannot identify the root cause of the problem.  A problem statement is a clear concise description of the issue(s) that need(s) to be addressed by the project team.  It is used to focus the team at the beginning, keep the team on track during the duration of the project, and to validate that the outcome the problem statement is expected to solve.

     Once the problem statement is established then the project team can focus on documenting all viable solutions.  It is important that more than a single solution be evaluated to demonstrate the level of due diligence that the team performed in evaluating all viable solutions.  It is here that all available options for addressing the business need are evaluated in detail.   Showing that you have seriously considered all the possibilities will strengthen your business case.  Providing management with all the available information will also increase the chances that someone could suggest other potential solutions.  

The business case should also contain a proposed timeline to show how long it will take to implement the proposed initiative.  As the timeline is evaluated it is important to note that project cost and project risk are both directly impacted by timeline.  If a project has a long duration, for example 2 years, it will likely have more cost and more risk than a project with a duration of only 2 months.  It is important to assess timeline, costs, and risks individually, as well as together, since one may directly impact the other.

     While writing, it is important to create and maintain a balance between the potential hard and soft benefits.  If your Groupware initiative is heavy on soft or qualitative benefits,  then it is effective to present the quantitative benefits in a strong and clear manner.   Most executive staff have a tendency to rely on hard data, therefore this information should be easy to identify and the rationale easy to understand. Whether the benefits are hard or soft it is critical that the benefit is measurable.  This is the only way that management can assess if the actual benefits are achieved.  It is important that all benefits also refer to how they will be measured.

     The last part of business case development involves making a recommendations based on the options presented.  Obviously, the quality of the recommendation is a direct result of the effort put forth identifying the potential options.  Recommendations are directed at solving whatever strategic problem the company is facing.  The recommendation should be in line with your analysis; that is, it should follow a logical approach based on the inputs contained within the business case.  Also, it is important that every business case contain the option of no action, as this is the baseline of which all other options should be measured.


Summary

     Writing a business case is not an easy endeavor for any initiative, most notably Groupware projects.  The vocabulary and culture of the IT and Finance departments are often divergent which can be evident when the two join for a project initiative.  This relationship is further complicated by the difficulty in quantifying the potential benefits involved with a groupware project.  The concepts outlined in this chapter can assist with producing a clear, effective business case and maximize the chances for a successful Groupware initiative.

     A strong business case should always begin with the initiation stage.  It is always important to approach a business case with a clear definition of the case initiative and what strategic issues it aims to improve.  Once this is defined, the next step is to identify the stakeholders and build a solid team.  Identifying and receiving the support of the key people involved can ensure the Groupware initiative gains visibility and momentum.  The next step is to determine the potential business impact to the company.  Clear identification and documentation of the organization’s current and future processes provides a solid foundation for quantifying the potential benefits that the Groupware will provide.  It is also important to identify potential risks.  Risk identification provides full disclosure to the stakeholders and allows for contingency and risk response plans in an effort to mitigate the impact. Third, a thorough application option evaluation and analysis should be completed in an effort to choose the best suited tool for the initiative.  It is important to invest the time to really understand what would be the most effective for the organization in terms of financials, scalability, culture, usability and flexibility.

     Lastly, write a clear and concise business case that includes logical and simple content.  Conclusions and calculations should be accompanied with a clearly defined rationale and diligent evaluation.  Make sure to include an executive summary that is concise and clearly worded.  Investing the time and following these simple steps will produce a strong business case and provide the catalyst for getting the Groupware initiative from an idea to reality.

 

Glossary

CDW- (formally known as Computer Discount Warehouse) a leading provider of technology solutions for business, government and education. www.cdw.com

 

Dropship- SPS program that is used to send products directly to customers. www.cdw.com

 

Plays and Programs – SPS program to generate revenue and product for account managers. www.cdw.com

 

Task – SPS program dedicated to account managers to organize daily activities.  www.cdw.com

 

SPS – Sales Productive Suite: System used at CDW as customer database and order taker.  www.cdw.com

 

Business case - A type of decision-making tool used to determine the effects a particular decision will have on profitability. A business case should show how the decision will alter cash flows over a period of time, and how costs and revenue will change. Specific attention is paid to internal rate of return (IRR), cash flow and payback period. Analyzing the financial outcomes stemming from choosing a different vendor to sell a company's product is an example of a business case.  www.businessdictionary.com

 

Scope - Sum of all individual jobs comprising a contract, employment, program, or project. www.businessdictionary.com

 

Process maps - Graphical representation of the sequence of steps or tasks (workflow) constituting a process, from raw materials through to the finished product. It serves as a tool for examining the process in detail to identify areas of possible improvements. www.businessdictionary.com

 

Metrics - Standards of measurement by which efficiency, performance, progress, or quality of a plan, process, or product can be assessed.  www.businessdictionary.com

 

ROI - Earning power of assets measured as the ratio of the net income (profit less depreciation) to the average capital employed (or equity capital) in a firm or project. Expressed usually as a percentage, it is a measure of the profitability which (while not taking the time value of money into account) indicates whether or not a firm is using its resources in an efficient manner. For example, if the ROI of a firm (in the long run) is lower than its cost-of-capital then the firm will be better off by liquidating its assets and depositing the proceeds in a bank.  www.businessdictionary.com

 

Hard Financial Benefit - Measurable increase in revenue, or cost savings, expected to be realized through the implementation of a policy, program, or project.  www.businessdictionary.com

 

Soft Financial Benefit - Benefits that are not financial in nature.  www.dictionary.com

 

Risk - The degree of probability of such loss.  www.dictionary.com

 

 

References

Ganly, Denise. "An ERP/Business Application Business Case Tutorial." Gartner, Inc (2009): 17. Web. 25 Feb 2010. <http://my.gartner.com/resources/169900/169964/an_erpbusiness_application_b_169964.pdf?h=277DCC36C89501526A724B69F2E2285F193CFEB4>.

Landry, Susan, and Anne Lapkin. "Use Gartner's Business Value Model to Tackle the Perennial Problem of Business Alignment." Gartner, Inc (2009): 7. Web. 25 Feb 2010. <http://my.gartner.com/resources/170400/170459/use_gartners_businss_value__170459.pdf?h=149128C618A5F35CD856148D695F6A200208CA9E>.

Chandler, Neil. "Consider Six Factors to Develop a Successful CPM Business Case." Gartner, Inc (2009): 7. Web. 25 Feb 2010. <http://my.gartner.com/resources/172400/172455/consider_six_factors_to_deve_172455.pdf?h=4803DF811AECA79DB4711347599EDA08ABECF417>.

Jones, Nick. "Creating Persuasive Mobile Business Cases in a Recession." Gartner, Inc (2009): 7. Web. 25 Feb 2010. <http://my.gartner.com/resources/165000/165062/creating_persuasive_mobile_b_165062.pdf?h=F224A791FE77C16AFC5E0A305B13A3D08315F14B>.

Woods, Jeff. "Gartner Interviews Andrew McAfee on Why Investment in Enterprise Applications and ERP Matters." Gartner, Inc (2009): 11. Web. 25 Feb 2010. <http://my.gartner.com/resources/164600/164665/gartner_interviews_andrew_mc_164665.pdf?h=02A72A72ECEDF1FD415C5E65D753A33709D89852>.

Olding, Elise. "How to Address CFO Concerns in the BPM Business Case." Gartner, Inc (2009): 6. Web. 25 Feb 2010. <http://my.gartner.com/resources/166100/166164/how_to_address_cfo_concerns__166164.pdf?h=30B2EB883D733297193CACE9B1B5703A63DD9466>.

Adams, Patricia. "IT Infrastructure and Operations Management Cost Justification in 2009." Gartner, Inc (2009): 6. Web. 25 Feb 2010. <http://my.gartner.com/resources/168300/168321/it_infrastructure_and_operat_168321.pdf?h=EA078AE01924C4BD37F1F8F77F812476CB8A808F>.

Smith, Michael, Audrey Apfel, and Richard Mitchell. "The Gartner Business Value Model: A Framework for Measuring Business Performance." Gartner, Inc (2006): 68. Web. 25 Feb 2010. <http://my.gartner.com/resources/139400/139413/the_gartner_business_value_m_139413.pdf?h=D8BAA430AE6014BDE389CBB398D6ED4633D36D89>.

Ganly, Denise. "Tutorial: How to Use a Robust Business Case Process to Avoid Seven Common ERP Pitfalls." Gartner, Inc (2009): 8. Web. 25 Feb 2010. <http://my.gartner.com/resources/170400/170415/tutorial_how_to_use_a_robust_170415.pdf?h=7B3C149725D24BE664F24CE05CD7BD9111837348>.

Schlegel, Kurt, Rita Sallam, Tom Austin, and Carol Rozwell. "The Rise of Collaborative Decision Making." Gartner, Inc. (2009): 7. Web. 13 Mar 2010. <http://my.gartner.com/resources/164700/164718/the_rise_of_collaborative_de_164718.pdf?h=356AD9C5B7FEB244DC59363865E773A56E7C35E6>.

Gonsalves, Antone. "Business Value Of Web 2.0 Tools Hard To Measure." InformationWeek 27 jul 2007: 2. Web. 13 Mar 2010. <http://www.informationweek.com/shared/printableArticleSrc.jhtml;jsessionid=PENRYDXISCQ2VQE1GHPSKHWATMY32JVN>.

Pogue, David. "Are You Taking Advantage of Web 2.0?." New York Times 27 mar 2008: 3. Web. 13 Mar 2010. <http://www.nytimes.com/indexes/2008/03/27/technology/circuitsemail/index.html>.

Coleman, D. (2009). Developing an ROI for Collaboration Projects and Programs [White Paper]. Retrieved from http://collaborate.com/white_papers/mem/white_papers/new_ROIforCollaborationArticle.pdf.

Osterman Research, Inc. (2005). Critical Success Factors for Deploying Real-Time Collaboration [White Paper]. Retrieved from http://www.ostermanresearch.com/whitepapers/download17.htm.

Socialtext. (2009). Five Best Practices For Enterprise Collaboration Success [White Paper]. Retrieved from http://www.scribd.com/doc/11954627/Whitepaper-Best-Practices-for-Enterprise-Collaboration.

Collaborative Strategies, LLC. (2003). e-Meetings ROI Analysis: Premise Hosted vs. ASP Hosted [White Paper]. Retrieved http://208-96-234-210.static.cimcoisp.net/files/white_papers/E-MeetingsROI.pdf.

Newsgator Technologies. (2009). Delivering ROI with Social Computing [White Paper]. Retrieved from http://www.newsgator.com/webinars/2009/roisocialcomputing.aspx.

Friedman, Thomas. "It's a Flat World, After All." New York Times 02 Apr 2005, late ed - final: Sec 6; Col 1. Print.

Kelly, B, and Marty Parker. (2009). The Compelling Case for Conferencing: How Conferencing Can Help Organizations Improve Business Outcomes While Reducing Costs in Challenging Economic Times [White Paper]. Retrieved from http://download.microsoft.com/download/0/8/3/0839AB32-2EE5-4CB8-B488-32639F9EC969/The_Compelling_Case_for_Conferencing.pdf

McDonald, Dennis. "The Justification of Enterprise Web 2.0 Project Expenditures." Dennis McDonald's Blog - Managing Technology 2006: 11. Web. 13 Mar 2010. <http://www.ddmcd.com/managing-technology/the-justification-of-enterprise-web-20-project-expenditures.html>.

Asay, Matt. "62 percent of IT projects fail. Why?." Cnet news 21 Mar 2008: 1. Web. 13 Mar 2010. <http://news.cnet.com/8301-13505_3-9900455-16.html>.

(n.d.). Retrieved 2010, http://en.wikipedia.org/wiki/Rate_of_return

 

Other Resources

 

CDW Business Case

 

Introduction 

Accomplished sales people must be able to manage their customers, maintain a competitive advantage in sales strategy, and effectively manage daily operationBalanceing between these demands requires a certain type of individual with sound skills as well as a grasp of the business. With the help of SPS this is easily obtainable at CDW.

 

CDW is a leading provider of technology solutions for business, government and education. CDW helps their customer to achieve their goals by providing their technique advices and product they need

Sales Productive Suite (SPS) is  a  application that has become an important part  ofthe CDW’s sales system; this application  is being used as a customer database, an order taker, a personal directory, an order manager, etc…. the only challenge is that a legacy software application is still in useing by many of the employees.

CDW has decided to implement  the SPS tool with new incoming sales account manager classes. Forty people where hired in the spring of 2008. 20 had access to SPS and the other 20 were still working on the legacy tool. We will demonstrate the difference in the ROI selection.

 

Staging

Due to the very  aggressive sales goals, the sale/reps managers are required skills at managing both short- and long-term strategies through a team averaging 20 account managers. As a excellent markering target,CDW had experienced tremendous growth over the last few years. However, the important processes for sales management had become straggle and in need of fixing.

For guaranteeing the business working well, the  initial role out of SPS was viral; CDW chose not to affect the entire sales force, by allowing older account managers to use the legacy software application. CDW start focusing on testing SPS application in order to make new employee obtain first-hand experience and is no longer training sales reps in Zorro. Theterm at CDW has dedicated time and resources to SPS programs such as:

 

 Plays and Programs which are designed to empower Account Managers with timely, relevant, and actionable strategies to position with customers, provide  a proper solution and lastly a new hinge to talk with customers and offer value as an Account Manager.

 

Tasks are connected to the things employees use every day such as customers, products, orders, quotes, and your teammates.In this case, the employee can allocate and managethe proper resource via team cooperation and customer tags, also  In addition, tasks can lay groundwork for much of future work. .

 

Drop Ship which  will be an enhancement to eliminate the pre-population logic for Microsoft Open License and to add an edit check on the Authorization Number to warn the user when they use a number that is about to or has expired.

 

Business Impact Stage

Although the new application still need to be enhanced and many of the company’s sales managers explain and oppose at managing short and long-term strategies, training the sales managers is a critical path for success in implementing.

In order to improve the new application can impove working efficiency better, there are three areas to attention, First, the role of the sales manager needed targeted training materials, which were based on current job requirements by using SPS.Second, the organization needed a pipeline for sales opportunies . Lastly, an internal analysis uncovered the need to enhance the effectiveness of the sales account managers population as a whole.

 

To fix each of these problem areas, a team was formed to bring consistency to the  sales rep role and enhance the impact of the sales account manager. This was the creation of the SPS program. Because of the size of the project, teams were broken into two primary concentrations: account manager productivity and Sales account manager Development. Both teams worked in tandem throughout the process to ensure success.

 

Evaluation

According to the business principle, provide the proper tools will fully promote the employee’s productivity. In CDW fully utilizing the SPS will propel a high level sales manger enter a higher level.Below is an example of a scoring card to measure the success of the program:

 

Importance

CDW Growth Strategy

Prioritization Criteria

Metric to use

2

Capture Greater Share of Wallet

Impact on customer spend

Improved Customer TTM

Increased Revenue

4

Expand Customer Base

Market Penetration

Increased Market Penetration

Quotes by Customer

5

Grow Addressable Market

Market Creation

Creation of new profitable markets

New Customers, by industry/vertical

3

Optimize S&M Model

Sales and Marketing Productivity

Increased Revenue

Increased Marketing Impact?

1

Provide Unmatched Customer Experience

Customer Impact

Improved Loyalty scores

7

Better, Faster, Cheaper

Project Investment

On Time, On Budget

Increased Operating Income

6

Drive Market Advantage through Coworkers & Culture

Knowledge/Experience advantage

Coworker engagement

 

N/A

Technical Difficulty

Improved Architecture

Improved IT Productivity

Improved Knowledge

 

N/A

Project Benefit/ROI

Baseline vs. actual (cost & benefit)

 

The sales organization selection team focused on the assessment, selection, development, and on boarding of programs in SPS for account managers. The process has provided the organization a consistent, predictable process with transparency and accountability.

After identifying these of two kinds of sales reps, we can learn about that it is unreasonable to let existing rep learn the new application, when they had not had specific development interventions in the past. The purpose is that building the sales rep not  only have high performing , but also help them with the skill and tool to excel at expanding the market and customer retention.

 

ROI 

To date, two critical processes have been tackled and a third is in design. Respectively, these processes are pipeline/forecasting process, annual planning, and go-to-market strategy.

 

Recognizing sales people required targeted development efforts to increase their results, the program was created to focus on selection and development of future sales reps and the development of processes, systems, and skills of currently practicing account managers. The program now incorporates objective and subjective evaluation based on high performer characteristics.

 

Out of our test group of the forty employees, we saw unexpected results. The test group that used the legacy tool made 50% more phone calls and also made 50% more orders than the group that used SPS. Although, the group that used SPS had more talk time and less orders but the dollar values of those orders were 200% more profitable in addition to more revenue than the legacy system users.

 

SPS users were equipped with more information and became solution sellers versus transactional sellers.

 

Raw Data for the first 6 months of the program, ROI was calculated as Net profit divided by total investment:

 

Group 

Time Period 

Total Calls 

Talk Time 

Number of Orders 

Dollar Amount 

Gross Profit 

ROI % 

% Difference 

SPS

January

28000

800hrs

950

$300,000

$35,000

1.17%

0.33%

Zorro

January

32000

700hrs

1000

$250,000

$25,000

0.83%

 

SPS

February

22800

700hrs

1000

$350,000

$25,000

0.83%

0.20%

Zorro

February

30400

650hrs

1200

$200,000

$19,000

0.63%

 

SPS

March

21000

700hrs

1000

$450,000

$50,000

1.67%

0.83%

Zorro

March

29400

650hrs

2000

$250,000

$25,000

0.83%

 

SPS

April

20000

700hrs

1500

$750,000

$100,000

3.33%

1.33%

Zorro

April

41500

650hrs

2500

$500,000

$60,000

2.00%

 

SPS

May

26000

700hrs

5000

$1,500,000

$150,000

5.00%

3.00%

Zorro

May

28000

650hrs

2500

$500,000

$60,000

2.00%

 

SPS

June

20000

700hrs

3000

$700,000

$70,000

2.33%

0.33%

Zorro

June

41500

650hrs

2500

$500,000

$60,000

2.00%

 

 

 

 

 

 

 

 

 

 

 

 

 

  

Total Rev 

Total Profit 

Total ROI  

 

 

 

 

 

SPS Group 

$4,050,000 

$430,000 

14% 

 

 

 

 

 

Zorro Group 

$2,200,000 

$249,000 

8% 

 

 

 

 

 

 

 

 

 

 

 

*Cost of Total Investment $3 million to Implement SPS

 

 

 

 

 

CDW's picture of success includes the expectation the company will be perceived as having the most knowledgeable and responsive experts in the industry. This directive has lead to a significant investment in employee development. As a result, the sales force is expected to bring in above-market results. 

 

Comments (14)

jeneesaunders@... said

at 6:57 pm on Jul 13, 2010

I love the Chapter overall, it shows you all put plenty of work into it.

jeneesaunders@... said

at 6:56 pm on Jul 13, 2010

This is one great read. I would have liked to see a little more spacing in between diagrams. This will make them stand out more. It will also make for a less cluttered chapter.

Christina Martin said

at 8:01 pm on Jul 11, 2010

Suggestion: I would provide double spacing where bulletted points are addressed. This would make for an easier read. Definintely need double-spacing where references are regarded. Enjoyed reading up on this topic. Great content provided!

Christina Martin said

at 7:57 pm on Jul 11, 2010

I totally agree that it is important to implement a business case for implementing a groupware project. Regardless of time constraints that have to be met, this is a priority that should be met first above any other objective or project determinent. So many times businesses rush in and short-cut the critical paths towards a successful implementation of a groupware project based on meeting time constraints or cutting out costs associated with developing a business case. In the end, the company definitely loses either way it goes. For example, the implementation may have ended up successful, but the goals and objectives of the business are not aligned with the actual system capabilities.

Matt Opheim said

at 8:16 pm on May 31, 2010

The first thing that I notice with this document, is that you have several ways of identifying lists. In one section you have bullets, in others, numbered lists. When you do your format cleanup, I would recommend you find one style, and make it consistent in the whole document. That way it does not look cobled together.

Qasim said

at 4:00 pm on May 25, 2010

Good Read, hard to understand your title headings form other highlighted topics. Good citations, Need a better understanding in ROI how that is being calculated. Other than that I liked the business case and it serves its purpose.

pat said

at 7:53 pm on May 24, 2010

I think so to take away the chapter objective- it is good but is different from other chapters.
The introduction is pretty good, I like the way you mentioned the satistics. Can you mention what is ERP stand for (in the introduction)
Almost in the end of the chapter, it seems the topic "Writing the Business Case" is repeated. Is there any way to skip the first one?
All in all, the over all content and format is very nice.

pat.

NKUMRA@GMAIL.COM said

at 6:12 pm on May 24, 2010

The material is great and the chapter flows well, however there are a few things that could be done to improve the chapter as a whole.

- Formatting could be worked on a bit. Some subtitles look larger and stick out more than the titles above them. This seems to be a bit confusing.

- The information is great, however, I would suggest it goes a little to directly into the subject. This could confuse the reader depending on their level of understanding. The information seems very technical in some areas, and somewhat difficult to understand for someone who would not have much of an IT background.

- The graphs are great. I would suggest adding more, especially since the text sounds a little more advanced than other chapters.

Jeeri Reddy said

at 5:19 pm on May 24, 2010

- Take out the Learning objectives (as a class we decided not to do this)
- "Identify Stakeholders and Business Case Audience and Form the Business Case Team" needs to be broken down into two different sections and expanded.
- Please include the formula for ROI
- "Business Impact" needs to be expanded to talk about busienss stratagy, logic and goals (long term and short term). Also needs to differentiate the effects between large and small companies

frank95@... said

at 12:44 pm on May 24, 2010

What I really liked about this chapter was that I couldn't tell where one person's edits ended and another one's began. It really flows nicely. This was very thorough and very well written. One thing I would suggest is perhaps adding ERP to the glossary. My company has an ERP system so I understand what it is and how it works, but prior to being implemented I wouldn't have known what it was at all. I noticed above where it was noted that there was an image that would not copy over. Here are the steps I followed to add images. First upload the image to the Chapter folder under "Pages & Files". Then go to the Chapter Wiki page and edit the page: Click the 'Add Link' control, Select "PBWorks file" from the select list, Select your file from the list. It should appear after that.

rbaird2000@yahoo.com said

at 12:14 pm on May 24, 2010

First and foremost, very well written.Intro:

I was having difficulty in determining what where the main sections of the chapter and what the sub-sections of the chapter, and I feel this may have had more to do with the pasting into HTML format than the actually writing. Is the big red sections suppose to be the main points? I am mostly asking this because I am on the QA team and I want to make sure that all teams will have roughly the same format.

(Spelling) ERP application, such as Oracle,

Mary Remington said

at 7:48 am on May 24, 2010

General Notes
This is the best chapter I’ve read so far! Everything is clearly stated in a tone that would be understandable to any student or practicing manager. The team did a great job of explaining terms and provided examples where necessary. It reads as if only one person wrote it, which is exactly as it should be. Great job!!!

I would like to get the opinion of the other groups regarding the learning objectives. I think they are beneficial.

I like that there are clear suggestions on how a business case should be developed and who should take on certain roles.

Images need to be uploaded first via “Upload Files” in order to be added to a page.


Introduction
Please define ERP in case there a people reading the document who are not familiar with the acronym.


Determining the Current State
In regards to ROI, note that there are additional ways in which a company or team can gain ROI other than monetary, like retention of qualified employees or increased knowledge of a project. Since these all end up resulting in a monetary value at some point, this may or may not be worth mentioning.


Quantifying Benefits and Risks
I can see here that the non-monetary ROI as mentioned above is noted in this section under “soft financial”.


Determining Groupware Options
When evaluating “relevant application options”, I am interested to know why Gartner (or other source) finds that stakeholders should be considered first before employees and collaboration requirements.


Determining the Evaluation Criteria and Weightings
Are the 7 criteria from Osterman ranked by order of importance? If not, a non-ordered bulleted list might be a better option.


Writing the Business Case
I like that the team did a small recap of the steps that should have already been completed before writing the business case.

This seems to be stated in an indirect manner, but it may be good to include metrics by which to measure the success of the initiative.

Mary Remington said

at 7:48 am on May 24, 2010

I have separated my comments below by giving each section the same header name as it pertains to. If you have any questions feel free to let me know. - Mary Remington

Mosa Sallam said

at 1:09 am on May 24, 2010

I truly think that this is the most valuable reading I have read in this course so far. You’ve done wonderful job citing the resources, fulfilling every single aspect of building a business case and providing a real world’s business case – CDW.
All in all, except some formatting here and there, especially the red titles, you guys have done a wonderful job.

You don't have permission to comment on this page.