Saturday, March 30, 2002
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:
- A brief (terse is a better word) PowerPoint presentation on Systems Theory.
- PowerPoint presentation on KM Metrics Framework (if you can't measure it, it doesn't exist!)
- Knowledge Management and the Enterprise
- 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.
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:
- 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!
- Familiar Metric Management - Effort, Development Time, and Defects Interact, which seamlessly ties together project and testing metrics.
- Customer Negotiation Metrics - 17 PowerPoint slides you should read before sitting down with your vendor.
Friday, March 29, 2002
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
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
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
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
- Assessing the Value of Business Intelligence
- Measuring Process Effectiveness
- eContinuity and the Internet
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.
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)
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.
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.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.
No approved change will be implemented without:
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:
- Entry criteria needed to initiate the change control process.
- 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.
- A completed test plan showing the results of testing the change in a pre-production or staging environment.
- Approval from the application owner(s) affected by the change and the business systems managerresponsible for the application or system being changed.
- A formal review by the Change Control Board to ensure that all entry criteria for the change have been met.
- The error will be communicated to all stakeholders of the affected system and/or application.
- 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.
- The action plan will be reviewed and approved by the individual's management chain and posted in a public place for review.
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
- Business Process and Business Document Analysis Overview and Business Process and Business Information Analysis Overview, which are also related to our previous ebXML entries.
- How to Document Quality Systems.
- Internal Quality Audits.
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:
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).
- It steps you through what it takes to implement a quality system based on ISO 9001:2000
- It shows how to develop your quality manual and documentation using Information Mapping techniques.
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:
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.
- 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.
- 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.
- Version 2 adds institutionalization goals to each process area.
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.
The newest issue of Methods & Tools is also out. This issue covers the following three topics:
- Understanding the Unified Process.
- Software Process Improvement: Assessing Readiness
- Web Site Mapping
Subscribe to Posts [Atom]