A few days ago, I had a very interesting conversation with a process improvement expert. He is part of a large multi-national company and for the last 18 months, he has been responsible for the deployment of process improvement best practices throughout his company’s IT department. This work has given him valuable insight on the subject of process improvement deployment, and I very much appreciate him sharing his experience and lessons learned with me. In this post, I will present the process improvement deployment experiences of this customer as a case study, with their lessons learned summarized at the end. This case study illustrates how theoretical concepts of process improvement can be put into practice.

For organizations embarking on the path of achieving a process improvement mindset, the first logical step is to capture their existing processes in a safe, usable, and accessible form. Safe meaning that the processes have the appropriate level of protection from misplacement and loss. Usable meaning that the processes are in a format (or formats) that can be easily used by all members of the organization. Accessible meaning that the processes are accessible organization-wide from a single well-known portal. Once the organization’s internal processes are captured in this manner, a gap analysis can be conducted and the indentified gaps filled by the industry’s best practices. This is a laborious step and requires careful planning and project management, but process authoring and management tools can substantially reduce this effort.

For this customer, the first step involved capturing a large number of processes, many of which were never previously documented. Their strategy relied heavily on tasking various subject matter experts (SMEs), from different IT groups, with process definition. The SMEs were provided with an intuitive tool and training. The SMEs, working from their own various geographic locations, were then able to enter their group’s processes in the central system. The process group constantly reviewed the entered processes and provided feedback to the SMEs. Once the initial processes were captured, the process group structured them into a reusable process architecture. SMEs, in turn, were able to review the process architecture and provide feedback. Employing this strategy, the customer was able to distribute the process definition effort across its IT department, and created a comprehensive process architecture in a matter of months. Moreover, this strategy made the process improvement adoption (institutionalization) more likely, as the user community was intimately involved from the beginning—versus being dictated to by an external group. It creates a sense of ownership.

At the end of this step, the organization had codified its distributed tacit knowledge.

To further increase process adoption by the organization project teams, the process group, with the help of SMEs, created variations of each process to better suit the various project categories. All the processes (and their variations) were made available for consumption from an organization-wide process portal. The portal also provided sophisticated “search and select” functionality to make sure the most suitable process could be quickly identified for a given project. Process search and selection will form the basis of a comprehensive process tailoring solution in the future.

The customer decided on this approach as opposed to burdening the project managers with the tailoring task. They felt tailoring processes by adjusting them was too complex a task for the project managers at this stage.

Based on my experience, many organizations underestimate the complexities of process tailoring. I feel this simplified tailoring approach is sufficient for most organizations, with the exception of matured process-centric ones.

To effectively improve the processes and the process architecture, the organization relied heavily on input from the end users. The “feedback” and “community” functionality of the process portal was used to collect and capture feedback and lessons learned from the organization’s project teams which, in turn, were used by the process group and the SMEs for ongoing process improvement.

Keep in mind that a single integrated system provided the process capturing, definition, architecture, tailoring, and feedback, with end-to-end traceability.

As the next step, the customer is developing usage models to accurately measure the rate of process adoption by the organization’s project teams. They feel having reliable adoption metrics is critical to sustaining  the support of senior management.

In summary, the following are the lessons learned from this process improvement effort:

• Identify and utilize SMEs for capturing the organization’s processes
• Importance of training SMEs and providing an easy-to-use tool for process definition
• Importance of a process architecture that supports reusability
• Create a sense of ownership as early as possible
• Simplify the task of tailoring
• Minimize the effort required by project managers to use a process in the their project
• Base the ongoing process improvement on user feedback
• Importance of end-to-end traceability
• Importance of usage models in winning and sustaining senior management support

This case study illustrates how theoretical concepts of process improvement can be put into practice.

I feel topics such as usage models and institutionalization/internalization deserve more detailed exploration.

Software development processes capture—in reusable form–the organization’s best practices and lesson learned, making them sharable across projects. Today, the benefits of process-centric software delivery are well understood. So, why is the industry’s adoption of software development processes so dismal? The lower than expected adoption can be partly explained by a phenomenon called groupthink. For this post I will rely on materials from James Surowiecki widely cited book: The Wisdom of Crowds.

The coinage of the term, groupthink, predates Surowiecki’s work, but he frames it concisely within the larger arena of group decision making, which he shows is more accurate, in most cases, rather than decisions made by subject matter experts. This easy to read book draws from and consolidates various scientific and empirical bodies of work from diverse fields–such as psychology, statistics, and economics–making the subject generally accessible.

For crowds to produce correct decisions, its members must be diverse, independent, and decentralized, and should have a mechanism to consolidate the individual judgments into collective decision. However, the decision making fails when the members of the crowd are too conscious of the opinions of others and begin to emulate each other and conform than think differently. This failure is called groupthink.

I believe commercial software methodologies have been suffering from groupthink. For over a decade, most efforts have centered around Unified Process with all participants—mainly methodology theorist and consultants-emulating each other and conforming rather than thinking differently. Any new development—such as Eclipse Process Framework or SCRUM—has been forced to fit in a UP mold. The practitioners have found these expertly devised methodologies irrelevant, and, hence, have mostly avoided them. At the same time, new practical ideas that arise during actual development projects are prevented from blossoming. The potential methods devised by diverse projects’ practitioners are likely to be more relevant, as they convey the wisdom of crowds (mobs) and consequently have a better chance of wide adoption.

The good news is that with the recent availability of integrated ALM and interactive process asset repository systems, it is now possible to involve practitioners in the end-to-end methodology development effort. I will cover this in more details shortly.

A colleague forwarded to me an interesting work by Petter Holmström titled “Ideas for Next Generation Process Authoring Tools”.  It’s a long comprehensive document, and I have just started reading it end-to-end. From a quick scan of the table of contents, abstract and conclusions, I mostly agree with his conclusions and recommendations:  

The tool vendors should shift focus and concentrate on making their tools more collaborative, customizable and scalable to different process sizes. In this thesis, some ideas of how this could be achieved have been presented, of which one of the more interesting ones is a wiki-based authoring tool.

 

As you may have realized from my previous blog postings, I am a strong proponent of collaborative process management tools and the importance of the involvement of developers and other process consumers in the creation of processes–they consume. The industry players and the user community should democratize process authoring and move on from blindly following methodology pundits.

Previously, I categorized process asset repository as an enterprise class system. In here I will clarify the term “enterprise class” and justify the categorization of process asset repository system as enterprise class.

The common aspects of enterprise applications include the following:

• Enterprise applications are used by a large number of people with varied roles. Each role requires it’s own view of a common set of data. Moreover, these applications must meet strict scalability (number of concurrent users) and response time benchmarks. And they should be accessible from any of the organization’s client machine.

• Enterprise applications are mission critical and incorporate large amount of specialized business logic.

• Enterprise applications are data-centric and built on top of a logical (relational) model infrastructure. In most cases the underlying schemas are share across multiple application.

• Enterprise application deal with the organization’s proprietary and valuable assets—data and methods. Hence they require secure—password policies–role based access and data encryption. Moreover, these assets much be centrally managed on a robust infrastructure.

As I state in a white paper on this subject, the organization’s process asset repository system is used by a large number of users with distinct set of roles. It manages all of the organization’s processes, which are proprietary and valuable. And it plays a critical role in the quality and risk management of mission critical projects.

As a side conclusion, process asset repository system cannot be implemented as a desktop application nor a non-transactional website.

In the next post on the subject, I will try to provide you with a more definitive view of the above requirements. To do so, I intend to formulate a set of concrete control objects–based on the above requirements–for development of enterprise applications/solutions. By looking from the perspective of developing such applications, I hope that you will get a fresh insight into the nature of enterprise applications. Also, you may find—as I do—the concept of control objectives interesting.

Earlier this week, one of our key customers was looking into exporting some of its IT processes from the organizations process asset repository system to IBM Process Server, a business process management (BPM) system.

BPM systems utilize business process execution language (BPEL), XML based language, for process representation. Using IRIS Process Author’s export facility, we are able to quickly define a script that generates BPEL representation of a process which can be consumed by BPM applications. The flexibility of the export facility stems from the fact that IRIS Process Author’s process object model is accessible from within export scripts. Hence, the script logic can directly reference process objects of the asset repository and transform and export the process elements into the desired format.

Usefulness of BPEL goes beyond BPM systems, Microsoft Window Workflow Foundation, currently embedded in BizTalk, SharePoint and Dynamics CRM, also supports BPEL. Therefore, aside from BPM systems, once in BPEL format, the organization’s processes can be used by a variety of applications.

In the first draft of my white paper, I failed to point out the importance of a flexible export facility for the organization’s process asset repository system. I will correct this omission in the next version of the white paper.

Seamless interface with BMP extends the usefulness of the organization’s process asset repository system beyond IT and software process improvement and extends it to the realm of business process improvement. But, the relationship between BPM and process improvement and the differences between IT processes and business processes deserve much more discussion. I will dig deeper into these areas in future posts.

I have just completed the first draft of a white paper on Process Asset Repository System. I greatly appreciate all comments, corrections and feedbacks. You can reach me at phodaie@osellus.com.
collaborative-process-asset-repository-system.pdf

This is the first in a series mini-posts on technical and architectural aspects of process asset repository systems. In this post I will introduce the process object engine sub-system.

Deployment of a process asset repository system is critical for any organization striving to advance from project-level process management—CMMI Level 2 maturity–to organizational wide process management that facilitates application of the organization’s best practices and lesson learned across all of its projects—CMMI Level 3 maturity.  Process asset repository system is an enterprise class application that manages all aspects—creation, storage, collaboration, consumption, appraisal–of the organizational process improvement needs.

Abstracted from the users, process object engine forms the core of process asset repository system. Other parts of the system, as well as, external applications interact with the process object engine through a set of web-services APIs. Process object engine provides the necessary infrastructure services including persistence, transaction support and change control.

Moreover, the organization’s process assets are granularly captured using an object model.  Process object model is an interesting topic and I will talk more about in future posts.