Trip Report : Day One of Gartner BPM Conference

Marius Grigoriu here....

I am a Program manager with CISG and in keeping with good program management its straight down to business. Today was the first official day of the Gartner BPM Conference at Washington DC and I am posting daily trip reports. In the Connected Information Security Group we believe that BPM or Business Process Management is key to the future of information security management.

Three recurring themes emerged from the different presentations given today:

1) Staffing

2) Agility

3) Continuous process improvement

Themes:

Staffing:

Getting the right mix of people working on the BPM project is critical for success. Just throwing the smartest people in a room is a recipe for frustration without the proper roles, skills, and authority. At a minimum, BPM projects should include a business process owner, implementation lead, developers, SMEs, and an executive sponsor. The business process owner is the team member belonging to the business who has knowledge of the business process and has the authority to make changes to the process as necessary. The process owner defines the process being input into the BPMS and also drives adoption of the system in the business organization. The implementation lead is much like our program manager role on the CISG team. They work with the business process owner to model the process, collect other requirements, drive the creation of the solution. Somewhat misleading is the title as an implementation lead does not drive adoption within the business, but must work closely with the process owner to accomplish the task. “Developers” are not just devs, but includes the entire team necessary to support the development effort: architecture and design, development, testing, and appropriate management. Not mentioned were the IT operations staff members who should also be included and finally is executive sponsorship. SMEs are the team members who know the most about the as-is process including any undocumented and unofficial processes still necessary to their team’s operations. The executive sponsor must be dedicated and willing to make hard decisions to push the project forward. By nature process decisions are decisions about people’s jobs, which can become contentious at times. It was mentioned that an absent or hesitant executive sponsor is a show stopping danger sign --the executive sponsor must be 100% behind a BPM implementation project to succeed.

Agility:

Multiple speakers have mentioned the important of agility in implementing BPM. First, one of the general goals of BPM is to enable businesses to improve (read change) their processes through the collection of data and to decrease the cost of IT changes (vs. the monolithic LOB app). Thus one of the points of implementing BPM is to facilitate business change and agility. Next is that waiting for perfection in requirements and process documentation/modeling is counterproductive. Teams may contains unknown, unofficial sub-processes which are hard to discover even with SMEs on the team. At some point, perfecting requirements and designs require much more time for an incremental change in value. Playbacks such as rapid prototypes and iterative releases should be used to frequently obtain feedback along the journey. It is important to note that iterative releases are not the same as planned staged releases. The latter is executing on a pre-determined plan created with information from the early phases of the project. The former is about inspecting the work delivered, identifying gaps and areas of improvement, then addressing those issues. A BPM project is not a “once and done” implementation project like many other IT projects that are developed then put into sustained engineering mode. Even after iterations have completed, one or two dedicated resources will need to be available to handle continuous improvement process changes.

Continuous Process Improvement:

Related to agility is CPI, the #1 recurring topic so far and one of the big benefits of implementing BPM. CPI is made possible by the metrics and process visibility created by implementing and running BPM solutions. However this implies that resources need to stay on project after implementation to make the changes resulting from additional process analysis. As processes change, so will the system, and the BPM implementation needs to be build in a way that can accept change. Re-useable components and the use of BPM/rules engines to move away from business logic built-into application code have been mentioned as a way to achieve lower IT change costs.

10 Habits of Successful Organizations Building BPM solutions:

1. Make BPM about productivity AND visibility:

• Metrics, KPI, SLAs, should be part of the defining the process
• Try not to scope out metrics

2. Integration

• Don’t underestimate the effort required to integrate systems and start early
• But don’t get bogged down either – don’t let that delay your first project (which should be a low risk, high impact project)
• Be ready to trade off integrations that stand in the way of a timely release

3. Never a “one and done” project

• Iterative approach to process improvement and bpm systems

4. Don’t skip process analysis

• Requirements are not the same as process analysis

5. Take time to deliver value

• Taking longer than 90 days to deliver is not a failure
• Use timeline as a box in which to deliver your value

6. Build a complete team

7. Self-sufficiency is a priority

• FTEs are necessary to build organizational capability
• Partially allocated FTEs are not good enough – they need to be committed to the project

8. Fund to value, not just the first release

• Big challenge as IT funding tends to be per project usually just for a first release
• To obtain the benefits of CPI, maintenance should is not a sleeper like for may be in other applications

9. Force collaboration, use playbacks and iterations to create tangible results for frequent validation

10. Set owners for the program, process, and technology

Thanks for reading, lots more tomorrow.

Marius