If you are new to BPM and just starting your journey, you need to charter a project and ask for a budget. You might have a great story about business value and business impact, but your request for funding is incomplete without a ROI case that includes the cost and time associated with discovering, implementing, and deploying a business process with IBM Business Process Manager.

If you have already started your BPM journey, you have experienced the success of at least one project. The attention that the project has garnered from stakeholders, executive management, and business users has generated a flood of new requests for BPM in other areas of your business. You need to estimate the scope of these incoming project requests as you build a process inventory. You need to assess each process before you can allocate resources for further process discovery and begin implementation.

An organization that has both experience and success in Agile Software Development techniques already has a different perspective on scope. Of the three variants in the iron triangle of project management, scope is the only one we can manage.

Managing scope through better estimating techniques with transparency in both accuracy and precision better supports decisions that impact project cost and schedule. Essentially, we can manage project cost and schedule only by improving the way we estimate projects. We should concentrate on making our estimates more accurate and more precise, but accept uncertainty, and make decisions based on an appropriate level uncertainty as our knowledge of the process improves throughout the lifecycle of the project.

Few organizations have made a complete transformation to Agile Software Development. In BPM, having access to a business process management system (BPMS) does not mean that you are practicing BPM. Similar to BPM, using one of the many available tools or add-on packages for agile project management does not mean that your organization is agile. Like BPM, it takes time for your organization to adopt agile techniques, adjust to a method that works for your projects, and refine your method so that it is repeatable.

The organization that is new to agile software development, or has experimented with agile software development with limited success, relies on estimating methods that are more familiar. In the sections that follow, the budgetary estimate typically meets the needs of project stakeholders to charter a project, approve a budget, and staff resources. The budgetary estimate described in this book does, however, place an emphasis on quantifying and exposing uncertainty, which is a concept that is pivotal in agile software development.

Perhaps history and politics have strained the relationship between the operational business and the internal IT department. Sometimes contractual relationships, such as those with vendors or Business Partners, do not support agile software development. Often the capital expenditure process internal to your organization does not support funding projects (or large programs) without clear definition of scope up front.

These factors do not mean that agile software development cannot work in these environments. It means that it might take time to repair relationships and build trust. It means that vendors and partners need to constantly improve estimating with accuracy and precision and make it transparent when delivering estimates. It means that you need to accommodate our internal capital expenditure process but direct focus on the business value and impact within cost and scheduling constraints.