Archive:An engine structured for success - Revision history

wikademia>Wikademia: moved An engine structured for success to Archive:An engine structured for success

2009-04-12T03:40:50Z

moved An engine structured for success to Archive:An engine structured for success

← Older revision	Revision as of 03:40, 12 April 2009
(No difference)

wikademia>Wikademia at 20:40, 11 April 2009

2009-04-11T20:40:15Z

← Older revision		Revision as of 20:40, 11 April 2009
Line 15:		Line 15:

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

wikademia>Wikademia: 6 revisions

2009-04-11T05:54:26Z

6 revisions

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

wikademia>Chungw: added category

2009-04-10T21:44:54Z

added category

← Older revision		Revision as of 21:44, 10 April 2009
Line 12:		Line 12:
	\| [[Charter for the bpm engine\|Charter for the BPM Engine]]		\| [[Charter for the bpm engine\|Charter for the BPM Engine]]
	\|}		\|}


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

wikademia>Chungw: added navigation to parent charter

2009-04-10T18:59:48Z

added navigation to parent charter

← Older revision		Revision as of 18:59, 10 April 2009
Line 5:		Line 5:
	#The projects had a fixed duration and a fixed team size. That meant that the scope had to be sufficiently managed across releases. A specific release had to deliver a certain benefit back to the organization. If it did then further investment would be considered for the remainder of the project roadmap. If it did not then it was terminated early. Certainly there were potential losses from failed projects, but these losses were minimized compared to multi-year projects that fail after millions of investment.		#The projects had a fixed duration and a fixed team size. That meant that the scope had to be sufficiently managed across releases. A specific release had to deliver a certain benefit back to the organization. If it did then further investment would be considered for the remainder of the project roadmap. If it did not then it was terminated early. Certainly there were potential losses from failed projects, but these losses were minimized compared to multi-year projects that fail after millions of investment.
	#The Demand Management method sometimes selected non-software projects. Every opportunity was weighed not only on the benefits it would bring to the organization but also by the cost of the project. Some operational changes were aggregated into process improvement projects, delivered benefit for the business, and represented success for the program.		#The Demand Management method sometimes selected non-software projects. Every opportunity was weighed not only on the benefits it would bring to the organization but also by the cost of the project. Some operational changes were aggregated into process improvement projects, delivered benefit for the business, and represented success for the program.


			== Applies to ==
			{\|
			\| [[Image:Engine.gif\|left\|link=Charter for the bpm engine]]
			\| [[Charter for the bpm engine\|Charter for the BPM Engine]]
			\|}

wikademia>Chungw at 20:05, 9 April 2009

2009-04-09T20:05:07Z

← Older revision		Revision as of 20:05, 9 April 2009
Line 5:		Line 5:
	#The projects had a fixed duration and a fixed team size. That meant that the scope had to be sufficiently managed across releases. A specific release had to deliver a certain benefit back to the organization. If it did then further investment would be considered for the remainder of the project roadmap. If it did not then it was terminated early. Certainly there were potential losses from failed projects, but these losses were minimized compared to multi-year projects that fail after millions of investment.		#The projects had a fixed duration and a fixed team size. That meant that the scope had to be sufficiently managed across releases. A specific release had to deliver a certain benefit back to the organization. If it did then further investment would be considered for the remainder of the project roadmap. If it did not then it was terminated early. Certainly there were potential losses from failed projects, but these losses were minimized compared to multi-year projects that fail after millions of investment.
	#The Demand Management method sometimes selected non-software projects. Every opportunity was weighed not only on the benefits it would bring to the organization but also by the cost of the project. Some operational changes were aggregated into process improvement projects, delivered benefit for the business, and represented success for the program.		#The Demand Management method sometimes selected non-software projects. Every opportunity was weighed not only on the benefits it would bring to the organization but also by the cost of the project. Some operational changes were aggregated into process improvement projects, delivered benefit for the business, and represented success for the program.


	~~== Discussion ==~~
	~~Please sign and date comments added to this behavior.~~

wikademia>Chungw at 20:01, 9 April 2009

2009-04-09T20:01:32Z

← Older revision		Revision as of 20:01, 9 April 2009
Line 1:		Line 1:
	~~[[Category:Business process management program governance]]~~
	== Summary ==		== Summary ==
	One particular Leadership tier sufficiently constrained the program operations such that projects would either deliver benefit or be terminated after only limited investment. How were they able to do this?		One particular Leadership tier sufficiently constrained the program operations such that projects would either deliver benefit or be terminated after only limited investment. How were they able to do this?

wikademia>Chungw at 20:00, 9 April 2009

2009-04-09T20:00:09Z

← Older revision		Revision as of 20:00, 9 April 2009
Line 1:		Line 1:
	[[Category:~~Charters for bpm~~ program governance]]		[[Category:Business process management program governance]]
	~~[[Category:Charters behavior]]~~
	~~[[Category:Charter for the bpm engine~~]]
	== Summary ==		== Summary ==
	One particular Leadership tier sufficiently constrained the program operations such that projects would either deliver benefit or be terminated after only limited investment. How were they able to do this?		One particular Leadership tier sufficiently constrained the program operations such that projects would either deliver benefit or be terminated after only limited investment. How were they able to do this?

wikademia>Chungw: Behavior added

2009-04-09T19:55:32Z

Behavior added

New page

[[Category:Charters for bpm program governance]]
[[Category:Charters behavior]]
[[Category:Charter for the bpm engine]]
== Summary ==
One particular Leadership tier sufficiently constrained the program operations such that projects would either deliver benefit or be terminated after only limited investment. How were they able to do this?

#The Executive Sponsor required that each project had a single process owner. In the model outlined in this Charter, this process owner served as the Business Owner. They were empowered by the Leadership tier to make all decisions for the project, even though those decisions might span multiple functional areas.
#The projects had a fixed duration and a fixed team size. That meant that the scope had to be sufficiently managed across releases. A specific release had to deliver a certain benefit back to the organization. If it did then further investment would be considered for the remainder of the project roadmap. If it did not then it was terminated early. Certainly there were potential losses from failed projects, but these losses were minimized compared to multi-year projects that fail after millions of investment.
#The Demand Management method sometimes selected non-software projects. Every opportunity was weighed not only on the benefits it would bring to the organization but also by the cost of the project. Some operational changes were aggregated into process improvement projects, delivered benefit for the business, and represented success for the program.

== Discussion ==
Please sign and date comments added to this behavior.