Exposing Best Practises Through Narrative

I found it interesting to follow the course of a development and to see where the concepts embedded in ‘best practise’ arises. Also I find the idea that there is a ‘best practise’ suitable for everyone suspicious, as different business will surely have their own ‘best’ ways of doing things, dependant on their own resources: facilities, money, time, skill sets etc..

Also interesting is the politics behind the development: the idea that some peoples ideas are promoted and others not, why this is the case and how it is decided.

I liked the idea of ‘narrative as performance’. It reminds me of feminist theory in communications which differs from the historically male-viewed idea of science as objective and objectifiable by claiming that it is impossible to objectify a social science and therefore this shouldn’t necessarily be attempted. The researcher is instead considered part of the research and the narrative is treated as a performance to be interpreted, much like this paper does.

How were the interviews conducted? Open or closed questions? Simple things such as tone of voice or body language of the interviewer can subtly influence response. How was this overcome? Was it even considered?

There is not enough detail available in the methodology to enable me to do a similar study without reading further. Why did they use colour coding? How did they apply these codes? How did they verify the authenticity of the participants’ words? How are they sure that the ‘narratives’ were interpreted correctly… the researcher in this case will influence the interpretation because they can only view it subjectively, not objectively. There were three authors – perhaps they all viewed the data independently and then reached consensus of interpretation, but this is not made clear.

That the grant management system was not successful means either of two things:

1. it is not possible to do grant accounting in the way prescribed by the system
2. users are particularly recaltrant about learning the new system, either due to lack of interest, lack of knowledge, their own political agendas, or laziness.

Management would be wise to investigate which of the two possible reasons were responsible and only create a new system (which according to the paper is planned) if they are positive that users are not being unnecessarily obstreperous.

The was no mention in the paper of how the system creator (Vision) saw the implementation of the grant management system – success or failure? Have they learned from the Ivy scenario that it may not be possible to do grant management according to standard accounting practises? Or have they learned the importance of researching a concept objectively and not relying too much on word of mouth?

The authors mention several times that they have noted the system properties that are lost as well as gained at each stage in the transformation, however this is not elaborated on and is unclear what is meant by this.

The papers significant aspects include a very clearly outlined resistance to the ERP, particularly the grant management module. It was also very clear how one ‘champion’ has a lot of power in the formation of initial policy.

When they were explaining how they system was being created and designed I was wondering whether it was possible to do rapid prototyping and task analysis on the proposed system to ensure compatibility and if it was then why wasn’t it done?

The paper also outlined well how ‘best practise’ isn’t always ‘best’ and how best practise is created by those who are quickest able to black box their ideas.

An interesting idea is that of how systems can contain conflicting perspectives and interests.

If participants aren’t enrolled early on, compromise will most likely have to be made later on, at a greater cost.

The notion of agency of non-human actors is another significant aspect of this paper. ANT is time constrained - networks, relationships and agendas change over time. Order is temporary.

If you are a manager, get your ideas into formal documents asap that they are sooner black boxed and accepted as norms. However, realise that if the black boxed ideas aren’t solid they will be exposed with use.

The success of a system depends on user buy-in (enrolment). Users who are not consulted feel taken for granted and will dig their heels in. Users should be consulted early on but also told that their suggestions may or may not be implemented in the final design. Users will feel appreciated and the project will have a greater chance of success. However, the system should also do what it is supposed to, and at least be as efficient and effective as the previous version with minimal workarounds.

Management should also realise that running two systems for a time may be required, but there should be a cut-off date after which only one system should be supported.

Contractual arrangement to upgrades etc should be contingent on the successful implementation of the system in the first place. A contract with this in place would allow Ivy to expose the problems with the system. This would force the manufacturers to fix the problem properly. Of course, the ‘champion’ would also have to bear some responsibility.

Historical practises should be incorporated into new systems, for actual local best practise. These should be identified using task analysis and rapid prototyping.