Recommended Roadmap for Shared Inspection Management Solutions This roadmap outlines the phases of activities required in order to plan, design and implement a shared inspection management solution. While each phase listed below is critical to the success of a shared inspection management solution project, certain areas of activity may have more or less importance depending on the business and political context as well as economic, regulatory or other conditions. I. Project Initiation 1. Define project objectives. Objectives should clearly define the scope of the project and not be too complex or too ambitious. Specification in later phases should not mask shifts in direction or scope. Objectives may include: Improve effectiveness and efficiency of inspections and inspections processes across more than one inspectorate; Reduce corrupt inspection practices; Improve transparency of inspection practices and accountability to the public; Improve efficiency and capabilities of inspectors; Reduce burden on businesses; and Harmonize IT architecture across inspectorates to yield financial benefits. 2. Identify the key stakeholders (i.e. agencies, inspectorates, ministries, consultants, organizations, business representatives, industry partners) to be involved in the project and their roles and responsibilities as part of the project. 3. Understand how the involvement of the identified key stakeholders may influence the project or present challenges and/or risks to be managed. 4. Understand and map the political, administrative, regulatory, and economic context. Indicate the implications of this context (potentially as opportunities, challenges, and/or risks). 5. Confirm project objectives and scope with key stakeholders. Clearly articulate how the project aligns to other projects, larger programs, and/or reform priorities and initiatives. Potential areas of scope associated with a solution implementation could include: Organizational change / restructuring; Business and/or inspection process analysis and redesign; Identification of standardized practices; and Identification of related reform priorities and/or initiatives. 6. Identify impacts on key staff within the organizations involved. 7. Ensure financial commitment, both for the project (design, development, and implementation) as well as the on-going operational costs. II. Project Organization and Governance 1
1. In addition to understanding key project stakeholders, ensure clear and confirmed roles for owners, users, and providers. Ensure that these roles are filled by authorised individuals in a decision-making body. 2. Clearly identify senior-level project sponsors and a project sponsorship model. Project sponsors should have some degree of ownership over the project and solution. 3. If possible, ensure ownership is formally with one organization, the principal owner. 4. Define project team organization in the form of a project team organizational structure and responsibilities/accountabilities (RACI) matrix. 5. Employ project management methodologies to manage quality and cost (time and resources) management standards and designate who is responsible for ensuring that these are used throughout the life of the project. 6. Define data governance. Do participating organizations maintain responsibility for their own data, or will data responsibility and ownership be centralized? Who is responsible for data produced in work processes supported by the application? 7. Invest the principal owner(s) with responsibility for availability of financial and other resources. 8. Define reporting mechanisms. 9. Define ownership and governance of the solution and its technology after project completion. This organization will prioritize on-going enhancements as well as the potential addition of new inspectorates. III. Project Scoping 1. As part of the pre-design scoping exercise, ensure that project design incorporates: technology components; business and inspection processes and best practices; organization and governance; legal consequences; staff development; and, finances. 2. Understand and articulate, at a high level, the business and technical functionality that will be incorporated into the shared solution. Understand, at a high level, the requirements of the inspectorates and sponsors involved. 3. Understand, at a high level, how current processes may be impacted as a result of the project and understand whether or not changes to inspection processes are in scope of the project. If so, it will be necessary to understand opportunities to reduce process complexity and also achieve efficiencies across inspectorates. Avoid the fallacy that technology can master complexity; oftentimes some level of change is required in order to introduce a level of process standardization. This is often the key to achieving project objectives, especially as they relate to improved effectiveness and efficiencies of inspection processes. 4. Identify inspection process complexity wherever possible. Determine whether or not these inspection processes are in scope for the initiative. 5. Identify existing systems and sources that may be instrumental in helping to reach the project objectives. 6. Identify risks and a risk management plan; allow for contingencies and unexpected opportunities that may arise. 2
7. Build in periodic re-consideration and specification of objectives and actions. 8. Develop and build in an evaluation tool to measure project progress. While evaluation of project progress will take place for the duration of the project, it is important to develop and confirm an evaluation approach/tool as part of project initiation activities. 9. Ensure that strong project management methodologies employed in the Project Organization phase to adequately control scope, budget, and achievement of milestones. IV. Solution Design 1. Present inspection best practices to stakeholders and identify how technology might enable improvement. 2. Understand and document the current state. Business processes, as well as the current state technical environment, need to be understood to enable the definition of the future state. 3. Re-think the inspection processes involved. Do not digitize the processes in their current state as it is recommended to redesign processes in view of technological possibilities as well as efficiency and effectiveness 4. Understand (from key stakeholders, inspectorates and decision makers) the desired future state and what a shared inspection management solution would ideally look like from their perspective. Document the findings these will feed requirements and design discussions with stakeholders. 5. Collect functional and technical requirements from stakeholder groups (e.g. inspectorates and other decision making organizations). Base these discussions on a starting point set of potential requirements in order to streamline the discussions. 6. Prioritize the identified requirements to ensure there is agreement among stakeholders on the level of importance of each piece of functionality. This exercise will also help determine the best approach to developing and deploying the solution, which may require a staged approach. 7. Identify other key systems and sources of data that should be incorporated into the overall solution. These may include systems to identify business entities (e.g. business/company registries, tax management systems, business licensing applications, existing inspection management systems); systems to provide a citizen/business view of the data (e.g. existing e-government portals); and systems to support key processes (e.g. document management, financial management). 8. Decide on use of existing data: will this be needed in the new practice? If so, will the data be made available by data conversion, migration or otherwise? 9. Research available, relevant solutions and decide on the choice of commercial-off-the-shelf (COTS) or custom-built solutions or a mix of these. 10. Decide on the development methodology to follow (e.g. waterfall or agile methods). 11. Develop a technical blueprint that finalizes the solution architecture (i.e. which systems will be used and how they will be integrated). 12. Prototype key functionality to more explicitly demonstrate important areas of the solution and therefore minimize potential confusion from stakeholders and system developers. 13. Design the development project by determining how to deploy functionality. Considerations include: The sequence of system functions and inspectorates to develop and deploy; 3
The use of pilot deployments and a proof of concept approach to gather lessons learned for subsequent deployments; and, The method to solidify project and system development resources by identifying government resources or by determining that the project will be tendered to an external vendor. V. Solution Development 1. Stick to the objectives and agreed upon organization of the project, unless the decisionmaking body decides otherwise. 2. During the solution development phase, keep different project aspects in balance: Technology; Business and/or inspectorate processes and requirements; Organizational consequences; Change management, communications, training and stakeholder engagement; Legal consequences; Staff development; and, Financial consequences. 3. Incorporate these aspects into a reporting format. 4. Ensure that a system design is produced for stakeholders to review and sign-off on prior to system development. This will minimize misunderstanding in the interpretation of system requirements. 5. Consider creating separate development, testing, training, and production technical environments. 6. Ensure sufficient time for system, functional, user acceptance, and quality testing. 7. Enable the decision makers to assess the project s progress through regular updates from the project team. 8. Communicate with relevant stakeholders and enable them to express comments and ideas. VI. Solution Implementation 1. Plan solution implementation as a separate process, following development and adaptation of results. 2. Conduct detailed solution deployment planning with key stakeholders and decision makers in order to guide implementation activities. 3. Plan for multiple iterations of user acceptance testing. 4. Pay adequate attention to: Evidence of achievement of original objectives; and, Data conversion and/or migration (if required). 5. Consider using a soft launch with minimal external communication to provide an opportunity for the system issues that arise to be addressed prior to rolling the system out to a large group and announcing its launch. VII. Change Management, Communications, and Training (on-going) 1. Develop high-level change management plans to identify potential issues and resistance from identified stakeholders and how best to address these areas. 4
2. Develop a clear understanding of the interests of all parties and customize communication and engagement activities to the needs of groups. 3. Communicate during all phases with identified target groups on: Technology; Business processes and change; Organization; and Objectives. 4. Ensure continuous promotion of the solution and its objectives, while avoiding over-kill. 5. Ensure communication is not one-sided, and includes getting feedback from stakeholders. 6. Develop a structured approach and plan to train inspectors as well as future users of the system. Customize these training plans to each specific user group to specifically address their needs. 7. Use training activities as additional opportunities to promote the system and its benefits. 8. Training should cover the changes to inspection practices (for example, the use of risk based planning as a concept) in addition to how to use the new information technology. 9. Consider the use of multiple training mediums including written documentation, videos, class room training, and post implementation support from super users. VIII. Financial Management (on-going) 1. Ensure adequate funding for all stages of the project. 2. In planning, include funding requirements for staff time and the time of other resources/stakeholders. 3. Differentiate between project costs and operational costs. 4. Ensure owners and sponsors have the responsibility for securing financial and other resources for the project. 5. Ensure appropriate contingency is included at various stages of the project. IX. Project and Progress Evaluation (on-going) 1. Insert evaluation activities throughout the various stages of the project. 2. Evaluate with clear functional objectives in mind: what is needed for the project in terms of progress, support and decision-making? 3. Conduct evaluations with different needs of stakeholders in mind. (e.g.: for businesses, results in burden reduction are crucial; political decision makers will be interested in whether efficiency of resource usage is improved; the general public will look at contributions to product safety.) 4. Do not evaluate more than necessary, as this takes time away from other important project activities. The following graphic provides a summary of the detailed Roadmap discussed above: 5
6