“Problems flow from issues such as inadequate training for users and computer coding that isn’t a suitable match for the “discretion” required to manage complex Ontario Works, and Ontario Disability Support Program (ODSP) files”
As in the product did not fit the need. The problem is that the real customer is not the Ontario government, but the end users who use a system on a daily basis.
“If you’re a code jockey and you’re trying to write code for a new system, you need a yes or no answer”.
Coming from someone who probably does not code. There are ‘If then ..else ,,,else ‘ or ‘case when’ . Sure blame the coders, though they did not design the system. Case after case when a system fails is that the people who actually have to use the system are the last ones who are consulted. Top down system development. We have compliance this and compliance that. Standards from here to there. Usability? Not so much.
Training. Telling users how to do their jobs. I admit, I have witnessed situations where users did not know a [ from a { from a hole in the ground. And yes, even ‘”what is a browser?”. But for most people the software they use should not require extensive training. Going from Word 2003 to 2007 was a change. Using Windows 8 included 2 weeks of foul mood, but it did not require extensive training. In my “expert” opinion, most end-users know how to do their jobs and are open to anything that will make their work easier. After a week or so and faster if their input in the UI design is taken into account.
Testing is done by ‘Business Analyst – QA’. Test cases, not by people who use the system from 9 to 5. Involve real users from day 1 or as soon as something that you can look at on the screen is available. That does not necessarily make them part of the development team, but yes, every week they will have x number of hours looking at the new system (as it is developed). Your average end user is busy and does not want to be a testing guinea pig. So bribe them. Buy them lunches. User interfaces will change, and so will attitudes of users. Major lesson learned after a manager and myself designed a retail sub-system. One of the users looked at me and said something like “this is a piece of shirt”. The database behind it was actually very good. All I had to change was the user interface.
Ensuring software runs mostly bug free, does not mean it is user friendly. Users for let’s say Word are too numerous to identify. Users for a specific system in a specific company or ministry are more specific. Let them test the system. Working and useful are not the same thing. To be useful a system has to work, but a system that works is not necessarily useful.
Depending on the size of the company there are 2 to 3 types of testing. The 1st is done by the coder. Like ‘yes the program compiles and it produces numbers’. The 2nd is a QA analyst. Not every company has them. 3rd the end-users. They will tell you if the UI works for them. Training works if it shows the users how to get at the information they need. Use cases are great for testing robustness, to see if the software can actually help users do their jobs, not so much. When in doubt ask an end-user.
And as a complete aside. Even after the most minute, insignificant, minor, 3 second change that could not possible go wrong. Test.