The comments of Customer Group 4 with regards to the project are listed below. In general, the project was quite successful in many respects. Indeed, this system gives us a good starting point in the quest for a system to adequately replace our poor paper-based systems.
Comments associated with the various areas of the project and the final product are listed below:
The interface was very clean and very efficient in our opinion. Consistent, feature-buttons were well labelled and placed in consistantly the same place, greatly aiding our users. The patient information layout was very flexible. It allowed us to search on a variety of fields, and the substring search should prove useful at times. Searching for information was simple and very intuitive. The use of the keyboard for shortcuts, especially tabbing between fields was nice at times.
In examining the user manual in comparison to the actual program we saw at the demonstration, we noted several inconsistencies. In general, these revolved around screens showing the interface of the project. In some pictures, buttons shown in the user manual are not in the final version we saw demonstrated. In other pictures, inconsistencies existed between the layout of text boxes on the screen. We would suggest that at minimum the pictures of the interface be updated in the user manual. Seeing completely different pictures of the interface would cause a great deal of problems for our users.
Another improvement to the manual should be having to do with the locking / unlocking functions. If these are so visibly important to the program at this stage of development, then some mention of them should be made in the user manual.
Section 2.1.4 through section 2.1.6 we believe should be altered to either remove these from this stage of the manual, since these functions were not delivered, or at least some note should be made about them being future implementations.
The remainder of the manual was quite well done. It was clear and concise in most places and the steps listed in the user manual to accomplish certain tasks fit well with those demonstrated in the lecture.
In accordance with the contract, we as customers should not really be making any comments at this time. While the contract was hardly vague in its coverage, it did specify that the customers will not "bitch or whine" about the supplier's work. We consider this phrase extremely unprofessional, and if sufficient time had been available to fully read the contract at the time of its signing, we may not have signed it. We feel it is in the best interest of this project that the customers get what they want and need out of the project. Hopefully, interactions between the customer and supplier will solve any difficulties and inconsistencies involved, and thereby benefit the project as a whole. The comment that we should stop "bitching and whining" clearly goes against these interactions. This tends to give the impression of the suppliers as intimidating and unprofessional in some respects.
Regarding the design process in general, we felt it generally failed in two respects. Firstly, there was inadequate communication between the customer and the supplier over the course of the project. Given the time constraints involved in this project, and committments people had to other groups, this is somewhat understandable. We do feel that as a customer group we were approachable however. Certainly, with the misunderstanding regarding the maintenance function, as an example, a message sent to our group could have easily clarified this problem. We also feel the supplier should have asked more open ended questions in an attempt to eliminate these misunderstandings.
Secondly, we feel as a customer that several of our requests, although agreed to by the supplier, fell on deaf ears at times. Noting the high degree of function specified above by ourselves, and again agreed to by the supplier, it is disturbing in some ways to see that they have not been implemented.
The presentation was generally well done. We appreciate the honesty laid forth by the presenter regarding functions that had not been implemented by the group, but were supposed to be. The presenter spoke in a clear manner and certainly attempted to answer our questions. Screen shots were clear, and the speed of the functioning program was very good.
The group leader also presenting did seem to be quick to jump to the future enhancement defense when certain questions were asked for the group. This defense was somewhat inaccurate in certain areas, as is specified further below.
We were disappointed that the demonstration did not include any mention of error checking involved in the program. A great deal of error boxes were specified in the user manual and in the overall design document, and some demonstration of them would have been useful to at least see their format, and whether or not error messages were comprehensive and educating to the user.
The assumption that the waiting list feature would not activate until the hospital was full is good for most situations. However, the supplier did specify they would provide a way in which the patient could be assigned to the waiting list for an operation at some future time in section 2.1.5 of the functional specification. We feel that both these wait list features are among the more important features of this system. We anticipate that many wards in the hospital will be continuously full and we will require a waiting list feature to help manage the hospital effectively. It was requested for this system by the customer.
It was specified that each patient coming out of a recovery room should have a recovery room assigned to him or her. This was to be delivered by the supplier, and it was therefore dissapointing to see that it was not present in the demonstration product.
It was specified by the customer that the ability to generate reports, especially reports on the patient situation was required. In this demonstration, no reporting method seemed to be included in the program. This is something that will need to be added by the supplier.
Advance Notices go hand in hand with the waiting list feature. We would like an advance notification system to help our staff avoid costly errors in scheduling. We agree that this function should be implemented in future versions of the program.
The way that you have described the maintenance feature is essentially the way that we would like the administrative section to work. We need to be able to add, delete and change the way the wards are laid out, which is as you have specified. This system just needs to be implemented.
Another, concern is with the way that you have chosen to lay out the hospital. The way that our documents have specified the layout is that there will be a ward number, a floor number, and the number of rooms. We believe the generalization you have made should be changed to reflect this. This will allow us to better keep track of the hospital.
We realize that you plan to add security features at a later date, but we would like to emphasize that it would be nice to be able to restrict access to functions and layouts based on the level of the person logged in.
We understand the difficulties inherent in designing a fully automated scheduling system. We appreciate the fact that your system will check for potential conflicts in scheduling. This will help our staff a great deal in developing schedules.
Another concern involves the locking and unlocking of fields. Personally I found the continual appearance of the dialogue box quite annoying. If this is a result of being designed in Access, then the problem would be rather severe. If not, it would be much preferable to simply have some other indicator to show which mode the fields are in. This would probably include the disabling ("greying-out") of buttons and fields that had no function in that mode, as well as some other form of display (saying "search mode" at the top of the screen, for instance) to make it clear what mode is in operation. This also could be as simple as changing the window header.
Since there seemed to be at least one problem, resulting in some sort of
syntax error, when a record was saved in search mode, this is quite strongly recommended before some computer-phobic staff member is to use the system.
Given that our users do not generally want anything to do with Microsoft Access at their level of use, we would find it very helpful if the Microsoft Access toolbar were removed and hence that the program essentially runs by itself in a window. We appreciate that the program was completed in Access, yet we do not find it necessary to tie our users to Access itself at all times.
Apart from these concerns, the system appears to meet the needs of the hospital very well, and appears to be a very stable system.