Managing Timescales and Progress
Planning is a critical part of your implementation project and devising a baseline plan that is both realistic and achievable is an essential part of managing expectations. If you are working with a software supplier and/or implementation partner they will develop their own project plan to manage its tasks and resources, it will not include all of the additional tasks that the institution will have to incorporate relating to business changes. Therefore, the overall project plan should identify all of the tasks that need to be completed together with timings, dependencies and resources and the project team should comprise both internal and external personnel and be charged with the responsibility of fully implementing the system.
Setting a timescale for a system implementation project is a very difficult exercise and extreme caution should be used. The Risk Management infoKit includes a section on Planning in the Real World and some key issues are noted there. Even at the start of a project, mistakes can be made: "Just because a project has been approved, it does not mean that work can begin the next day. Institutions need time to adjust while priorities are changed and prior commitments discharged. One of the most common problems is that these activities are simply left out of the plan. Assumptions are made such as "in Week 2 the supplier will be on-site to install a test system", ignoring the reality that no internal staff are available to work with the consultants. Even more extreme are cases where complicated contracts must be negotiated or staff or consultants recruited, each of which can take weeks. Ignoring these activities can lead to projects that are weeks behind before they even begin.
Often timescales are set for projects that are impossible to achieve. A common mistake is to set a project schedule tied to the annual business cycle (e.g. start of the financial year) with too much emphasis on long-term objectives and insufficient consideration of the short-term project foundation and initiation tasks. Consequently, any delay, however minor, in establishing the proper foundations for the project or initiating it compresses the overall timescale for the implementation.
Indeed, this is the original tight-rope balancing act. Too much emphasis on project start-up activities leads to paralysis as all of the effort is consumed on planning and preparation, but too much emphasis on short-term tasks leads to short-term progress and long-term confusion.
Although it is referred to above in the context of project start-up activities, major problems can occur if the system is scheduled to go-live on a critical date within the institution's calendar (e.g. the Admissions module is due to go-live on 1st September) and any significant prior activity overruns. The date upon which systems like these are set to go-live are often immovable and institutions will be faced with absorbing the pressure imposed by:
a shortened implementation timescale;
delaying the implementation by a year; or
implementing the system modules in a different sequence.
Whatever the decision, the outcome will be momentous, and this is the type of major risk that must be highlighted at the start of the project and contingency plans put in place to deal with the consequences of it happening. For example, those contingencies must anticipate:
a re-doubling of efforts and resources in the case of a shortened implementation timescale;
the probability of standing-down project personnel and the consequential laying-off of their temporary replacements if the implementation is delayed by a year; and
a re-scheduling of specialist internal and external resources if the system modules are to be implemented in a different sequence.
Another problem that many projects face is procrastination. This is a particular problem in HE, where large projects have long timescales and, in many cases, the schedule may call for a year or more between the start and the first go-live date. Human nature being what it is, dictates that any task not due to happen 'today' is delayed until 'tomorrow'. Everyone has enough work to do to dominate their immediate thoughts without worrying about projects that still have months to go.
Obviously the problem with this is that there are months of work to do in the months allotted and the 'extra time' is only an illusion. Whilst everyone accepts the idea that the project will impose great demands at the time of going-live, the challenge is to induce and maintain a sense of urgency and enthusiasm from the beginning whilst time is available. A definitive approach is to set and continually monitor intermediate milestones and tangible achievements that help everyone to focus for the short-term.
Conversely, a similar problem arises as people begin to focus on specific parts of the system. Large and complex systems are difficult to deal with as a whole and so the work is often divided into pieces. In turn, each team concentrates on its specific area of responsibility, configuring and testing to ensure each function works properly. However, this approach often masks the overall process. It is important to ensure that each process flows smoothly from one stage to the next and, as assumptions or changes are made in one area, they are reflected in others.
The path to a successful implementation is littered with conflicting demands from many quarters. Several compromises must be made along the way and not everyone will be happy with the decisions made. For example, testing, training and performance tuning are obvious areas where, with additional time, more can always be achieved to make going-live more acceptable. However, no matter how much testing is performed, some software 'bugs' will remain in a large system when it goes-live. The only true test comes when hundreds, and perhaps thousands, of users begin using the system in production mode. The same holds true for training and tuning and there is no such thing as too much of either. However, it must be recognised when enough has been accomplished to make the decision to go-live.
