Wednesday, 30 April 2008

Value from consultants

Block's 2nd [1] edition says that on implementation
"the greatest service of the consultant may be to raise consciousness of the client about the value of engagement in the implementation process."
But getting that value from the consultant must depend on getting the value from engagement, and I don’t know what engagement is.

[1] Block, P. (2000) Flawless Consulting: a guide to getting your expertise used, (2 Edn), Jossey-Bass/Fpeiffer. 27

Wednesday, 23 April 2008

Client engagement

Czerniawska argues that the extent of engagement among client-managers who work with consultants determines the success of consulting projects but she does not define engagement. Engagement may relate to reasons for using consultants. Reasons may be:
  • people,
  • process
  • perspective
  • politics
Management processes can improve the use of consultants, and hence the need for client management engagement with consultants. If clients must engage with consultants, then what does engagement entail?

UK government documents indicated the importance of top-level engagement and commitment [2,3,4,5]. The NAO report makes recommendations to improve engagement in consulting projects but does not distinguish types of client in public organisations.

[1] Czerniawska, F. (2006). Ensuring sustainable value from consultants.
[2] Intellect. (2000). Getting IT Right for Government A Review of Public Sector IT Projects.
[3] Intellect. (2003). IT Supplier Code of Best Practice.
[4] NAO (2006) Central Government's use of consultants: Building client and consultant commitment National Audit Office.
[5] NAO (2006) Delivering successful IT-enabled business change Vol. HC 33-1 National Audit Office.

Saturday, 19 April 2008

Constructing consultancy

I'm a bit confused by Czarniawska's paper [1]. She describes attempts to communicate between a business practitioner and a researcher (herself) as using two different logics. I'd have said that they were talking at cross purposes Czarniawska describes it in terms of logics and describes these logics. Now up to now, for me, logic is logic is logic – like one logic and no variations. But she describes:
  • logic of representation
  • logic of practice
  • logic of theory
Logic of theory claims to use formal logic and has criteria of truths – sounds like what I understood to be logic – mathematical logic
Logic of practice is concrete, uses incomplete narrative and tacit knowledge – sounds like common sense to me.
Logic of representation is abstract, uses rhetoric and stylised narrative – sounds like a form of story telling.

I think Czarniawska might be saying the same thing as Seidl and Mohe, but using different theories. They said consultants and their clients couldn't communicate because they each work in their own system and the communication got distorted (perturbed) in transmission.

I have a recollection of someone (Fincham?) writing about the different discourses that clients and consultants use. I must find and check if that is another way of explaining talking at cross purposes.

[1] Czarniawska, B. (2001) Is it possible to be a constructionist consultant? Management Learning, 32 (2), pp253
[2] Seidl, D., Mohe, M., (2007) The consultant-client relationship: a systems-theoretical perspective. Available from

Friday, 11 April 2008

Project management and risk

Supervisor #2, who has experience of projects, suggested that I look at risk evaluation and analysis in project management.

Gray & Larson (2008) devote a whole chapter to managing risk [1]. They look at the process, breaking it into steps:
  1. identification,
  2. assessment and
  3. risk response development.
I can see the relevance of managing risk to project management. Identifying risks is a senior management responsibility [2]. In the public sector people may evaluate strategic choices in a risk averse culture . Consequently, people may go for a project where there is a lower chance of success but a paper trail exists to show that it's not their fault, rather than a project with a high chance of success, but no paper trail. At least that’s my hypothesis and how do I check it?

Risk avoidance strategies make it harder to implement change. Risk averse contracts that put the onus on the supplier or the consultant do not improve the probabilities of success.

Beck & Mobs [3 ] discussed motivations of the various stakeholders when they proposed a longitudinal case study research of a large public private project in Germany. They thought that private managers tended to be more risk averse than politicians leading public agencies. Politicians can demonstrate groundbreaking investments in IT. Perhaps politicians hold a different attitude to risk from the public servants that must implement the IT projects.

Other researchers have used quantitative analysis to explore risk factors that may influence decisions [4], [5]. But I don’t think I want to go the quantitative route. I need to be aware of risk management but that it’s not the focus of my research question.

Smith et al (2006) analysed risk factors relevant to software projects and identified most important risks as lack of top management commitment to a project, and lack of client responsibility, ownership and buy-in of project and its delivered systems [4]. That's what interests me.

[1]GRAY, C. F. & LARSON, E. W. (2008) Project management: the managerial process, NY, McGraw-Hill.
[2]INTELLECT (2000) Getting IT Right for Government A Review of Public Sector IT Projects.

[3] BECK, R. & MOBS, A. (2006) The Public Hand and IT Mega-Projects: Lessons from the German TollCollect Case. Inaugural Research Workshop for IT Project Management Milwaukee, WI, Association for Information Systems Special Interest Group on IT Project Management
[4] SMITH, D., EASTCROFT, M., MAHMOOD, N. & RODE, H. (2006) Risk factors affecting software projects in South Africa. South African Journal of Business Management, 37, 55-65.
[6]AUBERT, B. A., BARKI, H., PATRY, M. & ROY, V. (2008) A multi-level, multi-theory perspective of information technology implementation. Information Systems Journal, 18, 45-72.

Thursday, 10 April 2008

Supervisor change

I'm quite sad. My supervisor #1 says that I'm moving away from his area of expertise (public sector) and he thinks he shouldn't go on supervising me. This is partly because he and supervisor #2 have encouraged me to look at the use of IT consultancy, and he doesn't feel that he knows much about that area. However, there is another professor in the OUBS who might be interested in supervising me, and we have already met and discussed a month or so ago. This professor got involved when I got a chance to talk over my proposed research with a CEO of big consultancy. So things should work out well.

Tuesday, 1 April 2008


People think I'm asking how consultants account for their work, which isn't what I'm trying to get at; I'm interested in how consultants' work is managed in the public sector.

It's akin to asking someone to build you a conservatory. You check out who the potential builders are, select one, give them a brief, and watch them lay the foundations and put together some contraption out of aluminium or wood or whatever. But suppose you just give them the job - "build me a conservatory" and leave them to it. You'll get what the builders decide to do when they decide to do it. Of course your brief might be to put it in that position, and make it eco-friendly, and to fit in with a listed building. That might go in the contract, but if you then ignore what they're doing, how can you tell where they're up to, if they're making any progress, and if it's the right progress. And I suppose if you're scared of builders, or out at the office/university all day, you could always hand over their management to your teenage children. Tell them to let you know when the job's finished and they want you to pay the bill.

Do you think that senior management in the public sector might be scared of IT builders? would they delegate the job to middle management? Or perhaps to outside consultants?

Some report said that senior management should be involved - it's a success factor in projects. And some government report says that there should be trained and experienced people to run projects, and that there should be a Senior Responsible Officer (SRO) in charge of every project.