Research feedback

I received the first feedback from my new mentor today.  He admits that he knows little about IT and nothing about ERP but that isn't the problem. According to 'The craft of research', the problem is mine -

Since few people read research reports for entertainment, you have to create a relationship that encourages them to see why it’s in their interest to read yours. That’s not easy. Too many beginning researchers offer readers a relationship that caricatures a bad classroom: Teacher, I know less than you. So my role is to show you how many facts I can dig up. Yours is to say whether I’ve found enough to give me a good grade. Big mistake. Do that and you turn your project into a pointless drill that demeans both you and your teacher. Worse, you cast yourself in a role exactly opposite to that of a true researcher. In a research report, you must switch the roles of student and teacher. When you do research, you learn something that others don’t know. So when you report it, you must think of your reader as someone who doesn’t know it but needs to and yourself as someone who will give her reason to want to know it.

In other words, I haven't explained in the research proposal - at least, to this reader's understanding - why using spreadsheets in an ERP environment is a problem. Maybe this information should be in the currently non-existent abstract.

The mentor brought up an interesting point, about absorption and non-absorption. As I understand it, he is asking about companies which failed to implement ERP and whether this failure was due to EUC. There is a statistic bandied about that "50% of all SAP implementations fail", but there is a world of difference between SAP and Priority. Whilst I am not aware of failed implementations of Priority, I am aware that not checking them is falling prey to the survivor's bias. I think that this is out of the scope of my research, but would be worth mentioning in the 'further work' or 'conclusions' section of the proposal and/or thesis.