Archive for the ‘Stakeholder Management’ Category

Integrating the change program with the parent organization (Lehtonen & Martinsuo, 2009)

Dienstag, April 28th, 2009

DSC02128

Lehtonen, Päivi; Martinsuo, Miia: Integrating the change program with the parent organization; in: International Journal of Project Management, Vol. 27 (2009), No. 2, pp. 154-165.
http://dx.doi.org/10.1016/j.ijproman.2008.09.002

 

Lehtonen & Martinsuo analyse the boundary spanning activities of change programmes.  They find five different types of organisational integration – internal integration 1a) in the programme, 1b) in the organisation; external integration 2a) in the organisation, 2b) in the programme, and 3) between programme and parent organisation.

Furthermore they identify mechanisms of integration on these various levels.  These mechanisms are

  Mechanism of integration
Structure & Control Steering groups, responsibility of line managers
Goal & content link Programme is part of larger strategic change initiative
People links Cross-functional core team, part-time team members who stay in local departments
Scheduling & Planning links Planning, project management, budgeting, reporting
Isolation Abandon standard corporate steering group, split between HQ and branch roll-out

 

Among most common are four types of boundary spanning activities – (1) Information Scout, (2) Ambassador, (3) Boundary Shaping, and (4) Isolation.  Firstly, information scouting is done via workshops, interviews, questionnaire, data requests &c.  Secondly, the project ambassador presents the programme in internal forums, focuses on quick wins and show cases them, publishes about the project in HR magazines &c.  Thirdly, the boundary shaping is done by negotiations of scope and resources, and by defining responsibilities.  Fourthly, isolation typically takes place through withholding information, establishing a separate work/team/programme culture, planning inside; basically by gate keeping and blocking.   

Governance Frameworks for Public Project Development and Estimation (Klakegg et al., 2008)

Montag, November 3rd, 2008

 Governance Frameworks for Public Project Development and Estimation (Klakegg et al., 2008)

Klakegg, Ole Jonny; Williams, Terry; Magnussen, Ole Morten; Glasspool, Helene: Governance Frameworks for Public Project Development and Estimation; in: Project Management Journal, Vol. 39 (2008), Supplement, pp. S27–S42.
DOI: 10.1002/pmj.20058

Klakegg et al. compare different public governance frameworks, particularly the UK’s Ministry of Defense, UK’s Office of Government Commerce, and Norway’s framework. The authors find that „the frameworks have to be politically and administratively
well anchored. A case study particularly looking into cost and time illustrates how the framework influences the project through scrutiny. The analysis shows the governance frameworks are important in securing transparency and control and clarifies the role of sponsor“ (p. S27)

Their analysis starts with the question of „Who are governance relevant stakeholders?„. The authors show two different general approaches to public governance stakeholders – Shareholder Value Systems and Communitarian Systems. The Shareholder Value System is based on the principle that only shareholders are legitimate stakeholders – a system which is used in the US, UK, and Canada. On the other hand the Communitarian System is based on the idea that all impacted communities and persons are relevant stakeholders – a system typically found in Norway, Germany, and numerous other countries. A secondary line of thought is the difference between Western and Asian stakeholder ideas, whereas the Asian idea is underlining the concept of family and the Western idea is underlining the relationship concept.

To pin down the idea of public project governance the authors draw parallels to corporate governance with it’s chain of management ↔ board ↔ shareholder ↔ stakeholder. The APM defines project governance as the corporate governance that is related to projects with the aim that sustainable alternatives are choosen and delivered efficiently. Thus the authors define a governance framework as an organised structure, authoritive in organisation with processes and rules established to ensure the project meets its purpose.

The reviewed governance frameworks show interesting differences – for example in the control basis, reviewer roles, report formats, supporting organisation, and mode of initiation. The principles they are based on range from management of expectations, to establishing hurdles to cross, to making recommendations. Focus of the reviews can be the business case, outputs, inputs, or used methods.

Governance and support in the sponsoring of projects and programs (Crawford et al., 2008)

Montag, November 3rd, 2008

 Governance and support in the sponsoring of projects and programs (Crawford et al., 2008)

Crawford, Lynn; Cooke-Davies, Terry; Hobbs, Brian; Labuschagne, Les; Remington, Kaye, Chen, Ping: Governance and support in the sponsoring of projects and programs; in: Project Management Journal, Vol. 39 (2008), No. S1, p. S43-S55.
DOI:10.1002/pmj.20059

Sponsoring of projects and programs is increasingly getting attention in project management research. The authors argue that this is due to two factors – (1) recognition of contextual critical success factors and (2) push for corporate governance.
[I personally think that riding that dead horse Sarbox is questionable to say the least and I can think of so many reasons why corporations want some of their projects controlled thightly.]

This article presents findings from a qualitative survey, in which 108 interviews from 36 projects in 9 organisations were collected. Crawford et al. propose a general model of project sponsorship – as they put it: „The conceptual model has significant potential to provide organizations and sponsors with guidance in understanding and defining the effective contextual conduct of the sponsorship role.“

Their general model consists of two dimensions – Need for Governance and Need for Support. In this model each sponsor can find his/her spot in the matrix by assessing what his/her focus of representation is. Sponsors either represent the need of the permanent organisation (need for governance) or they represent the need of the temporary organisation (need for support). In the interviews conducted, they identified typical situations which require a shift in emphasising one or the other dimension.

When to emphasise governance?
Among the resons and examples given during the interviews were: the project is high risk for the parent organisation, project performs poorly, markets are changing rapidly, governance or regulation call for increased oversight, project team behaved illegaly or non-compliant, the project is mission-critical, or the project’s objective is to re-align the company to a new strategy.

When to emphasise support?
Typical situations given were: parent organisation fails to provide resources, project faces resistance in the organisation, different stakeholders impose conflicting objecitve on the project, lack of decision-making by the parent organisation, project team is weak or inexperienced, or the project shows early signs of difficulities.

Among the many open research questions not yet addressed are –
What are the essential attributes to effective sponsoring?
Which influence does one or the other strategie has on project success?
Which competencies are required in a sponsor?
What are the factors contributing to effective sponsorship performance?
What does the role of the sponsor in different contexts of programmes/projects/organisations look like?

Stakeholder salience in global projects (Aaltonen et al., 2008)

Montag, Oktober 20th, 2008

 Stakeholder salience in global projects (Aaltonen et al., 2008)

Aaltonen, Kirsi; Jaako, Kujala; Tuomas, Oijala: Stakeholder salience in global projects; in: International Journal of Project Management, Vol. 26 (2008), No. 5, pp. 509-516.
http://dx.doi.org/10.1016/j.ijproman.2008.05.004

In their 1997 article, Mitchell et al. define stakeholder salience as „the degree to which managers give priority to competing stakeholder claims“. Furthermore, Mitchell at al. describe how the salience of a stakeholder is defined by three characteristics – (1) the stakeholder’s power to influence the firm, (2) the legitimacy of the stakeholder’s relationship with the firm, and (3) the urgency of the stakeholder’s claim on the firm.

Aaltonen et al. use the case study of a construction project of a paper-mill in South America to outline what strategies Stakeholders use to influence their salience. In line with typical case studies of construction projects Aaltonen’s stakeholders are environmentalist groups trying to influence the project. [I personally think based on my experience what Aaltonen et al. describe is also true for all sorts of projects, just if I think back to my organisational change and IT projects where we had workers‘ unions and councils as equally hard to manage stakeholders.] The authors observed a couple of strategies used:

  • Direct/indirect withholding strategy
  • Resource building strategy
  • Coalition building strategy
  • Conflict escalation strategy
  • Credibility building strategy
  • Direct action strategy

As per Mitchell’s definition these strategies aim to increase influencing power, legitimacy, and/or urgency. The tactics used to increase power were

  • Affect & influence parties, that provide resources, e.g., lobbying financiers and politicians
  • Affect the resource supply directy, e.g., laws and policies that prohibit imports
  • Build lobbying alliances, e.g., between environmentalist groups and unions
  • Recruit individuals with networks to important resource providers, e.g., ex-regulators, governmental workers, activists

The tactics used to increase legitimacy were

  • Initiate legal and political conflict, e.g., court action, political support
  • Inform the public about impacts of the project, thus damaging reputation of the project and increasing legitimacy
  • Signal illegitimacy of project, e.g., boycotts, counter impact studies
  • Attack supporters, e.g., showing them being partial, exposing lobbyists
  • Use other projects as showcases, e.g., using abandoned projects and withdrawls to show the illigitimacy of the project

The tactic used to increase urgency was signalling urgency, time-sensitivity, and criticality of decisions, e.g., by staging direct actions, protests, sit-ins, road blocks.

Stakeholder analysis in projects: Challenges in using current guidelines in the real world (Jepsen & Eskerod, in press)

Montag, Oktober 20th, 2008

Stakeholder analysis in projects: Challenges in using current guidelines in the real world (Jepsen & Eskerod, in press)Jepsen, Ann Lund; Eskerod, Pernille: Stakeholder analysis in projects – Challenges in using current guidelines in the real world; in: International Journal of Project Management, in press. http://dx.doi.org/10.1016/j.ijproman.2008.04.002Update the article has been published in:  International Journal of Project Management, Vol. 27 (2009), No. 4, pp. 335-343.In this small group experiment the authors presented four project managers with the task to analyse their stakeholders. The participants needed to identify, characterise, and decide how to influence stakeholders. To characterise them the project managers defined which contributions they needed from each stakeholder, what they would use a reward for contributing, and which power relationship linked manager and stakeholder.The participating managers (all managing renewal projects) identified a list of challenges they faced during this task

  • Comprehensiveness – How do I ensure that I identified all stakeholders? Is my list exhaustive?
  • Simplification – Can I treat some of them as a group?
  • Foresight – How can I ensure I specified all needed contributions upfront?
  • Biases – Ethical dilemmas, prejudices, generalisations about stakeholders
  • Tools – Suggested questionnaires are not practical, it’s hard to gather focus groups

Nevertheless Jepsen & Eskerod found two approaches that worked quite well – (1) Meetings with groups of stakeholders and (2) Initiating two-way interactions and discussions with stakeholders.Involve them early, involve them constantly!

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.

Perceptions of the impact of project sponsorship practices on project success (Bryde, 2008)

Freitag, Oktober 3rd, 2008

 Perceptions of the impact of project sponsorship practices on project success

Bryde, David: Perceptions of the impact of project sponsorship practices on project success; in: International Journal of Project Management, in press.

Bryde investigates in this article the question which impact on the project stakeholder practice has.
The impact on the project is simply measured as perceived performance score of the project. The different practices are operationalised in three factors (with items sorted according to their factor loading)

  • External focus
    • Responsible for defining benefits and requirements
    • Take delivery at completion
    • Establish strategy, set priorities
    • Define success criteria
    • Define project and objectives
    • Monitor benefits
  • Internal focus = supporting
    • Create an environment for projects to succeed
    • Make senior management commitment
    • Give training when necessary
  • Internal/external focus = championing
    • Cancel project if appropriate
    • Champion project, make resources available
    • Monitor business environment

Finally Bryde uses a stepwise regression to quantify the impact of each factor on the perceived project success score. Resulting in a two factor model where ‚External focus‘ (standardised β = 0.373) and ‚Internal focus‘ (standardised β = 0.268) impact the project success. Adjusted R2 is 0.326.

Unfortunately in this article the performance is just scored up although a multi-item measurement exists, factor analysis has not been employed. Furthermore the article does not detail the consistency of scale neither for the antecendents nor consequence (Cronbach’s Alpha) and does not test for heteroscedasticy or distribution. Thus this article falls short in advancing the development of a multi-item measurement of project success from a stakeholder point of view. 

Investigating the use of the stakeholder notion in project management literature, a meta-analysis (Vos & Achterkamp, in press)

Dienstag, September 30th, 2008

 Investigating the use of the stakeholder notion in project management literature, a meta-analysis (Vos & Achterkamp, in press)

Achterkamp, Marjolein C.; Vos, Janita F.J.: Investigating the use of the stakeholder notion in project management literature, a meta-analysis; in: International Journal of Project Management, Article in Press, Corrected Proof.
http://dx.doi.org/10.1016/j.ijproman.2007.10.001

Managing the stakeholders is an, if not the most, important part of the project manager’s job. Previously Vos & Achterkamp published articles focussed on the identification of stakeholders, which is a crucial and not so simple task.“Basic, but not trivial“, as one of my Economics professors always used to say.

In this article, however, Vos & Achterkamp reviewed 42 articles in terms of

  • Definition of stakeholders
  • Purpose of stakeholder notion
  • Identification issues
  • Role of stakeholders

Analysing the commonly used definitions of stakeholders the authors identify two key theoretically based definitions – stakeholders could either be persons with an interest in the project, or persons who can or are affected by the project. One or both of these two definitions are used in only 16.6% of articles reviewed, the remaining articles mainly deal with this topic without defining the object stakeholder at all.

Why look at stakeholders? The purpose of the stakeholder notion is first and foremost to sense-making and defining success. Further purposes of stakeholder management are risk management, use as source of information, and using stakeholders as a management instrument.

The review of the identification issue, a topic close to the authors, shows that most articles only recognise the issue, or explain it partly. Only a minority of 4 articles (out of 42) recognises and explains the issue.

Lastly Vos & Achterkamp review the roles of stakeholders. For reasons of not only simplifying complexity down to a managable level, but also for overcoming issues of stakeholder identification stakeholders the authors suggest an explicit, structured, role-based identificiation procedure. Whilst they acknowledge that stakeholder salience model, as discussed in this earlier post, is the leading theoretical model of identifying stakeholder; the authors argue that the role-based stakeholder classification model for innovative projects is more promising.

„Considering stakeholders in terms of roles of involvement in the context of projects then raises the question of whether there is anything new. Indeed, thinking in terms of roles is not new in project management. Could project roles perhaps be used for stakeholder identification?“ (p. 4)

Vos & Achterkamp review three articles in detail, which use a role-based stakeholder classification model. These three articles define the following roles

  • Callan et al. (2008)
    • Controller
    • Executer
    • Constraining advisor
    • Discretionary advisor
  • Turner (2008)
    • Manager
    • Steward
    • Owner
    • User
    • Sponsor
    • Broker
    • Resources
  • Vos & Achterkamp (2006)
    • Client
    • Decision maker
    • Designer
    • Passively involved

A multicriteria satisfaction analysis approach in the assessment of operational programmes (Ipsilandis et al., 2008)

Montag, September 22nd, 2008

A multicriteria satisfaction analysis approach in the assessment of operational programmes (Ipsilandis et al., 2008)

Ipsilandis, Pandelis G.; Samaras, George; Mplanas, Nikolaos: A multicriteria satisfaction analysis approach in the assessment of operational programmes; in: International Journal of Project Management, Vol. 26 (2008), No. 6, pp. 601-611.
http://dx.doi.org/10.1016/j.ijproman.2007.09.003

Satisfaction measurement was one of my big things for a long time, when I was still working in market research. I still believe in the managerial power of satisfaction measurements, although you might not want to do it every 8 weeks rolling. Well, that’s another story and one of these projects where a lot of data is gathered for no specific decision-making purpose and therefore the data only sees limited use.

Anyway, Ipsilandis et al. design a tool to measure project/programme satisfaction for European Union programmes. First of all they give a short overview (for all the non-knowing) into the chain of actions at the EU. On top of that chain sit the national/european policies, which become operational programmes (by agreement between the EU and national bodies). Programmes consists of several main lines of actions called axis, which are also understood as strategic priorities. The axis are further subdevided into measures, which are groups of similar projects or sub-programmes. The measures itself contain the single projects, where the real actions take place and outputs, results, and impact is achieved. [I always thought that just having a single program management body sitting on top of projects can lead to questionable overhead.]

Ipsilandis et al. further identify the main stakeholders for each of the chain of policies –> projects. The five stakeholders are – policy making bodies, programme management authority, financial beneficiaries, project organisations, immediate beneficiaries. The authors go on to identify the objectives for each of these stakeholder groups. Then Ipsilandis et al. propose a MUSA framework (multi criteria satisfaction analysis) in which they measure satisfaction (on a five point scale, where 1=totally unsatisfied, and 5=very satisfied)

  • Project results
    • Clarity of objectives
    • Contribution to overall goals
    • Vision
    • Exploitation of results
    • Meeting budget
  • Project management authority operations
    • Submission of proposals
    • Selection and approval process
    • Implementation support
    • MIS support
    • Timely payments
    • Funding ~ Scope
    • Funding ~ Budget
  • Project Office support
    • Management support
    • Admin/tech support
    • Accounting dept. support
    • MIS support
  • Project Team
    • Tech/admin competence
    • Subproject leader
    • Staff contribution
    • Outsourcing/consultants
    • Diffusion of results

The authors then run through a sample report, which contains the typical representations of satisfaction scores, but they have 3 noteworthy ideas – (1) the satisfaction function, (2) performance x importance matrix, and (3) demanding x effectiveness matrix. The satisfaction function is simply the distribution function of satisfaction scores.
[I still do not understand why the line between 0% at score 1 and 100% at score 5 should represent neutrality – Such a line would assume uniform distribution of scores, where I think normal distribution is more often the case, which is also acknowledged by the authors, when they try to establish beta-weights via regression analysis, where normality is a pre-requisite for.]

Furthermore Ipsilandis et al. continue to establish the relative beta-weights for each item and calculate the average satisfaction index accordingly (satisfaction is indexed at 0% to 100%). Cutting-off at the centroid on each axis they span a 2×2 matrix for importance (beta-weight) vs. performance (satisfaction index). The authors call these diagrams „Action diagrams“.
[Centroid of the axis is just a cool way of referring to the mean.]

The third set of diagrams, the so called „Improvement diagrams“, are demanding vs. effectiveness matrices. The demanding dimension is defined by the beta-weights once more. The rational behind this thinking is, that a similar improvement leads to higher satisfaction at items with a higher beta-weight. The effectiveness dimension is the weighted dissatisfaction index. Simply put it is beta-weight*(100%-satisfaction index %). Reasoning behind this is to identify the actions with a great marginal contribution to overall satisfaction and only little effort needed.
[I still don’t understand why this diagram is needed, since the same message is conveyed in the ‚action diagrams‘ – anyway, a different way of showing it. Same, same but different.
What I previously tried to fiddle around with are log-transformations, e.g. logit, to model satisfaction indeces and their development in a non-linear fashion, instead of just weighting and normalising them. Such a procedure would put more importance on very low and very high values, following the reasoning, that fixing something completely broken is a big deal, whereas perfecting the almost perfect (think choosing the right lipstick for Scarlett Johannson) is not such a wise way to spend your time and money (fans of Ms. Johannson might disagree).]

Post-project reviews as a key project management competence (Anbari et al., 2008)

Mittwoch, September 17th, 2008

 Post-project reviews as a key project management competence

Anbari, Frank T.; Carayannis, Elias G.; Voetsch, Robert J.: Post-project reviews as a key project management competence; in: Technovation, Vol. 28 (2008), No. 10, pp. 633-643.
http://dx.doi.org/10.1016/j.technovation.2007.12.001

George Santayana was the wise guy who said: „Those who cannot remember the past are condemned to repeat it.“ At university I learned that 2 strategies exist to make an organisation remember it’s past – Internalisation and Codification. While internalisation usually happens anyway and an organisation only needs to keep track on who did which projects in the past, so that he can be interviewed, the codification bit is tricky.

Anbari et al. describe which interest are held by which stakeholder group and how that is going to impact any knowledge management or lack thereof. The authors also outline useful techniques and critical aspects, plus when project reviews are most usefully held during the project lifecycle.

Furthermore, the paper discusses where post-project reviews fit into the project life cycle and project management processes. It assesses how such reviews can assist an organization in improving the manner in which its projects are conceived, planned, implemented, reported, and evaluated.

Finally Anbari et al. outline a 3-fold growth model for organisations
(1) Vicious circle = no real reviews
(2) Functional circle = reviews which no one knows about
(3) Virtuous circle = reviews everybody knows.

Interpreting an ERP-implementation Project from a Stakeholder Perspective (Boonstra, 2006)

Montag, August 11th, 2008

Stakeholder Salience Theory an Types of Stakeholders

Boonstra, Albert: Interpreting an ERP-implementation project from a stakeholder perspective; in: International Journal of Project Management, Vol. 24 (2006), No. 1, pp. 38-52.
http://dx.doi.org/10.1016/j.ijproman.2005.06.003

Boonstra analyses a case study from the stakeholders perspective using Stakeholder Salience Theory (Mitchell, Agle, Wood 1997). Stakeholder Salience Theory states that the prominence of a stakeholder (salience) is directly related to the cumulative attributes of power, legitimacy, and urgency.

Power (= exercise will against resistance) is explained with resource dependence theory, agency theory, and transaction cost theory. Resource dependence theory shows that managerial attentions is required if the project is depends on a critical resource owned by a stakeholder. Further managerial attention is required if opportunism can potentially occur in that relationship, as explained by agency and transaction cost theory.

Legitimacy (= compliance of activities and outputs with existing norms, beliefs, values is explained by population ecology and institutional theory. Population ecology states that projects not fulfilling stakeholders needs struggle to survive; whilst institutional theory observes that survival depends on legitimacy acquired from conformance or isomorphism. Thus legitimate stakeholders require managerial attention.

Urgency (= degree of need for immediate attention) is a general concept in several organisation theories but explicitly discussed in issue management and crisis management literature. Urgency has two distinctive attributes time sensitivity and criticality of the claim. Urgent stakeholders require managerial attention.

From Neville, Benjamin A.; Menguc, Bulent; Bell, Simon J.: Stakeholder Salience Reloaded – Operationalising Corporate Social Responsibility, in: ANZMAC 2003 Conference Proceedings, Adelaide 1-3, December 2003, pp. 1883-1889.

Based on these 3 attributes Boonstra identifies 8 types of stakeholders.
„1. Dormant stakeholders possess the power to impose their will on a firm but, by not having a legitimate relationship or an urgent claim, their power remains unused.
2. Discretionary stakeholders possess legitimacy, but have no power for influencing the firm and no urgent claims. There is no pressure to engage in a relationship with a stakeholder.
3. Demanding stakeholders exist where the sole stakeholder relationship attribute is urgency: those with urgent claims, but having neither legitimacy nor power.
4. Dominant stakeholders are both powerful and legitimate. Their influence in the relationship is assured, since by possessing power and legitimacy they form the dominant coalition.
5. Dependent stakeholders are characterised by a lack of power, but have urgent and legitimate claims. These stakeholders depend on others to carry out their will. Power in this relationship is not reciprocal and is advocated through the values of others.
6. Dangerous stakeholders possess urgency and power but not legitimacy and may be coercive or dangerous. The use of coercive power often accompanies illegitimate status.
7. Definitive stakeholders possess power legitimacy and urgency. Any stakeholder can become ‘definitive’ by acquiring the missing attributes.
8. Non-stakeholders possess none o f the attributes and, thus, do not have any type of relationship with the group, organisation or project.“ (Boonstra 2006, pp. 40-41).

Boonstra then identifies the different stakeholders on the project, when they were evolved, which events triggered their involvement, and which meaning they gave the ERP system. The author shows that different stakeholders have different meanings, attitudes, and views, which dynamically change over time and which are not always disclosed. [Similar to the concept of technological frames described in this article.] Furthermore Boonstra underlined the importance of power as a major attribute for stakeholder salience. He also showed that Dominant Stakeholders can become Dormant Stakeholders, which activates other stakeholders to fill in that power gap.
For future research they briefly discuss two possible directions (1) linking stakeholder analysis to success/failure of projects and (2) exploring the role of the project manager.

A Case Study of Project and Stakeholder Management Failures: Lessons Learned (Sutterfield et al., 2006)

Donnerstag, Juli 17th, 2008

Stakeholder Management

Sutterfield, J. S. Friday-Stroud, S. S. Shivers-Blackwell, S. L.: A Case Study of Project and Stakeholder Management Failures – Lessons Learned; in: Journal of Project Management, Vol. 37 (2006), No. 5, pp. 26-35.

Sutterfield et al. describe a framework for managing the project’s stakeholders from the perspective of the project manager. Their framework includes the following 9 steps

  1. Identify project vision and mission
  2. Conduct project SWOT analysis
  3. Identify the stakeholders and their goals
  4. Identify selection criteria for strategies on how to manage the stakeholders and identify alternative strategies to manage the stakeholders
  5. Select PSM strategy for each stakeholder (PSM in this case is neither project safety management, nor procurement strategy management, but rather project stakeholder management)
  6. Acquire and allocate resources to manage stakeholders
  7. Implement the selected PSM strategies
  8. Evaluate the implemented PSM strategies
  9. Seek and incorporate continuous feedback

A Roadmap for IT Project Implementation – Integrating Stakeholders and Change Management Issues (Legris & Collerette, 2006)

Freitag, Juli 11th, 2008

History of PM Theories

Legris, Paul; Collerette, Pierre: A Roadmap for IT Project Implementation – Integrating Stakeholders and Change Management Issues; in: Project Management Journal, Vol. 27 (2006), No. 5, pp. 64-75.

Legris & Collerette start with an overview of theories on IT implementations. Locating the roots of these discussion in technology adoption models rather than in project management. Furthermore they break down the typical IT implementation project in 5 phases – preliminary analysis, systems requirement, preparation, implementation, and consolidation. They outline key factors for each phase and offer scales on how to score each of these factors to assess the condition of the project.