View source for Charter for business process management investment

== Related lessons ==
{|
| [[Image:Charters.gif|left|link=The charters for bpm program governance - an overview]]
| [[The charters for bpm program governance - an overview|The Charters for BPM Program Governance - An Overview]]
|-
| [[Image:Engine.gif|left|link=Charter for the bpm engine]]
| [[Charter for the bpm engine|Charter for the BPM Engine]]
|-
| [[Image:DemocracyGlobe.gif|left|link=Charter for bpm democracy]]
| [[Charter for bpm democracy|Charter for BPM Democracy]]
|-
| [[Image:Alignment.gif|left|link=Charter for alignment]]
| [[Charter for alignment|Charter for Alignment]]
|-
| [[Image:Resolution.gif|left|link=Charter for conflict resolution]]
| [[Charter for conflict resolution|Charter for Conflict Resolution]]
|-
| [[Image:Investment.gif|left|link=Charter for bpm investment]]
| [[Charter for bpm investment|Charter for BPM Investment]]
|-
|
| [[A charters glossary|A Charters Glossary]]
|}


== Executive Summary ==
The investment strategy governs how quickly the BPM program can become operational and deliver value in a repeatable fashion.  As a BPM program matures, it will require different investments than it did at inception.  This Charter examines the types of investments that are needed, from where those investments will be sourced, and considers the time element.

It is disadvantageous to ramp up too slowly.  The benefits of a BPM program would not be maximized and could potentially cost the organization any potential competitive edge provided by the selected opportunities.  Similarly, attempting to ramp up too quickly will incur inefficiencies and excessive costs.  Returns would be diminished.

A funding model for each stage is explored.  It is essential that the Leadership team can effectively identify in which stage a program exists and knows ways to get it to the next stage.


== Objectives ==
This Charter
*Explains a simplified diffusion curve for program maturity,
*Defines standardized criteria for identifying each transition boundary, and
*Discusses how to accelerate the evolution process in a manageable fashion.


== Scope ==
The stages of BPM program maturity are described with their identifying characteristics.  As a program evolves, its progress on the maturity curve can be measured.  The investment model must change according to the current and the future needs of the program.


== Plan ==

=== The Maturity Curve ===
[[Image:BPM_Maturity_Curve.png|thumb|none|Simplified, three-stage maturity curve for a BPM program.]]


<center>
{| border=1 cellspacing=0 cellpadding=5|| style="width:800px"
| bgcolor="gray" | <center><font color="white">'''Characteristic'''</font></center>
| bgcolor="gray" | <center><font color="white">'''Validate'''</font></center>
| bgcolor="gray" | <center><font color="white">'''Adopt'''</font></center>
| bgcolor="gray" | <center><font color="white">'''Transform'''</font></center>
|-
| '''General'''
|
|
|
|-
| ''Major Theme''
| valign="top" | Execution Capability
| valign="top" | Capacity and Application
| valign="top" | Linking Strategy to Execution
|-
| ''Description''
| valign="top" | A limited number of opportunities are selected for implementation in this stage.  A small engine is used to deliver these solutions and prove the viability of BPM within the organization.  The affected population is usually constrained until the organization is comfortable advancing to ''Adopt''.
| valign="top" | Technical bandwidth and operational readiness are increased during this stage.  Challenges have been identified, and remediation techniques have been established allowing projects to be executed efficiently. The daily lives of more users are affected by implemented solutions.
| valign="top" | The program now provides the accepted approach to solving business problems.  There are a well-defined method for opportunity selection, a pipeline full of prioritized opportunities, and a machine executing on those projects.  Business decisions are made possible by the production solutions and the exposed information.
|-
| ''Stage Maturity''
| valign="top" | The organization can advance to the next stage when capability has been demonstrated.  During this stage the
*Leadership tier is organized,
*Execution tier is started at the solution level,
*People are trained and gain some (albeit limited) experience,
*Tools are selected,
*High-level methods are selected,
*Obstacles are identified and remediation is planned, and
*A timeline is established for ''Adopt''.
| valign="top" | The organization can advance to the next stage when capacity has been demonstrated.  During this stage the
*Execution tier is grown sufficiently to meet demand,
*Opportunity selection criteria are defined to manage demand,
*Validation guidelines are put in place, and
*Continuing funding is secured.
| valign="top" | N/A
|-
| ''Objective''
| valign="top" | '''Prove Value and Suitability''' - To verify that BPM is an approach that can be used within the organization by proving technical and operational capabilities.  Starting with a baseline methodology the selected pilot solutions are delivered.  An ''Adopt'' plan that addresses organizational issues is drafted.
| valign="top" | '''Embed in Core Operations''' - To begin applying the methodology, tweaking it where necessary to gain acceptance.  A balance must be struck between the demands of opportunity management and the availability of people and infrastructure.  The long-term funding model must be established.
| valign="top" | '''Drive and Align Direction''' - To operate in a manner where business priorities drive project execution, which in turn produces benefits and capabilities back to the business.  Established methods and reliable tooling are provided.  The pipeline is being addressed in a continuous fashion.
|-
| ''Focus''
| valign="top" | [[Image:BPM_Focus_Validate.png|none]]
The focus is on delivering individual solutions.  Limited attention is paid to centralizing aspects of the program until demonstrable results are imminent.
| valign="top" | [[Image:BPM_Focus_Adopt.png|none]]
Focus shifts to identifying items that can be shared, like infrastructure and coordinating bodies.  Execution still occurs in a distributed fashion, but common items are consolidated for better leverage and efficiency.
| valign="top" | [[Image:BPM_Focus_Transform.png|none]]
The focus is on selecting and delivering the right opportunities, something that requires ongoing coordination from a centralized vantage point.
|-
| ''Typical Timeframe''
| valign="top" | 12-18 months
| valign="top" | 12-24 months
| valign="top" | ongoing
|-
| ''Solution Types''
| valign="top" | '''Proof Points''' - Solutions include those that can be realistically delivered in the timeframe of this stage.  This means that they may not deliver strategic benefits and may not even align with top-level objectives.  The focus is on proving the viability of the BPM program with real-world process problems.

Unless executed flawlessly, excessively large opportunities will hinder the program.  Sometimes the solutions in this stage are even discarded as learning exercises.  It is critical that opportunities be selected based on their likelihood for success.
| valign="top" | '''Mission Critical''' - Solutions include those that stress strategic importance while still providing a suitable learning environment for new people joining the engine.  The level of complexity is restricted to the capacity of the existing expert team.

The solutions begin forcing roadmap discussions for the program.  Possible opportunities are identified for later investment with clear milestones for achieving specific objectives.  This stage sees the refinement of a Demand Management approach for selecting and prioritizing opportunities that impact top-level objectives and goals.
| valign="top" | '''Decision-Enabling''' - Only prioritized opportunities that deliver strategic value are selected in this stage.  Business decisions are possible because of the process solutions.  The pipeline is composed of new opportunities and continued extensions of existing solutions, with both sets being prioritized and selected based on strategic benefit.
|-
| ''Solution Visibility''
| valign="top" | There is limited enterprise-level visibility for the ''Validate'' solutions.
| valign="top" | There is increased enterprise-level visibility for the ''Adopt'' solutions, primarily when there are production issues.
| valign="top" | There is consistent enterprise-level visibility for the ''Transform'' solutions because they actually enable business decision-making.
|-
| '''Engine - People'''
|
|
|
|-
| ''Skills Spectrum''
| valign="top" | [[Image:BPM_People_Validate.png|none]]
| valign="top" | [[Image:BPM_People_Adopt.png|none]]
| valign="top" | [[Image:BPM_People_Transform.png|none]]
|-
| ''People''
| valign="top" |  There is usually a small team that has taken the initiative to prove BPM.  This group of Innovators and Early Adopters will usually have more to accomplish than they can realistically deliver in a short timeframe.  In later stages, these people become the core team.  These participants tend to be borrowed from the specific business units who will benefit from the solutions.
| valign="top" | The experience from the ''Validate'' stage provides resources who form the core part of the engine.  These experts lead projects in this stage, helping to grow the engine's capabilities.  Some experts continue to focus on the innovation, pushing the boundaries of the program and increasing the opportunities that can be addressed. The core team members are usually pulled from their originating organizations to form a centralized pool.
| valign="top" | The engine is fully staffed and can operate largely independently.  The core team is allocated to projects but eventually return to the shared body.  Upon returning their primary task is to increase the body of knowledge.
|-
| ''Vendor Involvement''
| valign="top" | Vendors tend to provide a wide range of services in this stage.  Training in tooling, mentorship on operational aspects, expert guidance, and staff augmentation are seen.  This stage has the highest dependence on vendors because the engine is only getting started.
| valign="top" | Vendors provide services to offset the differences between the demands imposed on the program and the current capabilities of the engine.  As capacity of the internal organization increases, an organization relies less upon vendors.  The lingering areas of dependence will be in continuing training of previously unseen areas of the program and also on staff augmentation for critical projects.
| valign="top" | Expert services and continuing training, especially with new software releases and capabilities, are the dominant area for vendor involvement.  Occasionally, staff augmentation is still necessary for urgent situations, but an organization can already balance supply and demand at this stage to reduce that dependency.
|-
| '''Engine - Tools'''
|
|
|
|-
| ''Software''
| valign="top" | Primary focus is on an execution environment.  Minimal attention is paid to process selection and to optimization.  Such product capabilities are included in evaluation but are limited to conceptual and prototypical deliverables.
| valign="top" | This stage requires some experimentation with more expansive capabilities so that a portfolio management discipline can be established.  Software requirements begin to include capabilities for
*Prioritization and selection of opportunities that align to strategic objectives,
*Concurrent project development with capability for sharing assets, and
*Validation of results and identification of further improvement opportunities.
| valign="top" | The software is married with the methods that have been established.  Opportunities must
*Clearly demonstrate how the solution outputs align with strategic goals and address problems,
*Leverage common artifacts to reduce time-to-delivery and to increase consistency with other solutions, and
*Provide business owners a better understanding of where the processes have improved or where further investment is needed.
|-
| ''Infrastructure''
| valign="top" | Infrastructure is rarely shared at this stage for the pilot solutions.  Participating departments look to quickly get environments up and running to support these solutions.  However, initial work on shared infrastructure begins at this stage to determine what obstacles might be encountered during ''Adopt''.
| valign="top" | Infrastructure begins moving to a shared model, especially for common resources like hardware and support staff.  Cost models are examined for how shared infrastructure might be accomplished.
| valign="top" | A centralized infrastructure is in place with procedures for gaining access, measuring usage, and allocating costs.
|- 
| ''IT Landscape''
| valign="top" | [[Image:BPM_Landscape_Validate.png|none]]
The BPM program usually leads the IT systems.  Dependencies on IT availability restrict what functionality can be used in the pilot solutions.  Some integrations and leverage are possible either from previous projects or with restricted functionality.
| valign="top" | [[Image:BPM_Landscape_Adopt.png|none]]
IT teams scale up in parallel to the BPM program.  The BPM opportunities begin filling the IT development pipeline with candidate functionality, and IT is able to estimate required investment to support those BPM opportunities.
| valign="top" | [[Image:BPM_Landscape_Transform.png|none]]
The IT development pipeline is in lock-step with the BPM program pipeline.  Systems are exposed for integration as determined by business priorities.  Total costs for the IT capabilities are included in assessments of the BPM opportunity benefits.
|-
| '''Engine - Methods'''
|
|
|
|-
| ''Approach''
| valign="top" | Existing methods are the basis for execution.  Some attention is paid to agility, and some new techniques are introduced and attempted.  The key outcome is a list of areas in which the approach and existing methods will need to change.
| valign="top" | Attention is on consolidating lessons learned and on adapting new methods to cultural specifics.  Best practices are established, largely in response to successes and failures of the completed BPM solutions.
| valign="top" | An adapted methodology is available to all program members.
|-
| '''Funding'''
|
|
|
|-
| ''Sources''
| valign="top" | Business units with specific tactical projects to deliver are often the ones that first invest in BPM.  These organizations are tasked with delivering their projects while validating that BPM is a viable approach.
| valign="top" | As solutions start to become more critical to the organization and the concept of process-oriented behaviors start to become adopted, centralized organizations start to form.  The centralized body may still receive its pool of money from specific business units interested in process solutions, but the centralized body starts allocating the funds.
| valign="top" | In this operational steady-state the centralized organization usually has a top-level budgetary line item for funding.
|-
| ''Distribution''
| valign="top" | This funding is often project-based and obtained in a piecemeal fashion as project costs are identified.
| valign="top" | The allocation is often done in two stages.  First funds are secured for some period of time, usual linked to fiscal budgeting years.  The size is based on rough estimates of the costs anticipated.  Second, as opportunities arise the distributions are provided as needed and tied to specific deliverables, which are more easily estimated in an accurate fashion when closer to the project initiation.

Some organizations refer to this arrangement as a ''framework agreement'' when used in the context of vendor distributions.
| valign="top" | The two-stage allocation model from ''Adopt'' is used but on a larger scale.
|-
| ''Project Teams''
| valign="top" | With no proven internal track record, business and IT are limited in their ability to invest.  People investments are in the form of time-boxed loans to pilot projects.  These individuals require training and assistance in the delivery of the solutions.   Both business and IT teams provide these investments in people and money.
| valign="top" | Some ''Validate'' resources return to their originating organizations, but others form the core part of the engine.  Experienced seeds plus new team members form the new project teams, increasing the range of skills.  The new team members learn through a combination of formal training and side-by-side collaboration.
| valign="top" | Project teams continue to be seeded by people who have contributed to completed solutions.  Education is provided through internal and external mechanisms.
|-
| ''Supporting Teams''
| valign="top" | The project teams are dependent on support resources who are dedicated neither to the pilot projects nor to the BPM program.  These resources are borrowed for specific tasks that must be scheduled in competition with other activities.
| valign="top" | Program growth encourages certain supporting functions to become centralized, such as infrastructure support for the BPM software.
| valign="top" | Dedicated support services are in place because the BPM operations are essential to business operations.
|-
| ''Infrastructure''
| valign="top" | Existing, or easily acquired, infrastructure is used.  Truly highly available and geographically redundant infrastructure is not generally addressed in this stage.  ''Validate'' business groups pay for these costs.
| valign="top" | The infrastructure is grown. This includes more development and test environments as well as increasing capacity of the production infrastructure.  Reuse of existing BPM environments that have spare capacity encourages centralized funding for the infrastructure.  IT begins to consider a line item for BPM infrastructure.
| valign="top" | Multiple infrastructure environments are available based on the SLA requirements of solutions.  High availability is provided for the mission critical solutions.  These environments are provided by a central fund that is sourced either by the impacted business units or as a top-level budgetary line item.
|-
| ''Software''
| valign="top" | Limited licenses are acquired.  Costs are allocated to the project organizations.
| valign="top" | Existing licenses or add-on licenses are used.  Costs are allocated to the project organizations with common assets funded by centralized funding sources.
| valign="top" | A centralized fund is used for software costs based on expected usage, which is determined from the pipeline.  This centralized fund is sourced either by the business units or as a top-level budgetary line item.
|}
</center>


=== Implementation ===
The steps should be common across organizations.  The only difference is the pace of evolution which is determined by how quickly these steps can be practically completed.

==== From ''Validate'' to ''Adopt'' ====
*Determine the critical success factors for the ''Validate'' stage.  What are the functional capabilities and operational capabilities that must be proven to advance to ''Adopt''.
*Pick opportunities that are quickly delivered to meet the critical success factors above.  This may mean that necessary integrations already exist or that the solutions rely on limited integration functionality.
*Provide infrastructure support to the BPM project teams.  Let them focus on solution delivery.
*Dedicate subject matter experts who are familiar with the operations being addressed by the ''Validate'' opportunities.  If these resources are not available to quickly and to readily address questions and to clarify requirements then that only slows down the ride up the maturity curve.
*Develop and communicate on the roadmap for solutions.  Not all features need to be delivered in the first release.  It is important to set the expectation that BPM projects are ongoing and will deliver production functionality with regular releases rather than with a monolithic release.
*Select tools that support rapid delivery and complement the methods chosen.
*Prioritize benefits of the selected opportunities against benefits to the program.  It might be more important to uncover some program obstacles than to deliver a specific feature in the solution.  The long-term advantage might be leveraged across solutions.
*Invest in the IT capabilities and capacity ahead of the BPM demand.


==== From ''Adopt'' to ''Transform'' ====
*Pull the experts out of their originating business units.  Place them in the core engine, and coach them on how to ramp up other individuals.  This preserves the momentum established earlier in the program.
*Establish sharing guidelines that allow for leverage and reuse of common assets.  If the common repository of shared assets is of a reasonable size consider investing in a team to maintain and to enhance those assets.
*Establish prioritization guidelines for interactions between the BPM program and other programs.  This is discussed further in the [[Charter for conflict resolution|Charter for Conflict Resolution]].
*Establish a funding model that supports ongoing projects and their roadmaps.  Analyze and prioritize the requirements roadmaps for possible further benefit to the organization.  If the benefits are prioritized higher than those of other opportunities then consider continuing the project, especially while the solution team is still intact.
*Include refresh cycles in the funding model such that the infrastructure and tooling are regularly improved.
*Provide education and training options for both the new and existing members of the engine.
*Communicate the benefits and the progress so that it is clear how an inclusive BPM program benefits everyone in the organization.


== Assumptions ==
*Too often, opportunities are funded for a limited time period that neglects the overall program and organizational benefits.  This is sometimes due to fiscal timelines and to a lack of discipline about prioritizing opportunities.  Those opportunities that can clearly demonstrate an alignment with strategic goals and can deliver on a regular, frequent cadence should be provided continuing funding.  BPM solutions provide increasing returns with each release.  This is usually because the early releases provide a functional baseline whereas the subsequent releases add the management capabilities.
*For a continuous funding model to work, there must be regular reviews to ensure that the solutions still provide the anticipated benefits.  Do not be afraid to enforce the reviews frequently and to terminate the projects if they no longer align.  In conjunction with a centrally funded model this technique can quickly mobilize other opportunities that move forward in the priority queue.
*The model presented in this Charter is expected to deviate in practical application.  Some organizations will find that some aspects occur sooner and others later.


== (Anti-)Behaviors ==

=== Behaviors ===
*[[Sharing - infrastructure cost models|Sharing - Infrastructure Cost Models]]
*[[Staging platform growth|Staging Platform Growth]]

=== Anti-Behaviors ===

== Conclusions ==
A comprehensive program maturity lifecycle covers three stages: ''Validate'', ''Adopt'', and ''Transform''.  The source of investment at each stage is a result of the types of activities and the desired outcomes for that stage.

The ''Validate'' stage almost necessitates a distributed investment model.  People, infrastructure, and cash funding have to come from the few groups who are interested in the success of the solutions.

As the organization's appetite for BPM increases and as the pipeline depth increases, it makes sense to begin consolidating assets that can be better leveraged.  This includes the people who now have experience, and it includes the infrastructure that has been started for the pilot solutions but that may still have capacity.

During ''Transform'', as more programs come onboard, the Leadership team can use a centralized funding pool to manage the demand pipeline.  The actual source of the funds during ''Adopt'' and ''Transform'' may come from the increasing the number of teams that participate in the BPM program, or it might be provided as a top-level line item.


== Lesson exercises ==



[[Category:Charters for business process management program governance]]