As this blog entry is connected to my thesis topic, I think it only fair that I start with news about the final stage in my doctoral studies - the viva exam. It would be more accurate to write 'start with the lack of news' - the administrator of the doctoral programme informs me that the external examiners are very busy and that he has yet to fix a date for the viva. Onto a case in my company which I would have liked to include within the case studies presented in the thesis - although it's too late for that. Maybe I can bring it up in the viva as an example of how not to deploy an enhancement.
The CEO decided a few months ago that he would like certain departments to keep time sheets, showing on what specifically they have been working on (i.e. the number of a project, or the number of an engineering change) as well as including more general information, such as participation in meetings with customers or training. One can understand his point of view: it might well be that we are spending more hours on these activities than we are budgeting for, or to paraphrase Peter Drucker, one can't manage something without measuring it.
The task was passed on to the CFO, my manager; she along with the network administrator and I looked for programs which manage time sheets. Specifically we were looking at the sort of program that lawyers, accountants or architects would use to record billable hours. My first idea, that the external programs in use could manage time, was a dead end. Whilst Microsoft Word keeps a record of hours during which a document is open, the engineering programs that we use do not have this functionality. We found a few programs with which I played: these programs led me to believe that there is a continuum of approaches. At one end, there are programs that are geared to recording working hours (when a person clocks on or off) and that the task management was bolted on afterwards. The other end has a very programmatic database approach which was much more to my liking, but also twice as expensive as the work hours program (no names). I had also considered creating a module in Priority to handle the time sheets, and seeing the database approach strengthened my position.
I could already see that whilst the work hours program was easy for the end user (there are interfaces for the web and for mobile phones), it would be problematic to create the initial tasks. The CEO presented several requests which could not really be achieved using this program; they could be approximated but not really to the depth that he wanted. The database program had no external interface: it's a program that has to be installed on each user's computer.
Even before I had started work on a specification for a Priority based program, it was clear that there were certain advantages in using Priority: it's a known technology, it's flexible, it's already installed and it's (essentially) free - there would be no marginal cost in using a new module, provided that I wrote it. A further advantage is that several of the tasks could be created automatically as a result of events happening within Priority, such as the opening of a new project. There are also disadvantages, which basically boil down to the requirement to having Priority open at all times in order to have automatic time recording (i.e. Priority knows and can record the current hour when a button is pressed); this requirement would not be met for one group of users.
After receiving the go ahead to prepare a demonstration program, I spent several hours over one weekend working furiously on the module. Every now and then I would take the dog for a walk, during which I managed to solve problems that had arisen as well as considering new ideas. I showed the module (via Teams) to the CEO and CFO, from which more requests arose, which I solved over the following days. It would be accurate to say that there is a lack of fit between the interface required and the paradigm of Priority forms; I would say that I managed to obtain about 95% fit.
Then we showed the module to representatives of the two groups who would initially be using it: the engineers and the planners who interface between the salespeople and customers on one side and the engineers and production on the other side. I had predicted in advance that their reaction would be negative and I was not disappointed. Whilst they understood what the CEO stood to gain from the module, from their point of view it was 100% overhead which they could do without. Even after I explained that most of the tasks would be opened automatically and that the user interface was extremely simple, they were still adamant in their opposition.
As a test, I defined a few tasks for the CEO who barely uses Priority; after five minutes of training, he was able to report that the module was extremely easy to use. Of course, the ability to extract data in any form conceivable goes without saying. I have yet to hear anything from the other users who were supposed to test the module.
Why was I not surprised that the users would be against using the module? Because from their point of view, the perceived value of the module is not even zero, it's negative. Quoting my thesis, the Technology Acceptance Model (TAM) is based on four components, all based on the individual: perceived usefulness, perceived ease of use, the individual's evaluative judgment of the IT system and the individual's motivation to use the system (Davis, 1989). I can easily imagine that at least the first two components of the TAM would receive negative scores; some of the users (especially their managers) are strong users of Priority so at least the third component is positive. I imagine that their reaction would be even stronger if we tried using an external program.
Quoting the abstract of the thesis, "the research shows that companies that develop a tested framework for deploying enhancements are able to reap the promised benefits and so improve their business performance. The research also shows that user resistance is a major problem that has to be overcome in order to achieve a successful deployment". We managed to complete the first two stages of the seven stage framework, viz. the identification of a misfit (stage 1) and the preparation of a technical specification that defines the advantages that would accrue from the enhancement, the disadvantages and the financial cost (stage 2). We floundered on the third stage - obtain the signed agreement of all stakeholders on the specification, involving senior management wherever necessary.
I haven't heard any more on the topic of time sheets for the past few weeks, probably because almost all of the participants in the last Teams meeting on this subject are also involved to some extent with a much more important project, including the reception and installation of new equipment in one of the factories, the problems with getting technicians from Italy to install the equipment, and software interfaces (including a program that I wrote that receives a file from a design program then builds appropriate parts and a BOM based on the data).
A final quote from my thesis: there is no attempt to assess the economic validity or benefit of specific enhancements; there is no comparison between enhancements that provide economic value and those that merely satisfy whims. Does this proposed enhancement really provide economic value or is it a whim of the CEO?
No comments:
Post a Comment