|This Part 4 of a multi-part post on the setup of an Information Management program, you can start the series with Part 1 – Information Management Program Setup.|
An operating model for an information management program is a diagram that depicts the major roles or role groups within the program and how decisions are made within the program. The operating model describes how an organization operates across business, information and technology domains.
Operating models are key artifact for new information programs or information transformation programs. The model describes what is important for the program and the drivers at each level of the program. Developing an operating model requires input from executives sponsoring the program, business stakeholders and technology leaders.
The six segments of the operating model frame that I develop for programs are:
Data Management and Architecture
Line of Business Solutions
Infrastructure and Operations
Maintenance and Support
The image below is sample depiction of a program operating model.
The operating model does not necessarily translate into an organizational structure, but it does describe how the roles and role groups cooperate and collaborate within the program context. The operating model is a tool in the dialogue between business and IT.
The most effective information management programs are programs that are initiated or sponsored by executive leadership. I would hesitate moving an program development project ahead if executive sponsorship and funding has not been secured for a program. Executive leadership and sponsorship is integral to getting the next level of the operating model developed, Steering Committee, and for long-term viability of the program.
A program steering committee is made up of the key stakeholders for the program across business and technology groups. The steering committee is responsible for the overall governance of the program. It may spawn sub-committees to govern specific program topics, capabilities or initiatives. Most information management program steering committees should be weighted toward business stakeholders over technology stakeholders. The steering committee should ensure that the program is directed to solving business problems, seizing business opportunities and driving towards a business that is information driven.
The program office is responsible for the management of the program, it is typically responsible for organizing and running activities across the program and reporting to the key stakeholders in the program. The Program Office typically organize and run the steering committee meetings, coordinate any governance councils activities and manage the financials for the program.
Other key responsibilities for the Program Office include:
Change Management – is the practice of assisting in the transition for current state to future state. This normally includes training users on new processes, policies and solution functionality. The Program’s Change Management function works closely with the Portfolio Management concerning timing of solution releases.
Communications Management – is the practice of producing consistent and targeted internal and external communications related to the program --- it is the marketing arm of the program.
Portfolio Management – is the practice of managing the programs portfolio of projects. Portfolio Management works very closely with Solution Delivery’s Release Management function to insure that projects remain on track and that cross dependencies are not jeopardized. Portfolio Management coordinates both horizontal (data, services and infrastructure) releases with vertical (line of business) releases.
The three functions above must work very closely, in small programs this functions may be filled by on individual, in very large programs there may be a team for each function.
The Solution Delivery segment of the program is where data and services are married to form line of business solutions. A brief description of these functions is included here, a very detailed post for each of these functional areas is forth coming in future posts.
Data Management and Architecture – is responsible for the acquisition, integration, quality and structure of data for the program.
Platform Services – is responsible for the supporting technical capabilities for the program which may include the extract, transform and load (ETL) tools, data publishing interfaces and reporting tools.
Line of Business Solutions – is responsible for assembling data and leveraging the platform services to create business solutions. Business solutions are typically reporting and analytic solutions, but may include data entry and data management capabilities.
Solution Delivery must be a well oiled machine in order to deliver business solution that achieve business value in a timely manner. Again, I will deep dive on this segment of the program in future posts.
Infrastructure and Operations:
I have combined Infrastructure and Operations functions into one mainly for convenience in talking about the functions with the program. In the next post we’ll talk about the organizational model for the program where these functions are often separated, but it all depends on the organization.
Infrastructure – is responsible for the hardware, core software and networking components for the program. This function will work very closely with Solution Delivery to ensure that the technical infrastructure can handle the workload to meet defined service level agreements (SLAs) for line of business solutions.
Operations – is responsible for the running and monitoring of the solutions within the technical infrastructure. Operations is responsible for managing the solutions within to meet there defined SLAs.
Maintenance and Support:
The final role and often forgotten role is a program is Maintenance and Support. Maintenance and Support is responsible for supporting the users of solutions produced by the program. Maintenance and Support is often forgotten within a program design and Solution Delivery is left to support the platform services and line of business solutions produced. This is typically not the most efficient use of resources and can jeopardize the delivery of new solutions. Support should be handled by a separate function away from Solution Delivery.
Maintenance – is responsible for break/fix and patch releases to solutions.
Support – is responsible for handling user incidents, triaging incidents for the program.
Maintenance and Support is key to having a well oiled program, without it smooth agile solution delivery is difficult to achieve.
|The series continues with Part 5 – Organizational Model (coming soon)|