Friday, June 24, 2016

Project Delivery Process D730

D730 - Identify Human and Organisational Issues

SIIPS Delivery Processes (D).png

DEFINITION

SIIPS D730.pngAssessment of the required change in terms of people and organisation.  Identifies peoples’ skills and behaviours, their resistance to the change, lack of skills, willingness and abilities.  A formal approach may be used.

SUMMARY

For a new system to work effectively, organisational structures and individual responsibilities and behaviours within the business may need to be adapted. This is a result of a combination of system characteristics and management decisions on how to optimise the use of these characteristics, as documented in the implementation papers.
Since the requirements definition, selection and implementation decisions are usually made by a combination of project team resources and user representatives, only a limited number of people will be able to understand and explain how much change is required. To prepare all users, this knowledge will need to be documented so that it can be shared.
Initially changes will be documented in terms of changes to the system features and business processes.  For staff and management to prepare properly however, this needs to be translated into changes for the departments involved (e.g. purchasing, accounting departments) and changes to the different business roles within departments (e.g. purchaser, accounting clerk, etc).
This translation requires the involvement of representatives of all relevant departments and business roles.  Once the changes are identified, these representatives will need to assess the likely reactions of the people affected by these changes.
When the user population is small and the number of business roles affected is minimal, the representatives will be relatively well informed to assess the likely reactions of their staff and peers.  For larger projects the assumptions made by the representatives will need to be checked as part of the plan to activate human resources and organisational change (D740 - Implement change management programme).

PATH PLANNING GUIDANCE

Optional - used where there are several users affected by the project.

DEPENDENCIES

Prerequisites (Finish-Start):
  • Delivery Approach Definition (DAD) or similar definition of overall required business solution.
Prerequisites (Finish-Finish):
  • aspects of the design affecting the human organisation or procedures
Dependent procedures (Finish-Finish):
  • D740 - Implement change management programme

RECEIVABLES

  • Delivery Architecture Definition (DAD) or similar description of overall business solution.

DELIVERABLES

  • Organisational Impact Implementation Paper

TOOLS

  • Various questionnaires
  • Examples: Required behaviours questionnaire

DETAILED DESCRIPTION OF TASKS

Document how the new system affects the current ways of working.
To scope the impact of the new system on the organisation and the people, a comparison of the current ways of working and the new proposed way of doing things needs to be made. During the detailed design work the new ways of working will have been documented in the respective implementation papers.
This information needs to be gathered and compared to a description of the current situation. This will enable the project team and the users to understand the scope of the change, identify the hurdles to overcome and propose and implement actions to support this transition.
To summarise the system changes and how they affect the business processes, it is useful to consider the following categories of findings:
  • changes in data structure, eg
    • more information held on customers
    • new structure of the article numbers for inventory management purposes
  • data ownership, eg
    • on-line input of client data by the salesforce instead of forms sent to a central department.
  • changes in processing, eg
    • real-time updates instead of batch processing
    • weekly information cycles instead of monthly processing
    • changed ways to calculate unit costs
  • responsibilities for transactions, eg
    • billing done by regional offices instead of by the  central billing unit
  • available information, eg
    • daily exception reporting of late billing

Identifying relevant business roles

To communicate effectively with managers and users involved, the information obtained will need to be restructured to reflect their perspective. This will allow them to understand how the system affects their department, their colleagues and themselves and will help clarify what support each person will need and what actions he will be responsible for.
This requires answers to the following questions:
  • who uses the current system data and who will use them in the future?
  • who owns and maintains the data at the moment and who will do so in the future?
  • who is involved in /affected by the processing differences?
  • who is and who will be responsible for transactions?
  • who uses the current information and who will use the information in the future?
This should lead to the identification of four groups of people:
  • people currently using the system or system data, who will no longer be involved. This typically occurs when manual controls or input processes are replaced by system features;
  • people currently using the system or system information, who will continue to do so;
  • people who are not using the existing system or information, but will be asked to do so once the new system is implemented;
  • people indirectly affected by the changes in the system elsewhere in the organisation or even outside the organisations (e.g. suppliers being asked to submit more detailed invoices, customers receiving a different breakdown on their bills).
Usually different business roles can be distinguished within each of these groups: i.e. subgroups of people with a similar set of responsibilities, data access and ownership, transaction and information responsibilities.  For example purchasers will have different responsibilities from people requesting goods to be ordered.

Defining the impact per business role

For each of the relevant subgroups identified, an overview of the following is needed:
  • what changes for the people in this business role
  • what benefits will these people experience
  • what will cause problems or resistance to overcome
  • how the changes affect the current performance and reward systems
It can be useful to make a distinction between the minimum system requirements without which the system will not function at all and the business requirements which are basically choices made by management as to how the system should be used. This distinction will be appropriate if the change load is high and there is a perception that not all changes can be implemented straight away and priorities need to be defined.
Documenting for each relevant business role the points listed above enables the project team to start the user wide communication needed to sell the system to the users. It will enable the user management to scope the implementation effort and the roll-out support they will need to put in. How to involve user management and set-up the right roll-out support structure is documented in D740: implement change management programme -ie plan and activate human resources and organisational change.

Involving the right people

The process of identifying the business roles and documenting the likely impact on each of these groups of people requires:
  • a sound understanding of the new system and its effect on the business organisation, and
  • a thorough knowledge of the current ways of working.
The former is usually the expertise of the project team and is in most cases well documented as part of the design work. The current ways of working are usually less well known within then project team. To increase this knowledge, the following avenues may need to be explored:
  • organisation charts, procedure documentation, job descriptions
When using this documentation checks will be needed to ensure that the documents are not out of date:
  • Involvement of user representatives on the project team.
Although this usually is a good starting point, the risk that their information is only of limited value increases with:
  • the size of the organisation
  • level of decentralisation
  • length of time users have spent as members of the project team and the in-depth knowledge they have acquired of the new system and the proposed ways of working
  • involving additional users
These users preferably do not become project team members but are a source of information on the existing business roles. Only when the impact on a business role justifies full time responsibilities will it be appropriate to bring additional people within the project team to help prepare the roll out of the system for this specific group of people. For example, some system implementations require a new function to be created, which justifies a specific project activity consisting of defining this function, the corresponding profile, identifying resources and training and educating the selected people for their new responsibilities.
It is essential at this stage of the project to involve more and more people. Whereas the decision-making process is usually centred around a limited number of user representatives, the process of identifying the human and organisational issues will benefit from a wider participation by the users. A minimum requirement will be to have involved at least one representative of each business role in understanding and documenting the impact on the business role.  In D740 (Implement change management programme) further mechanisms to widen the user involvement are documented.

Documenting the Issues

The human and organisational issues are usually documented in the environmental Implementation Paper - Organisational Impact.  This would identify and set out the needs for change in organisational or human behaviour.  It would then examine the various options available and recommend an approach.  Details of how the changes should be achieved would be stated.

This would normally be detailed in terms of the approach to be used but not the detailed action plan.  Detailed actions are planned and undertaken in Process D740.

No comments :

Post a Comment