By Andre Griffith
A couple of weeks ago, I overheard some students of the University of Guyana discussing the absolute nightmare of registration, standing in line for hours trying to get into courses for the coming year. My own experience using an automated registration system as a new undergraduate nearly two decades ago was relatively painless. For me, registration was at most a 20 minute exercise accomplished from the comfort of home, or from anywhere where I had access to a touchtone telephone.
I therefore considered writing about the need for modern systems to reduce the sheer hassle of interacting with officialdom in our republic but considered the issue of UG registration in and of itself to be largely peripheral to the issue of IT in business which after all is supposed to be the central concern of this column. I was however provided an opening of sorts by the Honourable Minister of Education who announced his intention to have an online registration system in place for the university “next year”.
With this announcement we are given the opportunity to examine the delivery of significant public projects in general, but from the particular perspective of an information technology initiative. I venture to suggest an examination of this sort could give us a sense of the pace of our progress toward establishing the general national framework that is necessary for our firms to become competitive. Apart from modern systems for e-business and e-government, this framework also encompasses fundamental components of infrastructure such as a reliable electricity system, transport such as the Berbice River Bridge, and a whole host of other initiatives aimed at laying the foundation for an efficient and competitive state. My main concerns are, our capacity for project management, our ability to truly understand the magnitude of the task at hand, arising from which is the question of the reasonableness or otherwise of the expectations that we set. I remember many years ago, the confident public pronouncement of a senior public servant that construction work for the Berbice Bridge would start before the end of that year.
At the time that the announcement was made, tenders had not yet been invited, and a quick check in my mind from an engineering and financial perspective, of the number of things to be completed in order to facilitate a start on construction, suggested to me that the public functionary had been poorly advised. Construction started at the very least two years subsequent to that confident announcement but let us now move on and look at some of the major things that will have to be done in order for the online registration system to come to fruition at the UG.
The first thing to note is that “next year” does not mean one (1) year given that UG has had a late start of about two months. This means that Mr Baksh has actually only ten months at his disposal to deliver on his promise. Unfortunately, in my experience working in the public sector and para-statal organisations, the Honourable Minister’s available time is further reduced by about four weeks given the impossibility of getting most serious work done between mid-December and the beginning of the new year, added to which there are about ten public holidays between January 1 and August 1 inclusive which must be blacked out when preparing the project calendar. Thus in one pessimistic paragraph, the available time has been reduced by twenty-five per cent.
In this nine-month period we have to do a number of things in order to arrive at the stage where each student of the university is able to register for every course that he or she needs to take for the academic year 2009-2010. The preceding statement is a first pass at a high-level statement of functional specifications for the online registration system. Let us see at a very superficial level, what some of the major components of such a project might be, and assess whether it is reasonable for us to expect an online registration system “next year”.
First off, adequate funding has to be secured for the implementation of this system, whether it will be developed as a bespoke system or customised from an existing registration package. Funding has to cover the cost of the software, hardware, consulting fees for the developers/ vendors and some amount of dedicated human resources i.e. a project team, in the University of Guyana. The exact amount committed would have to be informed by some reasonable estimate of implementation costs, and of course by what the Honourable Minister of Finance is able to spare from the treasury failing which a donor programme can possibly be negotiated. There is a finite time involved in researching total implementation cost and negotiating the budgetary allocation. This finite time comes out of your nine months.
Formation of a Project Team – Although the natural tendency will be to have persons within the system take on the responsibility of implementing this system in addition to their normal duties, this course of action is not advisable in this instance. For anything other than the most trivial of projects, dedicated resources should be assigned since operational responsibilities inevitably take precedence over project implementation leading to schedule slippages. The time taken to identify dedicated personnel is again finite and is lengthened if those dedicated resources have to be recruited from outside of the organisation.
Functional Requirements – The functional requirements have to be developed. This is where some of the most serious threats to the project schedule can arise from the point of view of IT projects. This stage formally and specifically sets the scope and here the devil is in the details. Take for example our original statement of functionality which was that each student of the university is able to register for every course that he or she needs to take. Reasonable as a high level statement, but at the stage of functional specifications we have to refine it. Consider, the case where there are only forty available places on a course, but the demand for the course exceeds the places available. What business rules govern who gets precedence; it could be first come first served. On the other hand, during my undergrad years, first year students had precedence over all others for first year courses, which meant that if you failed or deferred a course, you had lower priority of accessing that course next time around. Point is, when it comes to detail which is what functional specs are about, every student will probably not get every course that they need! Will you allow students who are indebted to the university to register? This is another business rule and there are many others that will have to be hashed out, written down in black and white and handed to the programmers to implement before next year.
With respect to the schedule, it is important to note that the persons who know these rules are not the IT specialists. It is rather, the Registrar and his or her staff that is the authoritative source of this information. Not only will the development of the system specifications have to be scheduled around the availability of the Registrar and his/her staff. As a matter of good practice, the Registrar as the “owner” of the registration system ought to be the person in the University on whose authority the functional specifications are approved and issued to a vendor for implementation. Just to make matters interesting, the university has recently advertised for someone to fill the position of Registrar leading me to believe that this most important position in this process may not be filled at this time.
I have seen first hand how vacancy of a person in a key position, at critical times can affect the final quality of an IT system from the point of view of its fitness for its functional purpose. Another interesting requirement is how many users will be allowed to access the system at a time? Absent any administrative mechanisms, thousands of students will be trying to access the system at the stroke of midnight on the day when registration opens either crashing the system OR making access so slow and frustrating that confidence in the system is destroyed. One simple way of handling this is to have persons become eligible for registration in sets based on some criteria as opposed to everyone at once.
System to be selected – I am not sure whether the intended collaboration with UWI extends to use of a UWI system by the University of Guyana or whether it is just limited to using UWI’s expertise in guiding the implementation. If it is the latter, then we are faced with the spectre of a public procurement process for both the hardware and the software together with its associated implementation fees. Take it from me, procurement of goods and services alone can eat the entire nine months and more with ease.
Development/Customisation of System – During this phase, a new system is either built from scratch or an existing one is customised in accordance with the rules specified in the functional specifications. During this phase, as a “real” system is in front of the user, it is inevitable that in some cases, the specifications were interpreted incorrectly, the specifications did not clearly state what was intended and a number of other situations that lead to an iterative process of refinement before arriving at an acceptable prototype.
In implementation, among other things, we start to load the system with the student records. These records must include at a minimum, the bio-data of the students, their academic history (which tells whether they meet the pre-requisites to register for certain courses), their financial status (if this is a barrier to registration) and any other data that is necessary. The information may or may not be held electronically by the university. If not, a significant data entry operation has to be mounted to input records for the thousands of students. If the data is held electronically, it has to be extracted, scrutinised, and sanitised before loading into the new system. We must also set up usernames and access rights for the university staff and for those same thousands of students together with their access privileges. Training in the use of the system is a must as is development of easy-to-follow user manuals that can be used especially by new students. An interesting case is that of the first year students. The source of their information is the admissions system, which has to interface to the registration system since there would be no prior record of these students.
The above is just a broad brush view of an outsider trying to assess whether he should believe that we will really have an online registration system “next year” or more correctly in about nine months time. I usually go through a similar process whenever I hear official announcements of significant projects in whatever field. In my opinion, the Honourable Minister has set himself an extremely aggressive and challenging deadline given that for simplicity’s sake, I have not even made any allowance for the routine and not so routine snafus. This looks more like a two-year effort to me but, given that Mr Baksh has indicated that he initiated this process some two years ago, some of the above may have already been done and he may be much further along in this process than I think. However, we will talk again in nine months time.
