EDRM System Implementation Toolkit

Implementation plan

There is general consensus that if you are implementing a corporate system you need to develop a phased implementation plan. Even assuming that you have an agreed classification scheme and a core set of system functions to roll out you still have a number of labour intensive tasks to perform for each administrative department/school and each section/unit prior to them implementing the system. These are detailed in stage two on project management. You also have to make a business case for implementation and if your budget is limited you will have to procure the solution in phases with stop points or review points at the end of each phase.

The preferred approach is to break the implementation down into phases. The following is a model plan:

Specification Phase

Phase one is a desk research activity carried out between the project team and the preferred supplier. Essentially it will involve taking the requirements provided in your Statement Of Requirements document (see stage six) and specifying exactly how these requirements will be met by the supplier using their software and services. The result will be a specification of the core solution to be provided and demonstrated and tested in phase two. Crucially it should also include a specification of how the system is to be tested in phase two and the criteria for acceptance.

Model office/prototype

Phase two is not a live solution. It involves the supplier implementing the core solution in a test bed or model office scenario. This usually involves up to six PCs on a dedicated network with scanning and printing facilities. It serves two functions.

The first is that it provides a facility where the project team can test the system with the supplier and agree whether it meets all the specified requirements or not. Out of that will come some changes to be made by the supplier to correct areas where the initial solution did not meet the requirements or some changes requested by the user to add functions not requested originally or modify functions.

The second is that it provides a facility where the solution can be demonstrated to users prior to the pilot in their unit or the roll out in phase four. The options here usually relate to how big is the model office, how long should it run for and how many users should be invited to use the facility?

Pilot/s

The third phase is the pilot phase. The obvious questions include:

• how many pilots do you run?

• which areas do you run them in?

• how many users should you support in a pilot?

• what contingency do you provide to the users?

• how long do you run the pilot for?

• how do you move from pilot to live running?

You have tested and accepted the core functions provided for the model office. The objectives of the pilots are to test the solution in a live environment and this will include user acceptability tests; tests relating to the integration of the system with the business applications used in that area and tests on the performance and resilience of the system.

The first question is how many pilots to run. Anything more than one will involve a considerable amount of effort to manage - particularly if the two pilots are to run in parallel. On the other hand if you are implementing a corporate solution you want to test the full range of functions and if you run two pilots you are likely to test more functions than in one.

The second question is which areas do you run them in? If you opt for two pilots you could select a structured process such as a subset of student registration that involves integration with the existing student registration system and business process management and a publishing application that involves several staff collaborating on the drafting and approval of documents prior to publishing them on a web site etc. You should select reasonably high profile areas and areas where the relevant stakeholders are keen to be involved and ready to set aside the resources needed to manage a pilot.

The third question is how big should the pilot be? If you are running one pilot then you should aim to support at least 40 – 50 users. If you are supporting two pilots you could reduce that number so that the overall total is still 50 or 60 users. If you involve many more than that then the resources required to train the users and prepare for the pilot will slow the project down.

The fourth question relates to the contingency you provide to the users. Put simply this means if we ask a department to work on a pilot for six months do we instruct them to stop keeping paper records or records in shared drives during that period and only to keep one set of electronic records on the new system. If we do then what contingency do we have if the system does not perform as the users must keep some form of records during that period? If we do not then how do we resource the fact that we are asking staff to keep two sets of records over a period? The answer for most education organisation s will be that our tests in phase two have proved that the system is stable and maintains the required records. Hence for the pilot we rely on the new system for our records and do not maintain duplicate record keeping systems. If problems do arise then we have to have a contingency plan.

The fifth question is how long do you run the pilot for? This depends on how big the pilot is and what services have to be delivered in order to make the pilot work as discussed in Service Requirements section below. If you need to integrate the system with a business administration system and/or scan and digitise the contents of some current folders and/or model, redesign and automate some business processes then you may need to allow six to nine months for your pilot. If it is a smaller standalone application then three to six months would be more realistic.

The final question to consider is how do you move from the pilot to live running. It is not desirable to run a pilot and then, even though it is successful, stop the pilot for a period and revert to old ways. So you should plan the pilot on the basis that it is the first part of a phased roll out into that section/department. Often you will run the pilot for one team and then roll it out to all the other teams and then go on to other departments/faculties. As for the model office so for the pilot you should have established in phase one the acceptance test and the criteria to be applied and then you can plan to roll out as soon as the test has been passed.

Initial and Secondary Roll Out

The fourth and fifth phases are the roll out phases. You have tested the solution at the model office phase and at the pilot phase and it has been accepted. You now need to consider how far and how quickly you want or will be allowed to roll the system out and where you need to build in review points and possible stop points.

This is where you can get a pay back from stage two and stage three. If you carried out very detailed project planning and got all the stakeholders involved and set up user groups including users from each faculty and each administration department then you will have the basis on which to construct a clear roll out plan based on which users are keen to be early adopters and which would prefer to be later in the roll out for sound reasons. If you carried out a detailed information gathering stage and reviewed all the functions, activities and transactions and the user requirements and the IT infrastructure and the volumetrics then you will have all the additional data you need to decide whether there are technical or logistical factors or process requirements which will influence the preferred roll out plan.

The third and most important factor that will influence the speed with which you roll out the system and the stop points you need will be your budget and internal resources. No matter how strong the business case you produce in stage five, it may be that budget constraints mean that you cannot spend more than a certain amount each year and hence you will need to phase your roll out accordingly. It may also be that you have identified a strong business case in central administration but are finding it more difficult to make the case for EDRM in the faculties. In that case you would make the first roll out phase central administration and then would put in a review point and have the faculties as an optional second roll out.

As indicated in stage two, supporting the implementation of a corporate EDRM solution is a labour intensive process. You need a change management plan to ensure that users are fully informed about the project and the roll out timetable. You need a training plan to ensure that all users are trained prior to their allotted roll out slot. You need to ensure that you start surveying the user records well in advance of the roll out date so that you have an agreed plan for whether you are starting day one forward or going back and loading any existing electronic content or paper content. You need to have agreed the folder metadata for that unit and the classification codes and the retention data.

For each department you need to decide whether you can roll out to the whole department or break it down into sections/units. You need to have agreed whether each department is simply being provided with the core system solution as specified in phase one and tested in phase two or whether they have a special case that has been accepted for additional customisation or for additional services. Examples may include modelling, redesigning and automating business processes specific to that section; backfile scanning of paper content; loading of existing electronic content. The more additional services you allow at this phase the longer the roll out will take.

The best advice is therefore not to commit to a single roll out. As part of stage two and stage three you should aim to identify the organisational structure and the total number of departments in scope of the project. At this stage you should decide whether you want to break the roll out down into two or three or more phases and then categorise each department as belonging to one of those phases. In order to make the business case you need to decide how many phases you will commit to initially in the ITT.

If you have more than two roll out phases then you will need to adjust the table above to show three roll out phases etc.

Corporate Application Development

Phase six assumes that you have rolled out the core solution to all Departments within the scope of the project. All key staff and certainly all administrative staff will now have access to the system and will have access to their folders on the system and will be saving their documents and e-mils etc into those folders on a regular basis.

This is then the time, after a suitable pause for reflection and congratulations at your achievement to consider now using the system to automate and streamline some key corporate processes.

These are processes which either could not be addressed or could only be partially addressed prior to the system being fully rolled out. Now that it is you can take it for granted that staff have access to all the data and content they need to conduct their work. That is a simple statement but it has enormous implications. There is scope at this phase for achieving a whole new range of business benefits as we explain in stage five.

Examples of corporate processes that could be modelled and streamlined at this stage include policy making and committee administration; the processing of invoices; student administration; collaborative research applications; capital project management; curriculum development; correspondence and complaints handling etc.

Many of these applications will require tight integration with existing business administration systems and some will best be developed within business process management software provided with those applications. The EDRM system will then simply act as a slave system controlled via the business administration system. All the content will be held on the EDRM system and at key points in the process the EDRM solution will be instructed to retrieve and display the required content.

Most of these applications will be partially addressed during the departmental roll outs but there will be limits set to how far each application can be fully automated until all staff have access to the system.

Clearly phase six will be a major phase. One issue is how much of phase six you try and specify in your statement of requirements. We review that issue in stage six of the toolkit.

Project Closure and Support

This refers to the final phase where you have rolled out the solution to all staff within scope and you have developed all the corporate applications that you require. The main activity then becomes closing the project and supporting the solution, conducting all the system administration tasks and training new staff etc.

Of course you will need support for the system from phase two onwards and the options for support services are reviewed in Service requirements below. Here we are talking about the requirement to close the project and start to support the solution like any other IT application within the education organisation. The project closure process is reviewed at a high level in stage two under project management and in more detail in stage nine of the toolkit.