Showing posts with label project. Show all posts
Showing posts with label project. Show all posts

Friday, 9 October 2009

Projects and social capital

Nahapiet & Ghoshal’s (1998) model assumes the existence of social capital; the fed back intellectual capital is apparently the only input to sustain social capital. Nahapiet & Ghoshal point out,
“much of this capital is embedded within networks of mutual acquaintance and recognition”
so interaction is essential for the development and maintenance of social capital but that development takes time. Something needs to create the social capital in the first place.

In a project context, which by its nature is temporary and time bounded, the various project members may well come without pre-existing relationships, and hence, without social capital as a means to create and exchange intellectual capital. Without initial social capital, Nahapiet & Ghoshal’s model cannot start to apply.

Project members must create initial social capital. How do they get started? That's where they need to engage with each other.



Nahapiet, J. and S. Ghoshal (1998). "Social capital, intellectual capital, and the organizational advantage." Academy of Management Review 23(2): 242-266.

Saturday, 2 August 2008

Assumptions about engagement

I'm assuming that the unit of analysis is the project. Why is it the project, because if it's the project is there a problem with the project? Is there a problem with IT projects in the public sector? And if there is a problem why does engagement have anything to do with the problem?
  • The NAO report (NAO, 2006) assumes that engagement is a good thing.
  • I'm assuming engagement is a process.
  • I'm assuming engagement is not a widely recognised management construct.
  • I am assuming one kind of engagement exists. Or does it vary depending on something? What? Perhaps it's its quality that varies. I note that the quality of engagement requires: reciprocity, shared decision making, a high level of interest, and is action for something worth doing.
But some studies measure engagement, such as the IES. Though I don't have free access to its reports its summary defines engagement:
"a positive attitude held by the employee towards the organization and its values"
I'm not sure that the NAO writers meant the same thing. The IES survey used a diagnostic tool that ranged from training & development to job satisfaction, which to me sounds like motivation and motivating factors {Marcum, 1999}, so something other than engagment. And I don't think the NAO would measure its senior responsible owners engagement on the same characteristics as the IES uses.


NAO (2006) Central Government's use of consultants: Building client and consultant commitment National Audit Office
Marcum, J. W. (1999) 'Out With Motivation, in With Engagement', National Productivity Review (Wiley), 18 (4), pp. 43-46.

Monday, 12 May 2008

A systems view of project management risk

Diana White's PhD thesis, "A systems view of project management risk" is very useful. Her research started with an interest in systems thinking at a time when some major projects had failed at great cost. She thought that management of risks associated with projects might be prevented by the use of systems thinking. And I like her diagram on page 8 which seems to be a cause-effect of the research overview. I tried my own:

But it doesn't reproduce well here, and this has got to be a working document because I want to add and change some of the bubbles and links already. So I'll do it again later.

Diana has a chapter that examines the literature on project management as well as three interesting case studies, one in ICT. So I'll note some of her references. However, she concentrates on projects and project management tools whereas I want to look more at people and management aspects of projects. My primary interest is in consultants and the management of them, but because consultants inevitably come with projects, then I must consider how they are managed in projects.

My review might begin:
"This review of the literature attempts to identify notions of successful use of consultancy contributions where public sector top management behaviour has reaped value."

except I'm not going to use the term 'value'. I like the metaphor of the harvest though in the word 'reap'. That is to harvest, or sow, glean, take the fruits of.

I want access to people at the top of the project; these could be contact or primary clients. I might want to interview the chair of a project board, and the relevant politician.

How much does a public but non-central government organisation use the advice and frameworks that NAO and OGC provide?

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.
[5]BARKI, H. & HARTWICK, J. (2001) INTERPERSONAL CONFLICT AND ITS MANAGEMENT IN INFORMATION SYSTEM DEVELOPMENT. MIS Quarterly, 25, 195-228.
[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.

Tuesday, 1 April 2008

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.