Why is it important to focus on the public sector?

My research looks at engagement on public sector IT projects, so

Why is it important to focus on the public sector?

This might be a viva question and I can say that I justify this focus in the literature review (page 14) where I've written:
IT projects are important to the public sector because they are a key means of implementing government policy requiring often rapid changes to how the public sector department functions and provides services.
But maybe I've justified only the focus on IT projects, not on the public sector. The public sector makes policy and implements it through IT. Examples of failures of such implementation are:

• Libra system for the magistrates courts
• the National id scheme with an initial budget of £3 billion that went up to £5 billion.
• in 2003 the government introduced two credits: Child Tax Credit and Working Tax credit. The Inland Revenue's IT supplier created a new IT system for processing the tax credits, a system that went live in April 2003 with problems that took ten weeks to solve. Volumes were higher than expected and the testing window had been cut. Both suppliers and IR senior managers had to account for the fiasco to a Parliamentary Public Accounts Committee.

Public Sector IT continues to be problematic. The day after I submitted my thesis, a Public Administration Select Committee was interviewing IT expert witnesses on good governance and the effective use of IT (pd report is here). Witnesses pointed out that IS is there to implement government policy and government business change.

Hence, I see a need to focus on the public sector.

What story am I telling?

I choose a quote to illustrate something and my supervisor asks me who said it. Or I don't choose enough quotes and my supervisor asks for more, so as to get an idea of the personality. But no-one checks that I haven't made up the quotes, or that the story I'm telling is what actually happened. Apart from my supervisors observing the process I'm following, because names and organisations are confidential, no-one knows who or where I got the data from.

So why couldn't I make up a story?

To some extent, I am making up a story. I take someone else's words in a document, or from an interview. I transcribe the interview words, losing the hand gestures, and the facial expressions, and the emphasis. I put in punctuation; punctuation doesn't exist when you talk - you just talk. So straight away, I'm creating a story slightly different from the original that was intended by the interviewee - it's a story that is my interpretation of what I think I heard the interviewee say. Then I wrap the interview quotes up with my own words in the paper I write. Then my supervisor reads it and interprets it in a different way from what I meant - gets a different story or even no story from it.

And so it goes on - it's the sociological equivalent of the old IT cartoon about the user requirements where the systems analyst understood a piece of wood had to hang from a tree branch, the designer wanted to hang the wood with three pieces of room, and the programmer sawed the tree trunk in half, propped it up, and hung the wood from two ropes on opposite branches. All the user wanted was a tyre to swing on. The discrepancies between expectations are analysed here.

So the story I'm telling could be as varied as there are people involved in telling it and listening or reading it. That's constructionism.

Aim of my research

The aims of my research are manifold:

• to get me a PhD
• to learn to write - more than writing because communication includes presenting research
• to find how (good?) clients engage with external consultants
• to argue the value of using consultants

What is my research? I chose the public sector, partly because I'd worked in it, partly because I knew there was a good supervisor whose strengths were in the public sector, partly because I know something of the consultancy world and partly because the media is so interested in the public sector and demands it be accountable. One area of public accountability is the use of consultants. They are expensive and perceived to be a waste of public money. So my research is examining, not that perception, but what value consultants do provide the public sector.

The public sector uses consultants in many different areas: IT, management, legal, construction, training. As a large proportion of public spending is on IT, and because I have a background in IT, I chose to focus my research on II projects.

IT projects draw in different types of people: consultants, developers, users, managers, third party suppliers of hardware, software and of contractors. Contractors may come with particular development skills. So a project may be made up of civil servants and consultants who consider the civil servants as their clients, but also made up of contractors, who work alongside the civil servants developing IT projects. Such a plethora of roles implies a variety of relationships and it's the relationships that my research's focusing on. How do these relationships start, grow, get maintained but particularly what are the relationships between client and consultants?

For work to be effective in leading to a finished project, the NAO exhorts clients and consultants to engage. But it is unclear what engagement is - just that it's something expected from both client and consultant doing something together.

Engagement is not the same as collaboration, which is an organisational arrangement.
Engagement is not user participation in IT testing, which might be part of a job role.
Engagement seems to be of hearts and minds: enthusiastic intrinsic motivation to get a job done well, and consultants can oil the wheels to give that flowing engagement between people. That means consultants mediate and it's the mediation that enhances engagement that leads to effective working on a project.

But are all consultants mediators? Some mediate at a strategic level, influence strategy, others mediate between project members (as does a project manager) influencing tactics and relationships. But if they get it wrong, consultants may deter engagement, not encourage it or even prevent it. Which leads to another question: how can the public sector best engage with consultants to engender engagement.

Engagement creates engagement. Yes - there's research evidence from psychology that suggests that recursion and queries it: which comes first, engagement leads good relationships, or good relationships lead to engagement? And what's best? That might be where I need to bring in Habermas to find a spectrum of engagement.

More questions; more research; more questions.

IS theory web site

I contacted Professors Petter and Randolph because their work is so interesting. See my earlier blog on their work here. They kindly answered. One resource they reminded me of, I haven't been there for a while, is the IS theory website, which is really useful and comprehensive. There is a page on social capital theory that includes a listing of papers in IS that use this theory:
http://www.istheory.yorku.ca/Socialcapitaltheory.htm.

Social capital, knowledge integration and IT

Social capital fascinates me because of its potential to transfer, integrate and create knowledge. Newell et al explore social capital and knowledge integration in an IT context, which makes it a fascinating paper. It's also about real research, not just concept development, even if it is just the one case study.

First the authors review the literature on

1. knowledge integration in large IT design and implementation projects ,
2. role of social capital in facilitating knowledge integration (Coleman, Granovetter). This includes mention of
   

• communities of practice (Lave & Wenger),
• interpretivist research (Berger & Luckmann)

I'm glad to realise that I am familiar with most of this literature.

Newell et al quote Napahiet & Ghoshal's argument that individual project members need to draw on their social capital to access dispersed knowledge (Nonaka) and problems arise if members don't use social capital or cannot integrate knowledge in the project team.

The researchers included a participant observer visiting over 18 months - more time than I've got. I've got something more like six months left to collect data. They recorded hour long interviews with all nine team members as well as ten owners, which something like what I'm doing. But they also had forty informal unrecorded interviews. The write-up seems to me to be a narrative and perhaps I can write something similar for my half dozen case studies.

Newell et al's case study shows more negative use of social capital than my case studies so far. For example, there was "little attempt to share", whereas I know a project where members emphasised team work and sharing right from the start. Newell et al's case study also used two IT consultants but they "did not see any need for involvement with potential users", so there's a different attitude to engaging with clients, and certainly not an attitude that uses social capital. Another contrast is the observation "that there was very little interaction and dialogue during meetings" (p50). I found a developer who'd been described as shy and who saw herself as quiet, but admitted that she now spoke up much more at meetings. Something about sharing in the team helped her to learn and to share.

Newell et al commented on meetings that team members often missed. I've had the impression in one case that when a more junior member stood in at a meeting, that some senior managers paid less attention.

Newell et al assess the bonding and bridging in their case study .
Bonding is about social cohesion within the team (similar to De Marco's module cohesion) - the more the better).
Bridging is reaching out to other communities (similar to De Marco's coupling) - it should be weak as in Granovetter's weak links

The above indicated that the bonding was poor, but unfortunately the bridging in Newell et al's case was also poor. They refer to "structural holes".

In conclusion the authors argue that "bridging and bonding aspects of social capital must be distinguished". I can use that in analysis of the case studies I find. The antecedent condition is to develop team bonds first, and I know evidence that supports this, where sociability was encouraged and trust existed.

It also shows the value of engagement. People need to share, be involved, interact and have dialogue.

---

Newell, S., Tansley, C. and Huang, J. (2004) 'Social Capital and Knowledge Integration in an ERP Project Team: The Importance of Bridging AND Bonding', British Journal of Management, 15, pp. 43-S57. 1109

EURAM rejection

I'm glum because my proposal to the EURAM doctoral colloquium has been rejected - it could be the first of many. However, the reviewers sent feedback. The rejection may be because the proposal didn't mention the IT literature from journals like Organization Science and Organization Studies (my first interest was in the consultants and then I specialised in IT consultants) which the reviewers found "surprising and problematic". But they suggested that I also look at literature on occupations and roles by authors such as Bechky.

I emailed my supervisors with the glum news, and they're being consolatory and practical, attaching papers on

• IT by Robey
• workplace artifacts by Bechky.

So I plod glumly onwards and onwards.

Social capital theory & IT

I found this paper (pdf) on IT and social capital but I was too late to get to the workshop where it was presented. Randolph and Petter write on the role of social capital inIT project management, arguing that who the project manager knows is important, so they introduce the theory of social capital, suggesting implications and possible future research. I wonder if they know anyone already researching this.

---

Randolph, A. B. and Petter, S. (2008) 'Is It What You Know or Who You Know? The Role of Social Capital in Information Technology Project Management', 3rd International Research Workshop on Information Technology Project Management (IRWITPM), Paris, France2008.

Managing consultants and outsourcers

A complication of project work is the number of stakeholders. Not infrequently, consultants and outsourcers work on the same project, particularly in IT. Peled in Israel researched the relationship between government bureaucrats, consultants and vendors looking to see who won or lost power when the government outsourced {Peled, 2001}. My diagram indicates the complicated relationships. It also shows that the consultants are a conduit between client and subcontractors.

Peled's analysis of interviews and participative observation found that the bureaucrats suffered a loss of management skills when using consultants, specifically feedback, negotiation, legal and accounting skills because the consultants negotiated with and supervised vendors. Unchecked power of IT consultants hindered management's ability to account. When projects failed, few bureaucrats knew the IT systems for which they were responsible, nor how failures could have been avoided. Peled recommends that bureaucrats must develop an interest in technological projects. On a project that involves a vendor or outsourcing to a third party as well as use of consultants, Peled suggests potential controls on consultants' work such as acknowledging consultants rather than hiding them.

---

Peled, D. A. 2001. Outsourcing and Political Power: Bureaucrats, Consultants, Vendors and Public Information Technology. Public Personnel Management, 30(4): 495.

Analogy

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.

Negative effect of accountability

Accountability has such a negative connotation. It goes with blame and avoidance of risk and is frequently associated with blame and negativity. It gets passed down a chain until it becomes weakened.

Yet it can have a positive effect. There's evidence that being accountable produces more successful projects. Thomas & Fernández found accountability for project results drove positive behaviours.Their qualitative research explored how 36 Australian companies defined IT project success, finding that when formal definitions of success exist, and can be measured, then IT outcomes are improved and resources better utilized. They found that:

"companies that held business managers accountable for results had the most effective evaluation practices. Accountability was found to drive positive behaviours, improving the both the consistency of measurement & the willingness of managers to act... accountability addressed many evaluation challenges."

They found evidence that holding a client manager accountable for IT projects leads to effective evaluation practices:

"The fundamental principle was that if managers were held accountable then evaluation got done and results were used. Companies without accountability for results tended to complete ex-post evaluations inconsistently or not at all."

---

Thomas, G. & Fernández, W. 2007. The Elusive Target of IT Project Success, 2nd International Research Workshop for IT Project Management,Montréal, Québec, Canada. From Association of IS Managers SIG conference, paper available at http://www.sigitprojmgmt.org/WorkshopProceedings2007.pdf

Adrift without an anchor

Supervisors have read my latest attempts at avoiding focusing, finding a research question or reviewing the literature. Sup #2 says I need an anchor.

• the focus should now be on IT consultancy
• show where the research questions come from, and then prune them
• write with detail
• appraise the literature - critically - what are the strengths and limitations of the studies.

Sup #2 has been useful in providing verbal suggestions for future six weeks, and sup#1 has given me detailed comments on written stuff.