Saturday, December 19, 2015

Functional Design - Software

Objectives:

  • Finalise the functions and reports of the base software package to be used and determine how they will be used
  • Finalise the system enhancements needed to meet any unique needs not available in the standard system and determine how they will be developed

Hints:

  • The primary objective of implementing a new system is generally not more information, but more effective information.  The project team should focus on understanding how and why existing forms, reports and processes are being used, and how the same objectives can be accomplished more simply with the new system.  Implementing new systems and technologies may allow some existing forms, reports and processes to be combined or eliminated.
  • If Consultant was not involved in the system evaluation and selection decision, it may be necessary to gain an understanding of business before designing how the new system should be integrated into the business.  The Functional Questionnaires may be useful in gathering information about operation and functions.
  • Every attempt should be made to adapt the business processes to the standard processing features of the software package and reduce the number of enhancements needed.
  • Organisations should also be encouraged to fully utilise the system’s features and functions, as appropriate.
  • The Implementation Strategy Report developed during the evaluation and selection process can provide a starting point for determining the detailed configuration requirements for the new system.
  • If appropriate, implementation papers for each major system function can be separately prepared and approved.

Steps:

  1. Compare the manual and automatic functions of the existing system and the new system, identify any changes and complete a System Functions Worksheet
    1. Manual procedures and calculations that can be incorporated into the new system or eliminated
    2. Changes to current procedures and methods to take advantage of system features
    3. New functions not currently performed
  2. Compare the reports and inquiry screens of the existing system with the new system, identify any changes and complete a Report & Inquiry Screens Worksheet
    1. Enhancement to standard reports (i.e., transaction, management and control)
    2. Additional reports
    3. Additional data required
    4. Preprinted output forms (i.e., checks, statements, stationery)
    5. Specific parameter settings and run time options of standard package reports
  3. Compare the existing input forms with the new system input screens, identify any changes and complete a Forms & Input Screens Worksheet
    1. Content, format and sequence
    2. Printing EOQs, lead times and reorder points
    3. Storage and distribution
    4. Disposition of existing forms (e.g., use up existing supplies, discontinue and destroy)
    5. Printing method (e.g., in-house copier, outside printer)
    6. Approved suppliers (for preprinted forms)
    7. Responsibility for monitoring quantities and reordering
    8. Control of sensitive forms (e.g., checks, vouchers)
  4. Finalise system controls and audit trails
    1. Source document completion and authorisation
    2. Input validation and reconciliation
    3. Transaction processing and reconciliation
    4. Form, report filing and retention
    5. Backup and storage
    6. Table and parameter maintenance
  5. Finalise system security and complete Security Access Worksheet
    1. Physical access controls to equipment, files, forms and reports
    2. Logical access levels for each system user
    3. Remote access procedures
    4. Access hours and locations
  6. Evaluate implementation alternatives and select approach
    1. Complexity
    2. Cost
    3. Resources
    4. Time-frame
    5. Organisational Impact
  7. Organize analysis and prepare the implementation paper for each system function
    1. Background
    2. Alternatives
    3. Recommended Approach
  8. Review implementation paper with the sponsor and obtain approval to proceed
  9. Complete System Change Requests for any identified system enhancements
    1. Functions
    2. Reports
    3. Input screens
    4. Security and controls

Tools:

  1. Implementation Strategy Report (if available)
    1. System Functions Worksheet
    2. Reports & Inquiry Screens Worksheet
    3. Forms & Input Screens Worksheet
    4. System Change Request

Deliverables:


  1. Implementation Paper (for major system functions)

Thursday, December 17, 2015

Business Case - Business Process Improvement

A major component of any consulting job is the development of a clear understanding of the payback for the investment a client will be making. Regardless of what a client 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 consulting engagements 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 and 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 is 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 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 organisation 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, such as SAP, Oracle or Microsoft Dynamics.  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 organisational 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 a consulting engagement perspective, a business case has several critical objectives:
  • It is a vehicle to document and gain agreement within the client’s organisation on the value of the business benefits associated with change, including changes such as business process re engineering, information technology implementation, organisation 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 client 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 clients view 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 organisation 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 organisation who implement change and achieve identified benefits. Therefore, identified benefits need to be agreed to, and achieved by, the organisation.  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 organisation 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 mobilises the organisation.  It is the process which defines the expected impact of an implementation or change, and establishes the measures which the organisation 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 measureable.  Business cases often contain stated benefits that are either unquantified 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 organisation’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.

Saturday, June 20, 2015

Mobilisation Plan



Mobilisation Plan.png
The “Program Repository” is a significant program management support tool which serves as an “umbrella” document that houses all project planning materials (i.e. contains phase-by-phase descriptions of all activities undertaken during the BPI program). It takes the form of a "live" planning binder to which additional, more-detailed sections (e.g., Mobilisation, Migration and Implementation Plans) are added with each new phase of the BPI initiative.
The “Program Repository” provides a comprehensive account of all decisions relating both to the “what” and the “how” of the BPI initiative. It thus integrates the “technical” aspects of BPI (e.g. assessment and design deliverables) with the “relationship” aspects of achieving stakeholder commitment (e.g. partnership with the organisation, and employee-involvement strategies).
The “Program Repository” begins with the Mobilisation Plan, which relates primarily to the Envision, Focus and Design High Level phases, and is normally developed with the organisation as a result of a CEO and/or leadership team “arousing” process.  While additional planning details are added to the “Program Book” as the BPI program moves through its successive phases, there are two fundamental “shifts in emphasis” during the BPI program.
The first shift occurs while Design High-Level activities are being completed, when the organisation is beginning its migration towards adopting the new way of doing business.  At this point, the Mobilisation Plan is reassessed and updated (based on all current information) and the Migration Plan is developed.  Later, as the organisation completes Build activities, its focus shifts towards implementation activities.  At this point, the Migration Plan is revisited and revised, and Implementation Plans are developed.  As part of day-to-day project management, the three major plans are supplemented through the use of one or more project management techniques (e.g., Plateau Planning, Work Packages).
The diagram above illustrates how the BPI initiative begins with a Mobilisation Plan that is “fleshed out” in more detail as it evolves into the Migration and Implementation Plans.  This process of evolution  reflects the natural movement of major organizational change from an initial idea to concrete reality.

Description

  • The Mobilisation Plan is the first section of the “Program Book”.  It contains a high-level outline of all phases, the anticipated milestones of the project, and an initial detailed description of the activities conducted in the early stages of the project.  The Mobilisation Plan also incorporates an initial employee involvement strategy (or “Change Leadership Model”) agreed by the CEO and the leadership team.

Organisation Value

  • A comprehensive Mobilisation Plan  assures the organisation that all important steps are being addressed.  It enables the organisation to gain consensus and share ownership of the overall project scope, the upcoming phases’ objectives and subsequent activities.
  • The decision on an initial employee involvement strategy, or change leadership model, prepares the leadership team for the challenges of guiding employees through a major change.
  • Omission of the Mobilisation Plan presents a significant liability to the organisation. Without this plan there is a serious risk that the project will not be completed on-time or within budget, or will not be completed at all.  If expectations are not clearly aligned within the organisation, both will fail.

Approach

  1. Review/validate the content of preceding proposals and/or discussions with the client.
    1. In some cases, project planning activities (or a subset of these activities) have been conducted as part of the proposal process.  Where a formal proposal process has not occurred, discussions will precede the development of the Mobilisation Plan.
  2. Discuss with the CEO and the leadership team alternative approaches and strategies for involving people and leading them through the change process.
    1. Visits to/from other organisations to discuss their experiences with large-scale change, and the negative and positive consequences of different degrees of employee involvement, are often highly beneficial.
  3. Facilitate consensus of the leadership team regarding the most appropriate strategy for employee and stakeholder participation.  This step has a direct impact on how the BPI initiative will be,and alerts the leadership team to the necessity of team cohesion and consistent communication.
  4. Create a draft project plan.
    1. For the entire project (end-to-end), elements include:
      1. project scope and overall objectives
      2. preliminary timeline showing all project phase.
    2. For the first phase (or immediate next phase) elements include:
      1. activity descriptions, duration and milestones
      2. specific resources required to complete activities\
      3. dependencies (or required predecessor tasks) associated with each activity.
  5. Review plan with team members to ensure feasibility and obtain commitment.
  6. Review plan with the CEO and/or the leadership team, revise if required, and obtain sign-off to proceed.

Guidelines

Problems/Solutions

  • Keep the project plan simple and crisp.  An overly-complicated plan may cause confusion and frustration for the project team and client organisation.  It should be user-friendly and easy to communicate.
  • If the organisation is unfamiliar with collaborative or participative employee involvement strategies, provide additional coaching and support on the implications of such strategies upon project plans.  As required, adopt different strategies for different parts of the organization.
  • Participative strategies, providing they are well-managed, have the highest likelihood of embedding change in the long term.
  • Use realistic time and resource estimates so that the project plan is a management tool rather than a “straight-jacket”.

Tactics/Helpful Hints

  • Start by identifying outputs on the timeline; then identify tasks and required resources.
  • Identify integration points with other related processes, departments or on-going projects and build relationships into the project plan.
  • Work as closely as possible with the organisation sponsor in establishing the project plan.
  • Use project plans from previous engagements in similar industries and/or companies of similar size.  These are valuable sources for information, standards, etc. during the course of project plan development.
  • The Mobilisation Plan provides an invaluable opportunity to build a robust relationship with the CEO and the leadership team.  It provides the framework and a mechanism for controlling how resources are deployed, and for accurately gauging and reporting on project progress to the client.

Resources/Timing


  • The Organisation Project Manager must spend significant time in developing the project plan to assure that it satisfies contractual requirements, includes all necessary steps, and deploys project staff effectively.
  • The Project Manager needs expertise in managing BPI engagements of organisations of similar size and industry.  It is critical that the manager have expertise in the methodology to such an extent that he/she clearly understands all of the intended outputs, requisite inputs and their interdependencies.