The version 1.5 of MOF Mobile Reference is available for download as of yesterday. This version includes MOF roles, processes and activities. Now I am working on the next version of CMMI Mobile Reference that will include sub-practices and work products.

Over the last few days, I have been working on a mobile reference app of the Microsoft Operations Framework (MOF), which I submitted to the Apple App Store this morning. I will let you know once it’s approved and ready for download.

I always wanted to dig deeper into MOF, partly because I had noticed many of our larger customers increasingly utilize it in their mission critical operations. Developing this app has provided the opportunity to do so. I find that developing an application forces you to understand the underlying details of subject.

In developing the first version of this app, I gained a thorough understanding of MOF’s meta-model. I am very impressed with MOF’s vast amount of practical content, and am already thinking about designing the next version of the app with much more content.

My overarching goal in developing these mobile references is to represent the already codified body of knowledge in a form more conducive to internalization. My belief is that the Mobile Internet Platform is ideally suited for effective internalization of codified knowledge.

This is a work in progress but I feel it will mature rapidly.

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.

Process improvement encompasses process definition, as processes have to be defined and manageable before they can be improved.

This is evident in the following CMMI practices:

• OPF 1.1 Establish Organizational Process Needs
• OPF 1.2 Appraise the Orgnization’s Processes
• OPD 1.1 Establish Standard Processes
• OPD 1.2 Establish Lifecycle Model Description
• OPD 1.5 Establish the Organization’s Process Asset Library

I have just finished another process improvement/governance related iPhone app, a quick look up reference app for COBIT process areas and control objectives. After two more days of  testing, I will submit it to Apple for approval. I’ll let  you know once it’s available on the App Store for download.

My respect for the iPhone development platform has increased considerably as I spend more time developing for the platform. Although Objective-C is outdated compared to  modern languages such as C# (especially C# 4.0), Apple more than makes up for it with extensive libraries and powerful development and in-device debugging tools.

Many times while thinking about or discussing CMMI related topics, I have difficulty recalling a particular process area, goal, or practice. I don’t always have a CMMI book or my laptop handy, but I always carry my iPhone. This got me thinking about developing a CMMI reference for iPhone that I could access at anytime.

I feel this app is useful for any iPhone owner who is into CMMI and process improvement. You can get a free copy of this application from the Apple App Store.

I had so much fun with this application that I am thinking about creating other process improvement, governance, or development methodology related apps.

I hope the process improvement community finds this app useful.

Recently I was part of the FDA 21 Code of Federal Regulations Part 11 (Part 11) audit of one of our custom software development projects. Part 11 audit is mandatory for any pharmaceutical system that uses electronic records and signatures in lieu of paper records. Our audit went surprisingly smoothly, and overall a positive experience for the team, reaffirming my beliefs about the benefits of established development processes and tools. This post briefly covers what contributed to the success of this audit.

Part 11 requires a software development process to be defined and followed. The process should have specific requirements, such as reviews of all the key milestones (e.g. System Requirements), and a well defined Validation phase (functional testing).

One of our internal product development processes was a good starting point for the definition of the process required for this customer project. As all our processes are stored in IRIS Process Author (IPA) in a reusable form, at the outset of the project, we were able to easily make the required adjustments to the selected base process to better suit the project. The process was then shared with the project team in a published form—in the project portal. During the audit, the external auditors carefully reviewed the details of this process and were fully satisfied with its coverage.

I was also required to demonstrate to the external auditors that our team was aware and followed the process. We use Microsoft Visual Studio Team Foundation Server (VSTS) as the development tool. IPA can generate VSTS process templates. In doing so, each activity of the process becomes a work item. In addition, all the process information such as description, steps, and roles, are captured as work items ensuring that every member of the team has access to process information when they need it. Hence the project team was steeped in the process being enacted. This showed the external auditors that the process was fully internalized by the project team and would not be abandoned at times of stress.

VSTS was also used for planning and managing issues, risks, and tasks, a single repository for all project artifacts. As VSTS is tightly integrated with MS Project, project managers were able to generate schedules and track the team’s progress.

In one of my sessions with the auditors, I did not have printouts for all issues and defects with me. When the auditors asked for evidence for certain scenarios, I was able to use VSTS (through web interface), and generate excel spreadsheet for the requested scenarios on the spot. This drove home for me the importance of having a central repository that instantly provide access to all project artifacts, which can be used as direct evidence during the audit process.

I believe process and tools are like two wings of a bird. To fly this bird needs both. Having a well-defined process in place is a great first step but unless the team has the tools that seamlessly incorporate the process into their daily work, the process is not internalized. High performance teams such as ours value being process-centric and disciplined, as long as processes are not a drag on their daily work. The integration of processes with tools not only helps with a positive audit experience, it also results in a motivated and disciplined development organization.

Architecturally, a process improvement system is an end-to-end enterprise application, as appose to a single-user desktop utility application.

Earlier this month, IBM Rational announced their Measured Capability Improvement Framework (MCIF) offering, vaguely described in the IBM’s oficial news release:

Additionally, with IBM’s new Measured Capability Improvement Framework (MCIF), organizations can also take actions to continuously improve on results by learning from past experiences. Through MCIF, IBM provides organizations with an end-to-end framework that enables them to measure results and manage projects so they can incrementally improve their software delivery capability. 

“In today’s economic climate, businesses are looking for new ways to derive greater value from their investments in software,” said Dr. Daniel Sabbah, general manager, IBM Rational Software. “Up until this point, organizations have been lax in measuring the business value and discipline of the processes [emphasis added] they use to deliver software assets. Classic metrics in software engineering largely ignore the importance of actual business outcomes. Our clients are now beginning to realize that the software they build or assemble must be treated as a strategic business asset. IBM is committed to helping them make the right decisions and improve the successful outcomes of this newly emerging business process discipline.” 

 

Measurement driven improvement is central to CMMI and CobiT has a strong emphasis on alignment of IT processes with organization’s business objectives. If you have read my blogs, you would know that I strongly believe in objective-based process definition. If anything, IBM Rational is playing catch up. But it is still nice to have their confirmation.

I didn’t attend this years Rational Software Conference, but I have been carefully studying white papers on MCIP and Rational Insight offerings. I will discuss Rational Insight in a future post.

MCIP white paper is well written and is an enjoyable read. I fully agree with the framing of the differences between business and manufacturing processes and software development processes on pages 3 and 4.

Unlike most other business processes, such as supply chain management or manufacturing, SSD needs to deal with a range of risk. SSD also differs from many other business processes in that it entails a diseconomy of scale: that is, individual productivity decreases with the size of the SSD effort. …

Software delivery differs from many other business processes by dealing with a broad range of innovation. Some software projects, such as maintenance of existing systems, are reasonably predictable, similar to manufacturing processes. Those projects carry limited innovation and drive limited or no business differentiation. Other projects, such as building unprecedented and large software systems, require high degrees of innovation in addressing problems that have never been solved before on a schedule. Committing to delivering innovation requires assuming risk, since the lack of complete knowledge at project inception is inevitable and uncertainty regarding how to proceed is part of the challenge. This risk is manifested in the statistical variance in the estimate of the time or cost to complete. 

A commitment to assuming risk entailed by bringing innovation to the enterprise provides the opportunity to improve ROI.  

Another major difference between the business process of software delivery and other business processes is the diseconomy of scale. Typically, manufacturing and service delivery processes offer economy of scale: The cost of a unit of software grows nonlinearly (i.e., yields cost reduction) with the size and complexity of the system. But this is not the norm in software production.

On the other hand, some of the insights that have been discovered as part of IBM effort are trivial. For example, on page 15 they say 

Many organizations mistakenly try to make one process fit all circumstances. In our experience, the above type of analysis is required to enable you to drive the appropriate change to the right project types. 

I don’t know of any organization that doesn’t believe this. In fact, it sounds condescending. 

In essence, MCIF is a practice-based approach to software development processes. An approach they first introduced in the last version of EPF (before it became inactive). One can argue that IBM was a later comer to this also., The concept of practice has been widely utilized in CMMI, Microsoft MSF and EssentialUP.  MCIF is a methodology for top-down selection of practices based on the organization’s business objectives.

Although I like objective-based software development process definition, MCIF, however, is top-down and non-collaborative. It relies on Rational Method Composer (RMC) tool, which is a single-user desktop application–requiring a configuration management system for basic maintenance of processes. The white paper, also, falls short in addressing the practical issues of mapping business objectives to different aspects of processes and the mechanics of process tailoring. 

Finally, from Per’s video, it is apparent that MCIF is not a tool empowering users, rather it is a service that requires engagement of IBM consulting services.

My recommendation: best source for software development capabilities improvement is CMMI body of work. As I said before, CMMI is the result of two decades worth of work by various subject matter experts, not a single vendor’s commercial methodology.