Monday, May 13, 2002
Random Thoughts. This entry has two fuzzy objectives: (1) a warm-up exercise for some work that I need to get done, and (2) fill in missing pieces from the previous entries.
As-Is and To-Be. One mistake I see in one project after another is the quest to document existing systems before defining its replacement. Here are some rules-of-thumb that I use to determine whether or not the 'as-is' analysis needs to be performed. If:
Considering that many projects are revolutionary in nature time, resources and money are wasted documenting something that is being replaced.
- The new system (or business process) represents a revolutionary approach (completely toss out the old for something radically different), the 'as-is analysis is wasted effort. Reason: If conditions and requirements have so changed that a revolutionary approach makes sense the last thing you want to do is replicate old methods and processes in the new system. A better approach is to elicit and prioritize requirements for the new system, and these requirements should reflect business functions and imperatives that are driving the need for a revolutionary approach. In other words, approach the requirements phase within the context of business rules and features/functions that are required. If you approach it this way you'll be getting a fresh perspective and making a clean break from the past. Of course, there are technical aspects that need to be analyzed, such as system interdependencies, data structures, operational requirements and the such because rarely will an old system be tossed out and a new one magically take its place. Therefore, the 'as-is' analysis will support requirements for data conversion, batch job synchronization and comparing resource requirements between the old and new system (impact on network, service levels and up- and down-stream systems that will remain).
- The new system (or business process) is evolutionary (i.e., process improvement, upgrade, etc.), then the 'as-is' analysis does need to be performed to determine how to best improve processes and the way upgrades will require changes in processes or infrastructure.
Another fallacy is to document the status quo in preparation for a brand new system or business process. Don't waste your time - it only provides revenue for consultants. The time and money are better spent on tracing requirements to business imperatives and going forward from there.
One other fallacy is to spend time developing documentation for systems when commercial documentation is available. During one engagement I was tasked with writing database administration policies and procedures. At my billing rate the final product ran into the tens of thousands of dollars. Aside from the fact that the document shortly became shelfware, the client could have purchased any of a number of excellent books in the $40-60.00 price range, and decreed that the procedures contained within were to be followed as a matter of policy. Selecting and recommending the best book from the many that were in a local book store would have saved a significant amount of money. Even better would have been to ask the DBAs to agree on the best commercially-available book and use it. The sorry fact is that, as I write this, there are consultants who are developing UNIX, Oracle and [pick your favorite application, database or operating system] documentation when excellent books may already be available.
Learning to Think. The point to the above is that thinking is required. Not problem solving - thinking in a critical manner. Question the status quo and don't be misled by misdirection, fallacious arguments that have logical flaws or appeal to emotion. Perform a mental sanity check on approaches that are normal practices, but waste resources and shareholder value. A few months ago I read a book titled Turning Numbers Into Knowledge: Mastering the Art of Problem Solving. I was expecting a book about quantitative methods and advanced problem solving techniques. What I got, instead, was a book that didn't even discuss numbers until page 111 of a 221 page book, and it was lite on problem solving techniques. Although it was not what I expected it turned out to be one of those rare books that deeply influences and provides fresh perspectives. The book led me on a journey that broke the process of critical thinking into manageable steps. Among the things I learned were:
Overall this book is one of my personal favorites and one that I recommend to colleagues. Another book that complements this one nicely is Systems Thinking: Managing Chaos and Complexity. See Kate's 22 March entry for details about this book.
- Examine key factors, such as information, attention and action within the context of a cycle of actions that begins with goals, and moves through execution, how events in the external world influence the meeting of those goals, an evaluation and refinement of goals. Then the process starts anew.
- Structured methods for getting organized. The techniques given are simple, yet powerful.How to collect and critically analyze data and information, common fallacies and how to spot them. Two of my favorite parts that reinforce these are then single-page chart titled "What Scientists Say, and What They Mean", and Chapter 20 (Uncertainty Principle and the Mass Media).
- The straightforward process of numerical analysis, using relatively simple math techniques to make sense of numbers and turn them into knowledge, is priceless. What makes this part of the book valuable is that the author integrates the preceding chapters that lead you to a critical thinking mindset with common sense and techniques that are within the grasp of high school students. It looks easy, but is testimony to the author's exceptional ability to communicate and inspire.
On that note I am officially starting my workweek. Best regards from Tustin, California.