Expectations Management - Revision history

Tkokotas at 13:53, 9 November 2018

2018-11-09T13:53:31Z

← Older revision		Revision as of 13:53, 9 November 2018
Line 1:		Line 1:
			''Developed by Gudjon Arngrimsson''


	As stated in the The 5th edition of PMBOK from the Project Management Institute (PMI), "It is critical for project success to identify the stakeholders early in the project or phase and to analyze their levels of interest, their individual expectations, as well as their importance and influence." This article mainly focuses on stakeholder expectations aspect mentioned. To do so, some basic concepts on stakeholder management will be introduced and explained.		As stated in the The 5th edition of PMBOK from the Project Management Institute (PMI), "It is critical for project success to identify the stakeholders early in the project or phase and to analyze their levels of interest, their individual expectations, as well as their importance and influence." This article mainly focuses on stakeholder expectations aspect mentioned. To do so, some basic concepts on stakeholder management will be introduced and explained.

Line 113:		Line 116:
	<references />		<references />

	[[Category:Project Management]] [[Category:Stakeholder Analysis]]		[[Category:Project Management]] [[Category:Stakeholder Analysis]] [[Category:Stakeholders]] [[Category:People]]

Tkokotas at 21:07, 24 October 2018

2018-10-24T21:07:01Z

← Older revision		Revision as of 21:07, 24 October 2018
Line 113:		Line 113:
	<references />		<references />

	~~[[Category:Stakeholders]] [[Category:Stakeholder Involvement]]~~ [[Category:Project Management]] [[Category:Stakeholder Analysis]]		[[Category:Project Management]] [[Category:Stakeholder Analysis]]

Gudjon: /* Value vs complexity */

2017-10-02T21:19:01Z

Value vs complexity

← Older revision		Revision as of 21:19, 2 October 2017
Line 83:		Line 83:

	====Value vs complexity====		====Value vs complexity====
	[[File:Value-complexity.png\|thumb\|240px\|'''Figure 05''': Value-Complexity [https://media.licdn.com/mpr/mpr/shrinknp_800_800/AAEAAQAAAAAAAAfUAAAAJGEwMDZhYTFkLTcwOGQtNDQyZi1iOWUxLTQxYjFhZTFkM2NkOA.png]]] This is a well known prioritization tool where the requirements discovered in the brainstorming process are further mapped, possibly with some of the previous methods, on a grid based on their value and complexity. On the one axis you have the complexity of implementing the requirements in the project. This is generally related to technical considerations. Therefor a technical team should be diploid to help create measurables and help define the complexity of each requirement. Value is on the other axis, and can possibly be sought from some of the previously mentioned methods. The project team can also asses the values of the different requirements in terms of project success		[[File:Value-complexity.png\|thumb\|240px\|'''Figure 05''': Value-Complexity [https://media.licdn.com/mpr/mpr/shrinknp_800_800/AAEAAQAAAAAAAAfUAAAAJGEwMDZhYTFkLTcwOGQtNDQyZi1iOWUxLTQxYjFhZTFkM2NkOA.png]]] This is a well known prioritization tool<ref>''Value vs Complexity - A Prioritization Framework. (n.d.). Retrieved September 26, 2016, from http://www.product-arts.com/resourcemain/articlemenu/1049-value-vs-complexity-a-prioritization-framework'' </ref> where the requirements discovered in the brainstorming process are further mapped, possibly with some of the previous methods, on a grid based on their value and complexity. On the one axis you have the complexity of implementing the requirements in the project. This is generally related to technical considerations. Therefor a technical team should be diploid to help create measurables and help define the complexity of each requirement. Value is on the other axis, and can possibly be sought from some of the previously mentioned methods. The project team can also asses the values of the different requirements in terms of project success

	Lastly, reactive expectations management needs to be considered. No matter how well a project is planned, the likelihood of new and or unforeseen requirements is high. For example, as the project moves along, new stakeholders can be identified with changing stages of the project, or changing surroundings, which the project manager has no control over. In such cases, the interpersonal skills of the project manager as well as his communication skills play a big part in controlling the situation.		Lastly, reactive expectations management needs to be considered. No matter how well a project is planned, the likelihood of new and or unforeseen requirements is high. For example, as the project moves along, new stakeholders can be identified with changing stages of the project, or changing surroundings, which the project manager has no control over. In such cases, the interpersonal skills of the project manager as well as his communication skills play a big part in controlling the situation.

Gudjon: /* Stakeholder mapping */

2017-10-02T21:16:52Z

Stakeholder mapping

← Older revision		Revision as of 21:16, 2 October 2017
Line 54:		Line 54:
	* '''Assess how key stakeholders are likely to respond in various situations'''. This is more of an retrospective approach and is intended to prepare the project manager on the best way of dealing with unforeseen problems during the lifetime of the project.		* '''Assess how key stakeholders are likely to respond in various situations'''. This is more of an retrospective approach and is intended to prepare the project manager on the best way of dealing with unforeseen problems during the lifetime of the project.

	Once all of this data has been gathered and processed there are many different ways of mapping the findings. One of the most popular ones, and the one used in this article is the Power/Interest grid ~~shown~~ in ~~Figure~~ 2		Once all of this data has been gathered and processed there are many different ways of mapping the findings. One of the most popular ones, and the one used in this article is the Power/Interest grid.

			A Power/Interest grid is most commonly split up into four quadrants as can be seen in figure 2. Lower left quadrant is the so called monitor quadrant. In this quadrant, stakeholders who have both low interest and low power over the project are placed. The project manager should as it states monitor them, but use as little effort as possible on these stakeholders. Lower right quadrant is the keep informed quadrant. Stakeholders ending there have high interest in the project without having much power or influence. Upper left quadrant is for those stakeholders having a lot of power in the project without necessarily being very interested in it. Lastly the upper right quadrant has arguably the most important stakeholder group and therefor the one most time should be used on satisfying. Those are namely the stakeholders with a lot of interest in the project and great power over it as well.

	Another methodology used to map and or categorize stakeholders is called the stakeholder circle. <ref>'' Lynda Bourne, (2011) "Advising upwards: managing the perceptions and expectations of senior management stakeholders", Management Decision, Vol. 49 Issue: 6, pp.1001-1023, https://doi.org/10.1108/00251741111143658'' </ref>		Another methodology used to map and or categorize stakeholders is called the stakeholder circle. <ref>'' Lynda Bourne, (2011) "Advising upwards: managing the perceptions and expectations of senior management stakeholders", Management Decision, Vol. 49 Issue: 6, pp.1001-1023, https://doi.org/10.1108/00251741111143658'' </ref>
	One of the tools represented here is identification, where the stakeholders are split into 4 types from the perspective of the project manager. Despite the name, this tool is placed under stakeholder mapping and can be seen in figure 2.		One of the tools represented here is identification, where the stakeholders are split into 4 types from the perspective of the project manager. Despite the name, this tool is placed under stakeholder mapping and can be seen in figure 3.

	[[File:Directional mapping.jpg\|thumb\|240px\|left\|'''Figure 03''': Stakeholder directional mapping [http://www.emeraldinsight.com/action/showImage?doi=10.1108%2F00251741111143658&iName=master.img-001.jpg&type=master]]]		[[File:Directional mapping.jpg\|thumb\|240px\|left\|'''Figure 03''': Stakeholder directional mapping [http://www.emeraldinsight.com/action/showImage?doi=10.1108%2F00251741111143658&iName=master.img-001.jpg&type=master]]]

Gudjon: /* Iron Triangle */

2017-10-02T21:06:14Z

Iron Triangle

← Older revision		Revision as of 21:06, 2 October 2017
Line 86:		Line 86:

	====Iron Triangle====		====Iron Triangle====
	[[File:Iron triangle.jpg\|thumb\|240px\|left\|'''Figure 06''': ~~'''Iron~~ triangle~~'''~~ [https://upload.wikimedia.org/wikipedia/commons/a/a6/The_triad_constraints.jpg]]]		[[File:Iron triangle.jpg\|thumb\|240px\|left\|'''Figure 06''': The iron triangle [https://upload.wikimedia.org/wikipedia/commons/a/a6/The_triad_constraints.jpg]]]
	The iron triangle<ref>'' Project management triangle, Retrieved October 2, 2017, from https://en.wikipedia.org/wiki/Project_management_triangle//'' </ref> is a useful model to understand what effects changing expectations can have on a project. It contends that the quality of a project is constrained by the scope, schedule and cost of the project. Furthermore, it states that changing any of the constraining factors necessitates a change in at least one of the other two constraints in order for the quality of the project to stay unchanged. For example, cutting in a project budget without changing the scope or the schedule will come down on the projects quality.		The iron triangle<ref>'' Project management triangle, Retrieved October 2, 2017, from https://en.wikipedia.org/wiki/Project_management_triangle//'' </ref> is a useful model to understand what effects changing expectations can have on a project. It contends that the quality of a project is constrained by the scope, schedule and cost of the project. Furthermore, it states that changing any of the constraining factors necessitates a change in at least one of the other two constraints in order for the quality of the project to stay unchanged. For example, cutting in a project budget without changing the scope or the schedule will come down on the projects quality.

Gudjon: /* Iron Triangle */

2017-10-02T21:05:42Z

Iron Triangle

← Older revision		Revision as of 21:05, 2 October 2017
Line 86:		Line 86:

	====Iron Triangle====		====Iron Triangle====
			[[File:Iron triangle.jpg\|thumb\|240px\|left\|'''Figure 06''': '''Iron triangle''' [https://upload.wikimedia.org/wikipedia/commons/a/a6/The_triad_constraints.jpg]]]
	The iron triangle<ref>'' Project management triangle, Retrieved October 2, 2017, from https://en.wikipedia.org/wiki/Project_management_triangle//'' </ref> is a useful model to understand what effects changing expectations can have on a project. It contends that the quality of a project is constrained by the scope, schedule and cost of the project. Furthermore, it states that changing any of the constraining factors necessitates a change in at least one of the other two constraints in order for the quality of the project to stay unchanged. For example, cutting in a project budget without changing the scope or the schedule will come down on the projects quality.		The iron triangle<ref>'' Project management triangle, Retrieved October 2, 2017, from https://en.wikipedia.org/wiki/Project_management_triangle//'' </ref> is a useful model to understand what effects changing expectations can have on a project. It contends that the quality of a project is constrained by the scope, schedule and cost of the project. Furthermore, it states that changing any of the constraining factors necessitates a change in at least one of the other two constraints in order for the quality of the project to stay unchanged. For example, cutting in a project budget without changing the scope or the schedule will come down on the projects quality.

Gudjon: /* Theory */

2017-10-02T21:00:26Z

Theory

← Older revision		Revision as of 21:00, 2 October 2017
Line 26:		Line 26:

	The iron triangle of the project environment states that success equals "On time, on budget and delivering the specified scope"		The iron triangle of the project environment states that success equals "On time, on budget and delivering the specified scope"

	~~Knowing who the important stakeholders are early in the life of the work, and knowing~~
	~~their expectations, ensures that conflicts can be recognized and addressed proactively.''~~

	===Expectancy Theory===		===Expectancy Theory===

Gudjon at 20:59, 2 October 2017

2017-10-02T20:59:50Z

← Older revision		Revision as of 20:59, 2 October 2017
Line 5:		Line 5:
	A closer look is taken on how different stakeholders will have different expectations within a project, how these stakeholders need to be categorized based on the interest and influence on the project, and how to successfully manage the expectations of different types of stakeholders.		A closer look is taken on how different stakeholders will have different expectations within a project, how these stakeholders need to be categorized based on the interest and influence on the project, and how to successfully manage the expectations of different types of stakeholders.

	Different methods and tools on how to align and manage expectations are introduced and explained. Furthermore, those methods are categorized based on when in the process they are relevant and for what type of stakeholder they are relevant. Limitations to the whole process are ~~examined~~		Different methods and tools on how to align and manage expectations are introduced and explained. Furthermore, those methods are categorized based on when in the process they are relevant and for what type of stakeholder they are relevant. Limitations to the whole process are discussed, in particular the fact that projects vary immensely in size and time-span, as a result, all of the tools can not be used for every project.

	==Introduction==		==Introduction==

Gudjon: /* Value vs complexity */

2017-10-02T20:46:47Z

Value vs complexity

← Older revision		Revision as of 20:46, 2 October 2017
Line 84:		Line 84:

	====Value vs complexity====		====Value vs complexity====
	[[File:Value-complexity.png\|thumb\|240px\|Figure 04: Value-Complexity [https://media.licdn.com/mpr/mpr/shrinknp_800_800/AAEAAQAAAAAAAAfUAAAAJGEwMDZhYTFkLTcwOGQtNDQyZi1iOWUxLTQxYjFhZTFkM2NkOA.png]]] This is a well known prioritization tool where the requirements discovered in the brainstorming process are further mapped, possibly with some of the previous methods, on a grid based on their value and complexity. On the one axis you have the complexity of implementing the requirements in the project. This is generally related to technical considerations. Therefor a technical team should be diploid to help create measurables and help define the complexity of each requirement. Value is on the other axis, and can possibly be sought from some of the previously mentioned methods. The project team can also asses the values of the different requirements in terms of project success		[[File:Value-complexity.png\|thumb\|240px\|'''Figure 05''': Value-Complexity [https://media.licdn.com/mpr/mpr/shrinknp_800_800/AAEAAQAAAAAAAAfUAAAAJGEwMDZhYTFkLTcwOGQtNDQyZi1iOWUxLTQxYjFhZTFkM2NkOA.png]]] This is a well known prioritization tool where the requirements discovered in the brainstorming process are further mapped, possibly with some of the previous methods, on a grid based on their value and complexity. On the one axis you have the complexity of implementing the requirements in the project. This is generally related to technical considerations. Therefor a technical team should be diploid to help create measurables and help define the complexity of each requirement. Value is on the other axis, and can possibly be sought from some of the previously mentioned methods. The project team can also asses the values of the different requirements in terms of project success

	Lastly, reactive expectations management needs to be considered. No matter how well a project is planned, the likelihood of new and or unforeseen requirements is high. For example, as the project moves along, new stakeholders can be identified with changing stages of the project, or changing surroundings, which the project manager has no control over. In such cases, the interpersonal skills of the project manager as well as his communication skills play a big part in controlling the situation.		Lastly, reactive expectations management needs to be considered. No matter how well a project is planned, the likelihood of new and or unforeseen requirements is high. For example, as the project moves along, new stakeholders can be identified with changing stages of the project, or changing surroundings, which the project manager has no control over. In such cases, the interpersonal skills of the project manager as well as his communication skills play a big part in controlling the situation.

Gudjon at 20:45, 2 October 2017

2017-10-02T20:45:30Z

Show changes