Sunday, September 11, 2016

Investment in upgrading, or the aquisition of a major, Application Software Suite

Application Software Investment - Business Case

Overview:

A major component of any Investment in upgrading, or the acquisition of a major, Application Software Suite is the development of a clear understanding of the payback on the the investment.  Regardless of what an Organisation is focused on - re-engineering business processes, implementing a new application system or restructuring an organisation - cost will be involved.  The question that is being asked more and more often is “What will be the return for this expenditure, or investment?”.
In the past, many organisations were sold on the basis of managing the cost component of a project.  If companies did address the benefit side of a project, it was often based on an intuitive understanding of the benefit which might be achieved based on a given change.  From a cost perspective, methodologies became key enablers of “project cost containment”.  In fact, the development of methodological approaches to re-engineering, upgrading or replacing information systems development was often driven by the need to have a defined, manageable process for implementing change and managing the cost side of a project.  As methodologies matured over time, many began to focus on the benefit component of change.  Methodologies often included the implementation of business performance measures which are used to communicate the impact of the change to the organisation.  However, what was still missing was a clear understanding of, and agreement on, the goals and objectives associated with the defined changes.  A business case is the technique which develops this understanding.
This ability to deal with projects from an investment rather than a cost containment perspective becomes even more significant as the scope, potential impact on the organisation, and the cost of projects increase.  For example, consider a re-engineering process which is focused on streamlining a company’s warehouse management processes.  The scope is reasonable limited, the project is typically short in duration, and the cost to the company for external consulting support and internal resource commitment are limited.  From a benefits perspective, the company might typically look to a reduction in cost, but as the project was limited in scope, the expectation would likely be modest.  In effect, the business “risk” is relatively low, therefore the need for a clear cost benefit is reduced.  Now take the same company, and consider the impact if the objective was to re-engineer the customer value chain, including re-engineering customer facing processes, implementing sales force automation technology, and establishing customer “partnerships”.  The time required to design and implement the changes is significantly greater, the required commitment of resources is much higher, and the potential impact on the business goes beyond simple cost reduction, and begins to drive improvements in revenue growth and asset management.  In this example, the business “risk” becomes much higher, therefore the need for a clear cost benefit is significantly greater.
Consider another example.  In the 1970’s and 1980’s, many companies implemented integrated application software such as MRP II systems.  These systems were typically site specific, and impacted business functions associated with the planning, scheduling, production and shipment of products.  The impact on the organization was reasonably high, and the cost could easily be in the millions of dollars.  However, even with this level of expenditure, business cases were often ignored, or developed at a high level, with a focus on subjective, non-quantified benefits.  Compare this scenario to the situation today for a company that is planning to implement an integrated enterprise wide system.  Not only is the scope much broader, often touching all components of a company’s value chain, but the costs can easily be $20-30 million or higher, depending on the geographic and organizational scope of the implementation.  Suddenly, there is a much greater need for a clear understanding of what the return on this level of expenditure will be.
From an external consulting engagement perspective, a business case has several critical objectives:
  • It is a vehicle to document and gain agreement within the organization on the value of the business benefits associated with change, including changes such as business process re-engineering, information technology implementation, organization alignment and restructuring and business rationalization (products, facilities, etc.).
  • The business case is used to establish achievable targets for business performance improvement associated with the change.
  • It is the technique used to develop the perspective of the project as an investment, rather than a cost, by relating the implementation requirements to quantified business benefits.
  • It is an approach which provides the organisation with a clear payback/return on investment profile.
  • The business case establishes the business performance baselines and goals which are used to evaluate and drive any change.
There are several critical points within these objectives.  First and foremost, developing a business case impacts how the organisation views and deal with change.  Rather than looking at projects as a necessary cost of doing business, or something that is the latest rage or trend, companies begin to view and evaluate projects in terms of what they will specifically return to the organization for the money spent/resources committed.  Second, once this payback is understood, performance measures can become true drivers for change. Clear goals and expectations can be shared and communicated to the individuals within the organization who will be responsible for implementing change and achieving the performance improvements.
Third, it is people within an organization who implement change and achieve identified benefits. Therefore, identified benefits need to be agreed to, and achieved by, the organization.  Note that the purpose of a business case is not to set “stretch” goals which individuals have little hope of achieving.  Rather, the business case is focused on setting realistic goals which people in the organization agree with and which they are measured against.  Viewed from this perspective, the development of a business case can be seen as a process which engages and mobilizes the organization.  It is the process which defines the expected impact of an implementation or change, and establishes the measures which the organization will use to monitor and measure success.
Finally, as achievement of benefits will be measured and monitored.  it is important to ensure that the business case contains quantifiable benefits.  This is not to suggest that all benefits contained in a business case must be quantifiable and measurable.  Business cases often contain stated benefits that are either unqualified or intangible.  The table below suggests typical benefits which could be components of a business case:
The challenge in developing a business case therefore is not to identify only those benefits which can be quantified and measured, and which will result in a bottom line impact on the organization’s P&L or balance sheet.  Rather it is to identify and document the benefits people believe will be achieved, regardless of whether they are quantified or unquantified, tangible or intangible, while at the same time keeping the focus on those results which will yield true improvements in business performance improvement.
SIIPS Business Case 1.PNG

Inputs & Outputs:

The business case process typically parallels an analysis process, be it Business Process Re-engineering, Software Selection and Implementation or Enterprise Technology Planning and Design.  Each of these methodologies/project approaches has a specific perspective on what project work looks like.  It is up to the individual who is designing the specific project plan to determine where, when and by whom the necessary business case development work will be done.
As an example, the following chart outlines business case development activities and their relationship to a high level Business Process Re-engineering project methodology.
SIIPS Business Case Analysis.PNG
The financial baseline development is the financial equivalent of developing an operational or systems understanding of the current environment.  The opportunity quantification is the translation of improvements in operations based on re-engineering and/or systems implementation into expected financial performance figures.  Finally, the business case development itself takes the investment documented in the implementation plan, the financial benefits documented in the previous steps, applies timing and risk assessment factors, and presents the implementation project in agreed on financial terms.
There are several critical interface/integration points throughout the project.  The financial baseline is typically very broad, as it is important that the team understand the financial performance of the company from a holistic perspective.  The financial baseline also provides the team with a focused understanding of where the areas of high potential dollar benefits are.  The second step, Opportunity Quantification” is dependent on input from the “As-Is”, To-Be” and Opportunity Identification steps.  Opportunity Quantification ensures there is clear agreement on the identified opportunities, the assumptions around the impact of achieving the opportunity, and agreement on the calculation of the financial benefit.  Once these three areas are clear, the development of business benefits becomes a reasonably straight forward mathematical calculation, starting with the financial baseline and applying the agreed on calculation.  In addition, the assumptions provide the basis for identifying when the benefits will be realized.
The final step, business case development, requires input from the implementation planning activity.  Implementation planning delivers the cost component of the business case by identifying the resource requirements and the expected timing of the respective requirements.  As noted above, the specific format of the business case will often be dictated by the client specific requirements for project authorization and approval documentation.

Business Case Development

As noted above, the development of a business case typically parallels  traditional analysis and definition activities.  As such, the business case development is part of an analysis as opposed to a stand-alone effort.  However, when developing a business case, the following are typical  activities which need to be integrated with process and/or technology definition work.

Activities & Tasks:

  • Identify/confirm the required financial justification required by the Organisation (for the specific type of investment anticipated)
    • Review Organisation’s justification requirements with client project sponsor and others as required (i.e., financial organization)
    • Identify key client decision makers who will be involved in final approval of results delivery or implementation project
    • Review previous project justification documentation
    • Develop straw-model business case framework (ROI, IRR, payback, etc.)
    • Develop straw-model executive review and authorization process, including timing, sequence of communication, individuals involved, etc.
    • Review/validate business case approach with client management team (i.e., Executive Steering Committee)
  • Develop/confirm Organisation’s financial baseline
    • Gather necessary financial baseline information, including expense ledgers, performance reports, balance sheets and other available reports as required
    • Develop summarized financial information baseline as required
    • Develop financial profile consistent with the agreed on business case framework (for example, if ROI is to be used, the team can develop a current ROI model as well as a “proforma” future ROI to indicate the magnitude of change which would be required)
    • Review and validate current financial baseline with appropriate client personnel and executive management team members
  • ¸Develop and review required business opportunity charts with project team members
    • Develop opportunity chart, highlighting information required, standard documentation format, types of calculations, etc.
    • Review opportunity charts with project team and gain agreement on use of charts within the overall project work plan and the due date for completed charts, by project work stream/sub-team
  • ¸Develop opportunity charts
    • Complete opportunity charts during the course of key analysis and definition tasks; information includes such items as:
      • Opportunity description
      • Analysis findings which support the validity of the opportunity
      • Calculation used to derive the opportunity
      • Assumptions around the opportunity and/or calculation
      • Measurement which would be used to evaluate the achievement of the benefit over time
      • Confidence level
  • Validate opportunity information with appropriate Organisation’s personnel
    • Review and validate opportunity information with client individuals who will be accountable for delivering the defined benefit(s)
  • Consolidate opportunities identified by the team consistent with the defined business case format
    • Consolidate opportunities as required
    • Review and validate with team members
  • Pre-present business case information with decision maker(s)/Executive Steering Committee
    • Plan and schedule one-on-one review sessions with appropriate decision maker(s) and/or Executive Steering Committee
    • Conduct pre-present sessions
    • Update and re-validate opportunities and business case with appropriate client personnel as required
  • Develop and present final business case to client decision maker(s)/Executive Steering Committee
    • Develop final business case documentation
    • Present to client as planned

Deliverables:

  • Agreed on financial justification documentation
  • Financial baseline
  • Validated opportunity charts
  • Validated business case

Suggestions:


  • A critical success factor is to ensure that the business case is developed consistent with the Organisation’s required justification  process, including the required justification methodology, information granularity, presentation format, etc.
  • Develop and confirm the financial baseline very early in the project.  It provides the team insight into the potential magnitude of opportunities based on current financial information, which in turn directs analysis activities.  It also helps identify additional financial information gathering which will be required.
  • Lay out the opportunity charts early in the process.  This will allow the project team to begin filling them in as they go through the analysis, rather than waiting until the end of the analysis to try to recreate the required information.
  • Pre-present business case information in individual sessions with decision makers and/or Executive Steering Committee members.  If any changes are recommended/suggested, be sure to reconfirm with necessary individuals prior to the final presentation
  • The final presentation of the business case should be a group confirmation of the benefit associated with subsequent implementation efforts.
  • An effective business case development typically requires that one team member have accountability for it’s development.  This individual also develops the financial baseline and the opportunity chart format, and assist team members in completing and validating opportunity charts with client personnel.

Thursday, September 1, 2016

Delivery - Brief Delivery Process Path

Delivery - Brief Delivery

An accelerated form of delivery relying upon a simple approach.  This can be appropriate where there is a small scope, a non-adversarial organisational environment, and relatively straightforward technical options.  Typical criteria for adopting this approach might be:
  • the scope of the project should be small (e.g. one business area, one business line),
  • a small group of empowered people is available within the client organisation who can make the decisions in the project,
  • there is strong pressure to meet deadlines that could not be met with a full approach as in Delivery - IDDI.
In many cases, the same processes are involved, but they are conducted in a simpler way.  For example, Brief Implementation Papers are used in place of Implementation Papers - these require substantially less evidence of detailed evaluation and consultation.  The availability of empowered managers to agree and sign off designs and activities generally leads to rapid progression through the processes.

Ref
Process
Optionality
Definition
D200
Agree reviewers and sign-off authority / responsibility
Normal practice
Agree a small, empowered group of authorisers and sign off responsibilities.
D110
Review technical environment and plan installation
Optional - usually required when insufficient detail was included in the Delivery Approach documentation and segment plan
Plan in detail the physical installation of the packaged software, additional systems software, hardware, communications equipment, servers, PCs etc. Note that increasingly this task is performed by the vendor.
D120
Plan, prepare and conduct project team training
Optional - usually required unless whole team have requisite experience in all aspects of the solution.
Normally, team members need training before productive work can commence.  Training may also be appropriate for management and other staff working with the project team.
D130
Install hardware, communications equipment, system software, and applications software as required for development, implementation and live running.
Optional - required when insufficient provision is already available for the project.
Install and commission items required for design, development, implementation and live running.  This includes system environment requirements, e.g. log ons, access security, accounts, budgets etc.  With medium systems this is often performed by the vendor.
D240
Impose issues control and change control
Optional - normal practice where there are several key users and/or several people on the team.  (When no formal mechanism is in use - all changes must still be documented and agreed in writing.)
Issues Control and Change Control procedures must be in place and used.  Changes from the defined requirements, must be agreed before becoming firm in the design.
D150
Define and instigate Project Team responsibilities and techniques for technical support, bug reporting, fixing, supplier liaison etc.
Optional - normal practice where there are several people in the team and the vendor is not represented.
During development there is a need for clear responsibilities to be defined for running and supporting the development system.  For example, who applies bug fixes? Who runs the batch jobs?  Who sets up the security access rights?
D160
Consider, review and plan approach to interfacing and systems integration
Optional - used where there will be significant interfacing or integration.
his process looks at the issues which arise out of the desired levels of integration between separate elements of the overall project and with external systems.  Plans and approaches will be modified accordingly.
D180
Data conversion strategy
Optional - used where existing data will be brought into the new system
A study should be made into the needs for data conversion.  Data availability and integrity is often wrongly assumed during design work. Recommendations will be made for securing data as required.
D300
Prepare discussion papers
Optional - discussion papers may have been identified in the segment plan or may be used to explore any particular issue that arises as the team see fit.
These are short papers covering a particular subject.  They are not formally controlled, reviewed or signed off.  Their purpose is to assist in the process of deciding an issue during the design work.
D450
Design/Prototype - Brief Implementation Papers
Normal practice
Design or define each topic within the project, using prototyping techniques wherever appropriate,  documenting the recommended approach and details in a Brief Implementation Paper (BIP) per topic.
D600
Create detailed specifications for non-Integrated Application Software IT development work
Optional - used where non-Integrated Application Software IT development tasks are involved in the overall technical solution
Define the technical requirements to a sufficient level that they can be used in the detailed design, programming and construction of a component.
D650
Instigate non-Integrated Application Software IT development parallel tasks
Optional - used where non-Integrated Application Software IT development tasks are required in the overall technical solution
non-Integrated Application Software IT development tasks should be instigated as appropriate.  Controls may be set in place to monitor progress, to ensure adequate quality and to ensure delivery will be on time and within budget.
D700
Set up system parameters, codes, structures, etc
Normal Practice
Each aspect of the system’s basic configuration system should be set up in accordance with the agreed implementation papers.  Most basic parameters will have been set during the prototyping.  At this stage the full tables are populated.
D710
Set up screens, queries & reports etc
Optional - as required
Each agreed optional customisation of the system should be set up in accordance with the agreed implementation papers.  Many will have been set during the prototyping.  At this stage the full tables are populated.
D720
Prepare and instigate operators’ instructions, procedures and manual
Optional - depending on suitability of vendor’s standard materials available
Prepare detailed instructions for the  technical operation of the system, including routine and abnormal running, eg security, disaster recovery.  This will normally include operational-standard JCL and the definition of human/machine interactions.
D750
Prepare and instigate User Procedures and User Manual / electronic information
Normal practice
Human procedures should be defined and agreed as part of the functional design work. Manuals or electronic documentation of the procedures and how to use the system should be extracted from the implementation papers and expanded/supplemented as necessary.
D760
Plan, prepare and conduct user and management training and education
Optional - used where user and/or management training is required
Full user training is vital both to the successful use of the system and also to its acceptance and successful take up.  An effective programme should be developed based on the identified training needs of all users and management.
D800
Plan, prepare and conduct User / System / Acceptance and Integration testing
Mandatory
Formal testing must be performed to ensure that all significant aspects of the system are acceptable.  Careful planning and preparation is required to ensure it is complete and comprehensive.  Results must be reviewed and signed off by responsible users.
D810
Plan, prepare and conduct technical tuning and volume testing
Normal practice
The system will need technical tuning to ensure acceptable performance.  Volume testing ensures that full volumes of data and transactions can be accommodated.  Testing should prove that normal loads can be sustained and peak loads can be accommodated.
D830
Define, plan and agree handover / cutover
Normal practice
An analysis should be made of the logistical requirements for changing over to the new systems.  Detailed timings must be considered and agreed.
D860
Define live support mechanisms
Normal practice
Dictate responsibilities for support of the live system and liaison points with the vendor.
D880
Load start up data
Normal practice
All initial data should be loaded.  Includes running of conversion suites and manual data entry.
D890
Validate start up data
Normal practice
Complete loaded data should be validated and signed off by the responsible user managers.
D900
Decision to go live
Mandatory
The ultimate governing body or manager for the project should take the definitive decision to go live.  It must be certain that all vital pre-conditions have been satisfied to at least a minimum level, eg testing, data validation, training, organisation.