TEAM Zarate Tarrani Notes From the Field

A Rose by any other name. At what point does knowledge management become process management? If you carefully study the Agile Enterprise Reference Model the distinction becomes blurred. Knowledge management, like all other disciplines, is a collection of processes. The Agile Enterprise Reference Model, however, is clearly process-oriented. You can download the model in MS Word format for off-line reading.

All that glitters. A wealth of related material is available from Paradigm Shift International's series of articles called Real-Time Chronicles, short essays on the emerging knowledge of agile enterprise.

Down to Earth. I've put together three collections of presentations and documents that show different facets of knowledge management:

1. Knowledge Management as a Profession.
2. Knowledge Management Theory.
3. Knowledge Management Practice.

All the news that's fit. I wish to share three more documents that do not neatly fit into this entry's theme:

1. A brief (terse is a better word) PowerPoint presentation on Systems Theory.
2. PowerPoint presentation on KM Metrics Framework (if you can't measure it, it doesn't exist!)
3. Knowledge Management and the Enterprise

Good morning from Irvine, California.

Buying Software and Other Frightening Acts. Recent entries in Postcards from the Revolution we're discussing software RFPs and related topics. It all boils down to the same issues and factors, regardless of what you're buying - a house, car, landscaping. You want the best possible product or service at the best possible price. The seller wants your business and to make a profit. At issue is quality, and in the case of software quality encompasses a number of attributes:

• Works in your environment without requiring upgrades, modifications to your equipment or processes and does not impose a maintenance burden.
• Contains the features and functions you specified.
• Is free of defects.

Bug or Feature?. Of course, the list of attributes is longer, but these are the major ones.

Let's focus on the last: free of defects. There used to be a facetious saying, It's not a bug, it's a feature. In real life, if requirements and specifications are poorly written the definition of defect may be open to argument. I like Cem Kaner's article titled, What is a Software Defect? because he clearly defines what a defect is, and as importantly, what a defect is not. Mr. Kaner is a well known software quality professional and an attorney, so a prudent person would consider his definition as at least a starting point.

Caveat Emptor. Testing, especially acceptance testing, is the responsibility of the customer. This holds true whether you're buying a car or outsourcing software development. Therefore, before a contract is signed there has to be agreement between both parties as to what constitutes quality and non-quality, how defects are to be handled when your acceptance test detects them, and a plethora of related issues that are beyond the scope of this entry.

One of the goals of acceptance testing is to make sure that the features and functions you specified are actually included in the software and they operate consistently with what you specified. My preferred method for specifying requirements is through business rules. I've covered this method in reasonable detail in Postcards from the Revolution, so I'll only mention them here. However, there are other methods that may be a better fit to your organization's processes and procedures for requirements management. One article that shows viable alternatives is Requirements that Handle IKIWISI, COTS and Rapid Change by Dr. Barry Boehm. IKIWISI stands for I know it when I see it (a common phenomena encountered by requirements analysts and facilitators), and COTS is commercial off-the-shelf software.

If you are contracting for software development with a vendor that employs object-oriented methods (or are developing in-house using them), you may want to read Business Rules and Object Role Modeling, which aligns the business rules approach to object-oriented methods.

It's About PM. There is more to outsourced or in-house software development than requirements, specifications and acceptance testing - there is an entire life cycle that needs to be managed. While there are distinct issues that need to be addressed when the project is outsourced, there are common issues shared by outsourced and in-house development. I've put together a Zip archive that contains three short PowerPoint presentations that cover the project management basics as a PM briefing. In addition, the PowerPoint presentation titled Nature of IT projects will prove useful, especially the facts cited in the form of quick quizzes.

You may also want to get a copy of the 1996 version of the Project Management Body of Knowledge (the 2000 version is not available as a complete document in the free version). Don't forget that properly closing out projects is as important as the initiation and management processes. You'll find valuable advice in the MS Word document titled Project Post Mortems. This connects nicely with Kate's work supporting knowledge capture.

Loose Ends. Wrapping this entry up are three documents that relate to what I've covered above:

1. Cost-Benefit Analysis of Test Automation. At some point it's going to make good business sense to invest in test automation tools. This paper will help you to determine when is the optimum time to make the investment and expected ROI. Don't forget to have a process in place before spending money on tools!
2. Familiar Metric Management - Effort, Development Time, and Defects Interact, which seamlessly ties together project and testing metrics.
3. Customer Negotiation Metrics - 17 PowerPoint slides you should read before sitting down with your vendor.

Process and Architecture. Kate and Linda have both written entries about process in one form or another during the past two days. I'm going to continue with documents that discuss aspects of process.

One interesting paper that blends software and system engineering processes and process improvement is titled Assessing the Rational Unified Process against ISO/IEC 15504-5: Information Technology Software Process Assessment Part 5. ISO/IEC 15504, also known as SPICE (Software Process Improvement Capability dEtermination) is a viable and popular assessment method, and part 5 of the document set specifically addresses the assessment model and provides indicator guidance. An FAA document titled Guidelines for Software Measurement (MS Word format) takes a different view of the subject and is more aligned with the Capability Maturity Model approach to assessment and process maturity. If you're trying to build a business case for implementing the CMM, a short MS Word document titled CMM Benefits contains a summary of the ROI achieved from implementing the CMM in a sampling of companies.

If your focus is architecture Model Driven Architecture provides a process approach to developing sound architectures. For teams that are working within the Rational Unified Process or employing key elements, such as unified modeling language, Using UML for Architecture Description is a worthwhile resource.

On the purely business side of IT processes IT Efficiency and Business Value and a companion document (both in PDF format), Principles of Effective IT Management give ideas and methods for IT operational process improvement and business/IT alignment.

What I'm Currently Reading. I'm working my way through a pile of books right now, but one stands out as excellent: Building Scalable and High-Performance Java Web Applications Using J2EE Technology by Greg Barish. First, let me assure you that I haven't been enticed to the dark side and am turning into a developer. That will never happen. What makes this book so interesting is the author's focus on scalability and performance, and his ability to clearly write about these two subjects. I have a pile of books on performance, capacity management and related topics and can attest that clear writing makes the difference between merely grasping concepts and achieving enlightenment. This book will enlighten. Linda just wrote her review of this book so I'll leave it to her to provide a more complete description of this book. I will say that you need not be a developer to gain a great deal of knowledge from it.

Knowledge Fest. I've been reading Working Knowledge: How Organizations Manage What They Know, which has inspired much additional research in quest of related material. My research has yielded a large number of documents and presentations, which I'll dole out in manageable portions over the weekend. There are three that I'll make available today to whet your appetite:

1. Knowledge Modeling
2. Knowledge Value Chain
3. Intelligence Monitoring

The last document does not fit within the theme of Working Knowledge: How Organizations Manage What They Know as much as competitive intelligence, but I so liked it that I'm sharing it immediately.

Check in here and in Postcards from the Revolution over the weekend for more material because I'll be posting in both weblogs every day.

Out of the Wilderness. Open source development, or using open source software in the enterprise, is not as straightforward as the proponents would have you believe. Nor is open source as fraught with risk, if properly understood, as its detractors would have you believe. The problem is that there seems to be no middle ground in the literature. I've found that you're either promised paradise of eternal damnation, depending on who wrote the literature. That was the case until Understanding Open Source Software Development.

This may be the perfect book about open source software because it places open source within the context of business value and does not promote it as the great panacea that characterize the message of far too many books on the subject.

What I like is that, after providing an overview of open source, its history and proponents, the authors discuss how to analyze open source software within two major frameworks: the Zachman framework (see prior entries) that was developed in 1987 and is popular today as an enterprise-wide information systems paradigm. The book also introduces a newer framework called CATWOE. I'm new to the latter, but it is solid and is independent of open source. CATWOE stands for Clients, Actors, Transformations, World View, Owners and Environment.

The remainder of the book discusses aspects of open source as they relate to the CATWOE framework, which ensures that fair and complete treatments of the business and technical issues are given. I would have liked a more in-depth discussion of the legal issues and business risks that are associated with the GPL; however, that information is in a state of flux and is probably best gotten from daily news sources.

If you want to understand open source software development, especially as it relates to business value, this book is the one I recommend. The authors also have an associated web site that supports the book.

In & Out. I've been pulled in many directions this past week, but want to share three documents that captured my attention:

1. Assessing the Value of Business Intelligence
2. Measuring Process Effectiveness
3. eContinuity and the Internet

The first document links business imperatives that Mike has discussed here and in Postcards from the Revolution to my specialty, competitive intelligence.

Measuring Process Effectiveness also has a direct connection between Mike's series on processes here, and competitive intelligence in that process measurement is important to those who are designing and implementing processes and those of us who reverse-engineer competitor processes to determine if they are a threat to our own competitive posture in the market.

If the third document has you scratching your head wondering where the connection is, consider how difficult it would be to gather competitive intelligence without the wealth of resources provided via the Internet. Yes, there was a time not so many years ago that we did it the hard way. But most intelligence gathering operations would be dead in the water today if the Internet would suddenly be unavailable.

Welcome a New Face. Marcia Hopkins has joined us as a contributor. She brings a new perspective to this and Postcards from the Revolution with her unique background and experience.

Process - Part 3: Policies. In my 21 March entry I gave an example process, using IT change control and the ETVX model to illustrate how a process works. I concluded the entry by stating that the process did not contain policies and left that for this discussion.

What is a Policy? A policy is a directive that has the following attributes:

• scope and applicability (what and whom does the policy govern?)
• comes from a source of authority that exercises control over all individuals who have roles and responsibilities in carrying out, enforcing or complying with the policy
• governs the scope of a processes and procedures that enable or support meeting the policy's objectives
• traceable to business imperatives (if you've been following my discussion of the Tarrani-Zarate Model in Postcards from the Revolution you'll have a basic understanding of business imperatives)
• enforceable

Mechanics. These imply that there is a system of authority, responsibility and accountability. The authority behind the policy is directly responsible for the implementation, execution and enforcement of the policy. Even if responsibility is delegated, the direct responsibility should be placed on the authority who created the policy.

Responsibility entails accountability for how well or poorly the responsibility has been discharged. This chain of authority-responsibility-accountability is a basic precept of leadership and the foundation of any organization.

Why Policy? Without policies there would be no control mechanism for processes. In the real world there are processes that are operating without governing policies, but such processes are often ad hoc and too often are a duplication of effort or are inefficient at best and wasteful at worst.

Relationships and Connections. Here is how it's supposed to work and why: business imperatives spawn policies. These imperatives come from many sources, including law, competitive pressures, the fiduciary responsibility of the board and executive management to safeguard shareholder value, etc. The execution of the policy is within the scope of processes, which are decomposed into procedures (see the ETVX model in my 21 March entry).

A few rules of thumb:

• Policies are executed via processes, and processes are comprised of procedures and validation points.
• Processes without governing policies have no controls, and if they cross organizational boundaries, depend on personalities instead of positional authority.
• Policies without processes have no repeatable means of being executed and are probably unenforceable.
• An unenforced or unenforceable policy erodes authority and can result in morale problems, inefficiencies and worse.
• A policy needs a source of authority who has control over all stakeholders.

Example Policy. The following policy is linked to the change control process presented in my 21 March entry. You'll see direct links between the policy, roles and responsibilities and the process itself.

It is the policy of (Enterprise) to manage the life cycle of all information systems supporting its business and technical objectives. As such, the processes and procedures for change control set forth in this policy document governs change, and release management. The scope of this policy is the management of changes to the production environment. Specifically: before any change to a system or a baseline, the proposed change will be evaluated and approved by the (Enterprise) Change Control Board.

No approved change will be implemented without:

1. Entry criteria needed to initiate the change control process.
2. An approved plan of action with milestones for implementation, that provides a sequence of events or steps for implementing and releasing the change into the production environment, a roll-back plan, assigned roles and responsibilities and post implementation validation (PIV) test plan.
3. A completed test plan showing the results of testing the change in a pre-production or staging environment.
4. Approval from the application owner(s) affected by the change and the business systems managerresponsible for the application or system being changed.
5. A formal review by the Change Control Board to ensure that all entry criteria for the change have been met.

Any system or application failure or defect traced to a change made to a system or application that was not made in accordance with this policy, process and procedures will result in disciplinary action. Specifically:

1. The error will be communicated to all stakeholders of the affected system and/or application.
2. Individual(s) making the unauthorized change will be required to develop an action plan specifying which measures will be taken to avoid a future occurrence of the failure or defect.
3. The action plan will be reviewed and approved by the individual's management chain and posted in a public place for review.

Closely examine the policy statement above, then compare it to my definition and discussion. Also analyze the process that was described in my 21 March entry and see if there are any gaps in the integrity of the policy or the process.

Here's a key question: from which level in the organization should come the source of authority for the policy and process we've been discussing? Hint: it's not IT.

Next Up. My next entry on processes will discuss goals, critical success factors and key performance indicators.

I just finished reading Doug Kaye's second issue of his IT Strategy Letter and am overwhelmed by the depth of analysis and array of topics covered. Doug is well-connected in the industry and is an insighful observer. Add the fact that he is an articulate writer who addresses topics that are of interest to consultants, IT managers and those in the trenches, and you'll understand why I listen to what he has to say.

The newest issue of Methods & Tools is also out. This issue covers the following three topics:

1. Understanding the Unified Process.
2. Software Process Improvement: Assessing Readiness
3. Web Site Mapping

You can subscribe to this newsletter, read back issues or catch up on breaking news at the Newsletter's home page.