Towards a distributed management model

Two boards run BiomedTown (BT): the City Managers Board (CMB), which comprises only personnel of the institution operating BT (B3C) or of its parent organisations (CINECA, or IOR). Currently this board is in change of both strategic and day-to-day decisions. However, with the activation of the distributed management model, we plan to transfer to the Building Manager Board (BMB) the responsibility for the day-to-day operations.

As BiomedTown becomes a large community run by a distributed management model, it is necessary to ensure that changes to every element of the web site do not produce unexpected damages, loss of services, or simply a reduction in the efficacy. To this purpose, we propose a formal process to be adopted for each modification that can be perceived by the single citizen. Such process is based on the classic change management workflow:

Requested: Anyone can request a change. A request-a-change link should be added to the main page, which exposes a pre-compiled message form to the webmaster. The webmaster is responsible of collecting these requests, rank them, and bring them to the attention of the BMB. Independently from this any Building manager can post a request for change to the attention of the BMB. Usually if the change is significant, the board will ask the requester to produce a preliminary costs-benefits analysis on the requested change.

Approved: the BMB runs the business and controls the allocation of the available resources therefore, it must approve requests for changes and assign a priority for every change. The CMB oversees the decisions of the BMB on a silence-is-agreement basis. However, BMB approvals might be overruled by the CMB if they change is not fully compatible with the business model or the best practices under which BT is run.

Planned: planning a change involves discovering the scope and impact of the proposed change; analyzing the complexity of the change; allocation of resources and, developing, testing and documenting both implementation and back-out plans. Need to define the criteria on which a decision to back-out will be made. Planning is made by the webmaster in collaboration with the requester; if during the planning new unexpected elements emerge, the webmaster can unilaterally take the request back to the BMB for further assessment.

Tested: Every change must be tested in a safe test environment, which closely reflects the actual production environment, before the change is applied to the production environment. The backout plan must also be tested. At the end the webmaster will produce a test report on the change, that will be made available for scrutiny to the BMB members; whenever possible the webmaster should also make available the change in the test environment to BMB members for further scrutiny.

Scheduled: when testing is completed the webmaster submit to the BMB a report that include the testing results, the production plan, and the back-out plan. The production plan details how the change will be made to the production environment, when, and under which conditions. The back-out plan is a strategy with which the change can be rolled back if major unexpected malfunctioning emerge after production launch.

Communicated: Once a change has been scheduled the webmaster must communicate it to all citizens. Beside general communication, usually with a BT message sent to all citizens, the webmaster will have to ensure that the change information reaches those citizens that are particularly affected by such change.

Implemented: At the appointed date and time, the webmaster implements the changes according to the approved plan.

Documented: All changes must be documented. The documentation includes the initial request for change, its approval, the priority assigned to it, the production, testing, and back out plans, the results of the BMB board critique, the date/time the change was implemented, who implemented it, and whether the change was implemented successfully, failed or postponed.

Reviewed: The BMB board should hold a post implementation review of changes. It is particularly important to review failed and backed out changes. The review board should try to understand the problems that were encountered, and look for areas for improvement. If not differently agreed, changes should be reviewed one month after production launch.