Saturday, March 30, 2002

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: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.

Friday, March 29, 2002

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.

Thursday, March 28, 2002

Of Processes and Service. The theme unfolding in the latest entries here is process design. Designing and implementing service management processes are TEAM Zarate-Tarrani core competencies, and will be the recurring subject of entries here and in Postcards from the Revolution.

Tie-in. I'll start by providing a document that supplements Mike's recent entry on policies and how they relate to processes: Managed Service Provider Security Policy. This document serves as an example policy document, and can be used virtually unchanged by any company that provides managed or outsourced services.

On the topic of processes and process improvement, Application Service Provider SWOT analysis (strengths/weaknesses/opportunities/threats) gives an in-depth look into all facets of ASP services. I also like the way Service Level Improvement Method discusses the ways to baseline service levels as a starting point for a process improvement initiative. Patching Blind Spots in IT Processes takes the improvement method in the former document one step further, and is valuable to anyone who is embarked upon IT process improvement.

Every minute of my weekend has been committed, so I'll not be posting here until Monday. Happy Easter.

Wednesday, March 27, 2002

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.

Tuesday, March 26, 2002

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.

Monday, March 25, 2002

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:

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:

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.

Sunday, March 24, 2002

Supporting Information. My independent research has intersected Mike's current series of entries on policies, processes and procedures. Among the documents that I've been reading that apply to Mike's topic are:The last two should interest anyone who is applying or implementing a quality program.

Quality and People. I've also posted two new reviews on Amazon that tie into the above documents:

Demystifying ISO 9001:2000: Information Mapping's Guide to the ISO 9001 Standard. I like this book for two reasons:
  1. It steps you through what it takes to implement a quality system based on ISO 9001:2000
  2. It shows how to develop your quality manual and documentation using Information Mapping techniques.
First, the approach to ISO 9001:2000. The author clearly explains what ISO 9001 is and what to expect in the certification process. If you're new to ISO 9001 (or 9002 or 9003) then the comparison in Chapter 2 between the 1994 and 2000 versions can be safely skipped. If your organization is already certified, or you wish to move from 9002 or 9003 to 9001, then the explanation of the differences is extremely helpful. Chapters 3 through 8 are standard fare that you would expect to find in any book about ISO 9000-series. What sets this book apart is the clear writing and ease of finding information. If you've read other books on the subject you know how dry they can be. This book is as lively as the subject matter permits (believe me, *any* book on the subject is going to be ponderous reading).

Chapter 9, Transition Planning, stands out as among the most valuable in the book (or any book about ISO 9000 in my opinion) because it covers the make-or-break issues for achieving certification. As an Information Mapping practitioner I especially liked the discussion of documentation considerations. I've long been convinced that Information Mapping and quality documentation should be integrated. With respect to ISO 9001 there has been much reluctance on the part of companies pursuing registration to stray from the rather ugly standard format of quality documentation. I hope this book changes that because the approach that the author proposes will add value to the quality manual by making it easy to read by all levels in your company, while keeping it 'assessor friendly' for certification and re-certification purposes.

People CMM. In the seven years since the 1995 release of the P-CMM, version 1 I've not encountered any sincere effort by any US client to implement the process. My personal theory is that the P-CMM was little known outside of the software engineering community, especially the DoD-related community, when it should have received wider dissemination to human resources and higher-level management. This book from a mainstream publisher should change that. With respect to the model itself, the previous reviewer has done a remarkable job of describing the model and how this book supports it. I have a few additional notes to add:

  1. This book is about version 2, which corrects some flaws in the first version which had team building at level 4. In version 2, described in this book, team building has been placed at level 3.
  2. Another change from version 1 to version 2 is the alignment of the P-CMM to the CMMI, especially with respect to integrated product and process development.
  3. Version 2 adds institutionalization goals to each process area.
If you have previous experience with the older versions of P-CMM, or CMM-SW, or the newer approaches as set forth in later versions and CMMI, you'll note that there are two implementation models: staged and continuous. The staged approach is the only supported implementation for P-CMM version 2.

The book goes into extraordinary detail about the P-CMM and how to implement it. You can easily use this book as a roadmap to achieving levels 2 through 5 of the P-CMM, or as a resource for improving the people part of the people-process-technology triad that defines IT. As such you need not have certification as a goal to gain value from this book. If you do decide to pursue certification at level 2 or higher, however, I strongly recommend that you also get a copy of Kim Caputo's CMM Implementation Guide: Choreographing Software Process Improvement. That book, while focused on implementing the CMM-SW, contains sage advice and a sound approach to dealing with the real problems that you'll encounter: organizational inertia and resistance, training and implementation issues and obtaining the key ingredient - commitment to perform.

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.

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]