Archive:Internal dependencies - simultaneous upgrades - Revision history

wikademia>Wikademia: moved Internal dependencies - simultaneous upgrades to Archive:Internal dependencies - simultaneous upgrades

2009-04-23T05:06:26Z

moved Internal dependencies - simultaneous upgrades to Archive:Internal dependencies - simultaneous upgrades

← Older revision	Revision as of 05:06, 23 April 2009
(No difference)

wikademia>Wikademia at 21:10, 11 April 2009

2009-04-11T21:10:47Z

← Older revision		Revision as of 21:10, 11 April 2009
Line 13:		Line 13:
	\|}		\|}

			{{ntnes}}
	[[Category:(Anti-)Behaviors of business process management program governance]]		[[Category:(Anti-)Behaviors of business process management program governance]]

wikademia>Wikademia: 3 revisions

2009-04-11T05:54:30Z

3 revisions

← Older revision	Revision as of 05:54, 11 April 2009
(No difference)

wikademia>Chungw: added category

2009-04-10T21:55:51Z

added category

← Older revision		Revision as of 21:55, 10 April 2009
Line 12:		Line 12:
	\| [[Charter for conflict resolution\|Charter for Conflict Resolution]]		\| [[Charter for conflict resolution\|Charter for Conflict Resolution]]
	\|}		\|}


			[[Category:(Anti-)Behaviors of business process management program governance]]

wikademia>Chungw: added navigation to parent charter

2009-04-10T19:05:29Z

added navigation to parent charter

← Older revision		Revision as of 19:05, 10 April 2009
Line 5:		Line 5:

	The important thing to note here is that the conflict situation was discovered early. Experienced system architects and business sponsors knew that the platform would periodically require maintenance. Renewal and improvements in the infrastructure were expected and recognized as important to the success of the effort. They then established a plan by which those upgrades could occur with minimal friction from active project teams.		The important thing to note here is that the conflict situation was discovered early. Experienced system architects and business sponsors knew that the platform would periodically require maintenance. Renewal and improvements in the infrastructure were expected and recognized as important to the success of the effort. They then established a plan by which those upgrades could occur with minimal friction from active project teams.


			== Applies to ==
			{\|
			\| [[Image:Resolution.gif\|left\|link=Charter for conflict resolution]]
			\| [[Charter for conflict resolution\|Charter for Conflict Resolution]]
			\|}

wikademia>Chungw: Initial behavior page

2009-04-10T16:21:13Z

Initial behavior page

New page

== Summary ==
With a shared BPM infrastructure, conflicts tend to arise when shared assets require changes. The shared assets even include software versions for the platform infrastructure. The questions that arise include ownership and cost allocation of regression testing, hardware upgrades, and more.

One organization established a regular maintenance cycle under which the software platform and shared modules would be refreshed. Every project team built into their project timelines regression testing and upgrade activities. If a specific business objective was going to be sufficiently delayed such that a schedule adjustment was warranted the project team could request a postponement.

The important thing to note here is that the conflict situation was discovered early. Experienced system architects and business sponsors knew that the platform would periodically require maintenance. Renewal and improvements in the infrastructure were expected and recognized as important to the success of the effort. They then established a plan by which those upgrades could occur with minimal friction from active project teams.