Archive for the ‘Critical Incident Technique’ Category

Project leadership in multi-project settings – Findings from a critical incident study (Kaulio, 2008)

Donnerstag, Oktober 23rd, 2008

 Project leadership in multi-project settings - Findings from a critical incident study (Kaulio, 2008)

Kaulio, Matti A.: Project leadership in multi-project settings – Findings from a critical incident study; in: International Journal of Project Management, Vol. 26 (2008), No. 4, pp. 338-347.
http://dx.doi.org/10.1016/j.ijproman.2007.06.005

Kaulio asked project leaders, who operate in a multi-project environment about critical incidents in their last projects. The idea of critical incidents is, that as soon as a participant remembers the critical incident it must have some importance. Ideally it then is followed by a blueprint analysis followed by measuring the criticality is measured on each contact point. Kaulio focusses only on the elicitation of the critical incidents, without doing the triple-loop of the original research concept. The author shows the frequency of critical incidents happening:

  • Technical difficulties
  • Dyadic leadership
  • Group dynamics
  • Consultant relations
  • Client relations
  • Peer relations
  • Project adjustments
  • Re-prioritisations
  • Liked dyadic-group processes
  • Formation of project
  • Court decisions
  • Dependencies
  • Requirements specification

Kaulio then maps these critical incidents according to the Locus of Control (internal vs. external) and whether they are a Management or a Leadership issue. Thus he argues  most of the critical incidents can be tied back to internal project leadership:

Locus of Control External
  • Project adjustment
  • Court decision
  • Consultant relations
  • Client relations
  • Peer relations
  • Formation of project
  • Dependencies
Internal
  • Requirements specification
  • Dyadic leadership
  • Group dynamics
  • Linked dyadic-group processes
  • Technical difficulties
  • Re-prioritisation
Management Leadership
Focus

Managing user expectations on software projects – Lessons from the trenches (Petter, in press)

Dienstag, Oktober 7th, 2008

 Managing user expectations on software projects - Lessons from the trenches (Petter, in press)

Petter, Stacie: Managing user expectations on software projects – Lessons from the trenches; in: International Journal of Project Mangement, in press (2008).
doi:10.1016/j.ijproman.2008.05.014

Petter interviewed 12 project management professionals on managing the end-user expectations.  What worked and what did not work?

The conclusions cover three broad areas – end user involvement, leadership, and trust. As far as user involvement is concerned the practices that work included

  • Listening to users
  • Asking questions
  • Understanding concerns about change and actively ease these
  • Working with the user (not at or to them)
  • Let user make tough choices, e.g., on functionality, budget, cost, time
  • Create small user groups to hear them all
  • Giving credit to specific users for ideas
  • Keep users involved and updated throughout the project

What did not work were – not communicating the project status, and trying to outlast difficult users.

On the leadership dimension useful practices mentioned include

  • Ensure project champion
  • Articulate clear vision
  • Motivate team to get it done
  • Educate users on benefits
  • Obtain buy-in from primary stakeholders

Factors leading to end-user dissatisfaction were

  • Scope creep
  • No mission
  • No explanation of purpose/value of the system
  • Follow others

Trust building activities that worked well, were sharing good and bad news, and providing specific times for deliverables. What did not work were hiding the true status of the project, and ‚fake it until you make it‘ also known as hiding knowledge gaps.

Information Systems implementation failure – Insights from PRISM (Pan et al., 2008)

Donnerstag, September 18th, 2008

 Information Systems implementation failure - Insights from prism

Pan, Gary; Hackney, Ray; Panc, Shan L.: Information Systems implementation failure – Insights from prism; in: International Journal of Information Management, Vol. 28 (2008), pp. 259–269.

The authors apply a „antecedents — critical events — outcomes“-framework to analyse the implementation process. Pan et al. postulate a recursive process interaction model which repeats throughout critical events in the project. The Process modell flows circular between Project Organisation-(innovates)-IS-(serves)-Supporters-(support)-Project Organisation and so on.

Furthermore the authors identify critical events (positive and negative) to analyse the system failure of the whole project. Generalizing from the chain of negative events, Pan et al. found that recursive interactions lead to a drift of the project. Subsequently that drift leads to a sequence of decision mistakes which accelerated into project failure.