The Connected Information Security Group : Program Management

Trip Report : Day Three of Gartner BPM Conference

cisg — Tue, 16 Sep 2008 13:27:16 GMT

Marius here again.....

Highlights:

On average, 80% of the IT budget goes toward maintenance and only 20% goes to new projects. On top of that, IT budgets keep shrinking year after year. This creates a big challenge in funding large initiatives like BPM. IT projects for cost reduction have been successful in the past, but has also resulted in budgets being cut. There are still pocket areas of opportunities for cost reduction, but much of the cost has been squeezed out already. Automation projects are experiencing diminishing returns. IT must now focus on business value generation, and that starts with the business process. BPM is not just about automation, but also about providing businesses information to make better decisions, change faster, and experiment. The future of risk analysis is to apply risk factors to a business process and run simulations to understand the impact.

Analyst predictions of the future:

The following predictions are worded in a way to spark discussion and you may not agree with each of the statements.

“BPM will fail at process improvement as a primary goal. Instead it will create an organizational capability as a part of the implementation journey – collaboration.”

The argument here is not that BPM will fail, but instead one of the side effects of implementing BPM will have a greater impact. The speaker argues that companies do not collaborate well enough today, but they will be required to collaborate better in the future. In the process of implementing BPM, organizations will develop a greater capacity to collaborate, not from the software, but from working on the implementation. BPM’s benefits go well beyond process improvement, making it worthwhile every step of the way.

“Current methodologies and tools for modeling will become obsolete in 5 years because process will become less predictable rather than more.”

“By 2015, enterprises that do not accept greater failure rates will lose the opportunity for success.”

This quote seems contradictory at first, but the supporting argument states that BPM’s ability to drive process change at higher frequencies combined with increasing computing power and collections of data results in the ability to carry out simulations and experiments. Simulations are an inexpensive way to explore options in pursuit of optimizing the business. The majority of the simulations will result in failures, but the failure is quick and the business is able to move on to the next idea. If a process change is applied and fails in the real world, BPM will again allow the enterprise to see the failure quickly and move away from it sooner. If the concept of quick failure being good is difficult to accept, consider the pharmaceutical companies who must test their drugs before going to market. Ideally, if there is going to be a drug failure (unacceptable side effects) that the failure occurs quickly and not years after being released to consumers.

Closing remarks:

BPMS are not just business applications like the majority in production today. They give IT the ability to once again become a business enabler. BPM does not mean that businesses will create new software systems without IT by drawing pictures and not writing any code. No -- IT and businesses will jointly use BPMS to create integrated process-based applications in a way that’s faster and cheaper than traditional development approaches. The cost of IT change must go down (80% of the budget) and BPM allows the business to play an active role.

Trip Report : Day Two of Gartner BPM Conference

cisg — Fri, 12 Sep 2008 12:18:43 GMT

Hi Marius here again with highlights from day 2 of the Gartner BPM conference.

Back of the Napkin

You may have heard of the book called The Back of the Napkin: Solving Problems and Selling Ideas with
Pictures. It’s one of the latest books creating a buzz in business community. Dan Roam, the author
of the book presented on how the most daunting business problems can be described simply using
only stick figures in the space of a few square inches available on the back of a napkin. Ultimately,
those who present the problem the best get the funding to proceed with their project. Dan argues that
there are three types of people. Those who immediately jump to the whiteboard and start sketching
in meetings (25% of us), those who are not artistic BUT will highlight what’s interesting (50% of us), and
finally those who are not artistic and simply refuse to participate in the process (the remaining 25%).
Those who highlight don’t come up with new ideas, but they are good at dissecting ideas presented to
them and highlight what really matters. Those who refuse to sketch do so because they understand
that what’s being drawn is far too simplistic to be reality. These people tend to have the most facts on
the problem. When they compare the drawings to their own information, they are turned away from
the conversation. The challenge is to find a way to involve these people, and the solution presented
was to (don’t read if you’re this last type ;-) ) to get them angry enough at the situation that they take
control, cross out the irrelevant information, and find a way to distill their facts into a way that fits onto
the drawing. Dan argues that visual communication transcends language and cultural barriers and can
be used to communicate complex ideas – but these ideas need to be transformed into a combination
of the following: who/what, how much, where, why, how, and when. After talking a bit about
neurobiology, Dan explains that the brain has different visual pathways for each of these types of
information that are all processed in parallel. How can you present each type of information visually?

Just follow this chart:

The story given was that Dan had to present the problem statement around a financial process in
Microsoft. He drew the problem statement on paper using stick figures and didn’t manipulate
the image through Illustrator or any such tool. The execs were impressed because he was able to
easily relate to them and they asked what software he used. Facetiously he replied “Pen and Paper
1.0.” The moral of the story however, is that the more human your presentation, the more human the
response will be.

Next time you need to speak to your customer about pain points, try the following Wong-Baker pain
chart, used in emergency rooms:

BPM Modeling

The next session was about BPM modeling by one of the leaders of the BPMN standard. BPMN is a
powerful standard that can be used to model almost any business scenario. It is an easy to use way to
draw processes designed to be understood and used by business users. It’s limitations include not
being able to model meetings (without resorting to an ad-hoc task) and serializing the model.
Serializing is necessary to be able to save the model in a way that is executable by a workflow engine.
Workarounds to the serialization issue are to export the model as XPDL or BEPL. Despite these issues
BPM vendors are retrofitting their tools to support BPMN 1.1 due to its power in modeling processes
and simplicity for business users. Want to give BPMN for a spin? Try the free tool:
http://bizagi.com/eng/products/ba-modeler/desc-efective.html

Risk Management and Compliance

This was the one must see track session considering what our team does and I had to trade off several other
good presentations to attend this one. The key point delivered was that GRC is a short-term audit-driven need.
Nobody likes compliance (except for those whose jobs are compliance) but thanks to the likes of
Enron and MCI WorldCom we’re in an ever increasing regulatory environment where imposed
regulations continue to grow. Businesses really wants performance and business risk management but
for now they are faced with immediate needs to track regulatory compliance. GRC tools out there
include some form of process, but they are still stovepipe applications. In the next 4-8 years, expect to
see BPM solutions move into the GRC space. Strengths of BPM in the GRC space are the fact that you
can set risk management workflows, perform policy mapping, model (and simulate) risks and controls,
automate controls, and analyze control effectiveness. In our experience, creating management
workflows and analysis of control effectiveness are some of the hot topics in the risk management
work. The weaknesses of BPM in the GRC space is related to domain knowledge and time to
implement. The primary drivers of GRC implementations today are the need for domain knowledge of
regulatory standards (something that BPM vendors do not have experience in) and a quick audit-
driven solution – customers need a fast solution, not tools that enable them to create solutions. Since
“pure” GRC is a short-term need, the industry will begin to focus more on risk management, and
eventually business performance management. Since BPM is already in the realm of performance
management, the prediction is that BPM suites will start to include risk management and modeling
capability with compliance built-in to ensure that processes created through the tool are in
compliance.

User Interface and Empowerment Disrupts Business Applications

From the start, it was a surprise to see how few people attended the keynote on user interfaces.
Rather, most attended the session on change management instead. Since my double was not available
at the time, I had to pick one or the other and went to the only session related to UX. The problem
statement presented is that the returns on automation are shrinking, mostly due to the fact that business
applications have already squeezed the people out of processes in most places. Many of the
remaining tasks end up being non-routine, highly cognitive, and interactive tasks—and this trend is
growing. In second place are non-routine, highly cognitive, analytic tasks. Both of these types of tasks
are poor candidates for process automation. What should IT to do in these areas? Industry wide, IT is
already being seen as an inhibitor to business change.

The answer is to model processes around business KPIs (not the opposite) and empower the business
user to have information at their fingertips and to “design” their own solution:

• Focus on End-User Flexibility

- Enable end-user process flow design

- Enable end-user-driven creation of apps through configurations, personalization,
mashups, compositions

• Develop a Consumer like Experience

- Embedded user experience that includes Web 2.0 and user productivity like
experience

- Immersive UI, pervasive mobility

• Incorporate Context Into Processes

- Peer-based, ad hoc collaboration enabled

- Community-generated content

- Process and information design presented based on individual need

• Include a Network-Centric Design

- Anyone can participate, from any organization, from any geography

- Architected for high-volume, highly distributed, simultaneous connections

- Information can originate from anyone, anywhere — no boundaries

• Provide Actionable, Intelligent Insights

- Predictive, proactive and context-aware analytics

- External and internal cross-application content

- Structured and unstructured data analysis/synthesis

In the end this is really the people component of people, process, and technology.

Thanks for reading, more tomorrow.

Marius

Trip Report : Day One of Gartner BPM Conference

cisg — Fri, 12 Sep 2008 12:11:00 GMT

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

Checklists and Mnemonics

cisg — Fri, 05 Sep 2008 19:56:37 GMT

Dennis Groves here....

The most common list is the to-do list, and it is the one we are all most familiar with and so the real value of a checklist is often very misunderstood. Aviation and medicine make heavy use of them. Computer programs are basically a sequential list of operations to for the computer to perform. In computer science; the linked list is considered to be a fundamental data structure. However, its most basic component is the list. In fact there is an entire computer language that is composed only of lists. And an entire branch of mathematics. The list is such a fundamental tool that most of us take them for granted and think nothing more of them. And yet we would be doing ourselves a great disservice to dismiss the usefulness.

Mnemonics are a kind of list used to recall important information. Recently I read a brilliant post by Adam Arndt about "SOAP"

The SOAP method involves putting all data concerning a problem into a “SOAP Template”, that is to say that all data should be entered underneath one of 4 headings (the first letter of each heading spells out the acronym “SOAP”):

Subjective, Objective, Analysis (or “Assessment”), Plan

Subjective information is filled out first and should contain subjective, qualitative information about the problem. Examples: “The network is slow”, “Outlook “hangs” when I try to send an encrypted email”, “I feel sick”.

The Objective information is filled out next and should contain verifiable/verified quantitative information that provides further insight into the Subjective information that the customer/patient has provided. Examples: Event ID’s from event viewer, errors displayed on the user’s screen, log files, packet captures, version information about software, programming languages used in code, functions used in code, % CPU utilization, blood pressure, body temperature, and heart rate statistics.

Analysis This is where you use your brain and analyze the Objective data that has been gathered and attempt to find root cause. One result of the initial analysis may be that you do not have enough Objective information to solve the problem so you ask the customer for additional Objective information that you need to continue the Analysis. This is an important part of the case documentation process as it should track any actions that have been attempted/investigated so that if another engineer must take over the T-shooting process the same actions are not performed multiple times. The final output of the analysis phase should be the discovery and documentation of the root cause of the issue.

Plan A list of possible mitigations for the problem. A list of possible ways to resolve the issue with their pros and cons laid out. (In some situations only one solution may exist.) The customer will then choose which solution to implement (we’re just consultants, not their business decisions makers we don’t make decisions for customers, we just inform them of their options and the pros and cons and they must choose which one works best in their environment), this decision should be handed off to the customer’s Release Management process and, especially when we’re doing consulting for the customer we should make sure that the customer understands the Operational Impacts surrounding that change.

The utility of such a pattern in problem solving is really amazing. For example lets say your worried about saving for the children's university education? SOAP to the rescue. Subjective: your fear you don't have enough money. Objective: look in the bank; have you started a college fund? Analysis: Not enough money for their education. Plan: Set aside money for the children's education every paycheck. Wow! That is a really useful pattern. And yet this was ostensibly invented to reduce medical malpractice law-suits by getting doctors to collect information in a consistent manner so that nothing was forgotten in times of emergency.

I find these kinds of patterns to be useful and exciting; as does my friend J.D. Meier who has a blog devoted to the documentation of such patterns and insights.