Review
Advance Business Institute review
by Mark
Nixon ABInsight, June 2002.
The following reviews were posted on Gantthead.com:
"The [book] was wonderful and fit together like a puzzle. Using the Titanic as an analogy is a great hook as well as teaching tool." (January 22, 2004)
"This is totally on the mark!"
(January 30, 2004 )
"I just read over all [of this
book] and found it excellent. Many of us have ofter referred to the
Titanic in working on projects, we now see how close we were. The
lessons learned from this tragety can be applied to projects today."
(September 18, 2004)
"My congratulations go to the the
author on a riveting [ebook]. I was glued to the screen, reading each
part to discover ‘what happened at the end’. If [he is] in PM, maybe [he
is] in the wrong trade. An excellent read."
(May 24, 2005)
"The book gives flesh-and-blood reality to the
need for honesty and integrity, the importance of creating a sensible
project management process, and the general management responsibilities of delivering on-line, on-time, and on-budget systems.
"
"Kozak-Holland provides sound advice to business executives and
tells a whopping good story to illustrate it and make it memorable."
Mention information systems and the eyes
of most business executives glaze over. Information technology is
complex, changes constantly, and can be daunting to senior managers
who are unaccustomed to working with it. Even when executives find the
technology exciting, projects to exploit it are often viewed as best left
to the technologists to handle with a weekly status report the only management
oversight that is considered necessary or desirable. While project management
as a discipline may be dull, managing projects, especially those involving
Web services, can be a death-defying feat. And in a world where the
Internet is increasingly influential in how a company communicates its
capabilities to the world and integrates its operations, systems projects
are too important to leave to systems people alone. Only executives who
have the business vision of what the system needs to do will have the
business knowledge, energy and motivation to see the project
through properly.
Mark Kozak-Holland in his new book, Titanic Lessons for IT Projects, has done this group of executives a valuable service by describing the roles and responsibilities executives must perform in a successful system project. A readable, interesting book about project management is a rare find but Kozak-Holland has written one. His book is hard to beat as a primer on how to approach an information systems project. Written for business managers with limited experience in systems technology, it is both insightful and pragmatic and relies successfully on the use of a highly vivid and well-known example of a project gone wrong, the luxury liner Titanic. Kozak-Holland describes the phases of a project life cycle systematically and draws the relevant analogies to the design, construction, testing and the loss of the Titanic in order to clarify the basic business issues in designing, building and implementing a new online system. The book is devoid of systems jargon and acronyms. It is full of rich examples of how to set objectives for a system, how to determine the nonfunctional as well as the functional requirements, and how to create an effective testing process. Throughout, Kozak-Holland focuses on one central point: the business executive who sponsors an on-line system needs to understand exactly what needs to be done, how it needs to be done, and the implications of not doing it correctly in order to communicate with and manage a systems "general contractor" successfully, whether the general contractor is the company's own systems organization or an outside company.
Unfortunately, systems people and business people often don't even speak the same language, much to one another's chagrin. Senior business executives, for example, are accustomed to the give-and-take of negotiation, where sometimes in order to make a deal work, it is necessary to leave some things ambiguous and not precisely defined. Systems people on the other hand, know that a system's function is binary - the system either works or doesn't - and that when the chips are down if it doesn't work, there is hell to pay. a wonder then that frustrations arise whenever non technology executives need to work with their systems counterparts.
As a result, many systems projects are left too ambiguous at the outset, lack the right level of business executive involvement, and encounter enormous problems in implementation, problems that stretch out the schedule, add cost to the equation and disappoint all who need to use the system.
In chapter one, Defining Your Strategy, Kozak-Holland discusses high availability, the primary characteristic of on-line systems, that distinguishes them from any other kind of systems project that the business executive might be involved with. If a system is on-line, a customer's expectation is that it will be available for use virtually all of the time. Kozak-Holland shows in a clear way, what the impact of non-availability is for an on-line system. He focuses on both the revenue potential of up-time and the opportunity cost of downtime as major factors in the evaluation of systems investment decisions.
In chapter two, Mapping Your Strategy, Kozak-Holland goes on to explain how requirements need to be defined and stresses the importance of nonfunctional requirements. While most executives focus on functional requirements - the use characteristics of the system from the customer's viewpoint - relatively few executives focus on the additional nonfunctional, usually non-visible, requirements that the system must meet in order to be successful. In the case of the Titanic, the functional requirements included the lodgings and guest services that were available to the mostly first-class passengers. Elaborate quarters, well stocked dining rooms and recreation facilities received considerable attention from the ship designers and were of high quality. More critical to the success and ultimately the failure of the Titanic, however, were the non-visible requirements: the ship's ability to stay afloat after a collision, the ability of the ship to turn, given its massiveness and speed, and the availability of lifeboats (or their lack).
Another nonfunctional requirement that Kozak-Holland addresses is the system's flexibility and adaptability to meet the needs of multiple sets of users. Without clarity about who will use the system, it is next to impossible to design a system that will meet all the requirements of being online, on-time and on-budget.
In one project that I managed, a Web-based system was purportedly being designed for the use of external customers (in this case, prospective insurance purchasers). Midway through the project, a new set of users was identified as essential, the company's customer service representatives who would receive customer phone calls requesting insurance rates and other information. Although the functional requirements did not change, the addition of this new set of system users increased the response time and system availability requirements above what would have been acceptable for external customers. This necessitated a different kind of system design that required the renegotiation of contracts with several external companies and stretched out the project schedule.
All too many executives have discovered - to their regret - that the system delivered is not the system that was expected or wanted. The cause, frequently, is that not all users were identified at the project's outset and that nonfunctional requirements were neglected.
Kozak-Holland illustrates this point by pointing out that part of the Titanic tragedy was caused by neglecting the requirements of passengers other than the first-class passengers, namely the steerage passengers and the crew. Because the ship was considered "unsinkable" due to innovations in the construction of the hull, inadequate provisions were made for escape in the event of a collision.
Kozak-Holland also relates an edifying tale, that most managers will recognize quickly, about cutting back on the production characteristics as a result of time and cost pressures. The hull had originally been designed to have an outer and inner hull that would preserve the ship afloat even if something penetrated the outside hold. This was cut back to less than half the height of the ship's hold, well below the waterline, in the interests of saving time, meeting production schedule, and reducing expense. In another example the vertical bulkhead walls of the 15 watertight compartments never reached the top deck as they were compromised by a long ballroom running horizontally, reducing their height to a mere 10 feet above the waterline.
Testing is another process that many business executives don't sufficiently attend to. Of course, making sure that a system meets the specified requirements is absolutely essential. Yet, once the system is constructed to meet the functional requirements, most business people are willing to let the systems people just verify that the system can perform the positive functions for which it is designed before putting it into production. Especially if deadlines are looming, the tendency is almost inevitably to make the system available without testing it in a simulated live environment.
This happened in the case of the Titanic. Rather than doing a full sail to shake out the ship, the assumption was made that it was sufficiently similar to its immediate predecessor that a full shakeout cruise was not necessary. Had the cruise been conducted, it is highly likely that some of the defects that ultimately caused the deaths of over a thousand people would have been discovered. Kozak-Holland explains in a succinct and convincing way what an executive should expect and require by way of testing, using the Titanic as a rich case example.
As Kozak-Holland reaches the end of the Titanic's journey and draws the final lessons, it is easy to see that a business executive responsible for a major systems implementation with large financial impacts on a company's business has a lot at risk in doing the job wrong. The book gives flesh-and-blood reality to the need for honesty and integrity, the importance of creating a sensible project management process, and the general management responsibilities of delivering on-line, on-time, and on-budget systems.
Kozak-Holland provides sound advice to business executives and tells a whopping good story to illustrate it and make it memorable.
© 2002-2003 IBM Advanced Business Institute
All rights reserved
Mark Kozak-Holland in his new book, Titanic Lessons for IT Projects, has done this group of executives a valuable service by describing the roles and responsibilities executives must perform in a successful system project. A readable, interesting book about project management is a rare find but Kozak-Holland has written one. His book is hard to beat as a primer on how to approach an information systems project. Written for business managers with limited experience in systems technology, it is both insightful and pragmatic and relies successfully on the use of a highly vivid and well-known example of a project gone wrong, the luxury liner Titanic. Kozak-Holland describes the phases of a project life cycle systematically and draws the relevant analogies to the design, construction, testing and the loss of the Titanic in order to clarify the basic business issues in designing, building and implementing a new online system. The book is devoid of systems jargon and acronyms. It is full of rich examples of how to set objectives for a system, how to determine the nonfunctional as well as the functional requirements, and how to create an effective testing process. Throughout, Kozak-Holland focuses on one central point: the business executive who sponsors an on-line system needs to understand exactly what needs to be done, how it needs to be done, and the implications of not doing it correctly in order to communicate with and manage a systems "general contractor" successfully, whether the general contractor is the company's own systems organization or an outside company.
Unfortunately, systems people and business people often don't even speak the same language, much to one another's chagrin. Senior business executives, for example, are accustomed to the give-and-take of negotiation, where sometimes in order to make a deal work, it is necessary to leave some things ambiguous and not precisely defined. Systems people on the other hand, know that a system's function is binary - the system either works or doesn't - and that when the chips are down if it doesn't work, there is hell to pay. a wonder then that frustrations arise whenever non technology executives need to work with their systems counterparts.
As a result, many systems projects are left too ambiguous at the outset, lack the right level of business executive involvement, and encounter enormous problems in implementation, problems that stretch out the schedule, add cost to the equation and disappoint all who need to use the system.
In chapter one, Defining Your Strategy, Kozak-Holland discusses high availability, the primary characteristic of on-line systems, that distinguishes them from any other kind of systems project that the business executive might be involved with. If a system is on-line, a customer's expectation is that it will be available for use virtually all of the time. Kozak-Holland shows in a clear way, what the impact of non-availability is for an on-line system. He focuses on both the revenue potential of up-time and the opportunity cost of downtime as major factors in the evaluation of systems investment decisions.
In chapter two, Mapping Your Strategy, Kozak-Holland goes on to explain how requirements need to be defined and stresses the importance of nonfunctional requirements. While most executives focus on functional requirements - the use characteristics of the system from the customer's viewpoint - relatively few executives focus on the additional nonfunctional, usually non-visible, requirements that the system must meet in order to be successful. In the case of the Titanic, the functional requirements included the lodgings and guest services that were available to the mostly first-class passengers. Elaborate quarters, well stocked dining rooms and recreation facilities received considerable attention from the ship designers and were of high quality. More critical to the success and ultimately the failure of the Titanic, however, were the non-visible requirements: the ship's ability to stay afloat after a collision, the ability of the ship to turn, given its massiveness and speed, and the availability of lifeboats (or their lack).
Another nonfunctional requirement that Kozak-Holland addresses is the system's flexibility and adaptability to meet the needs of multiple sets of users. Without clarity about who will use the system, it is next to impossible to design a system that will meet all the requirements of being online, on-time and on-budget.
In one project that I managed, a Web-based system was purportedly being designed for the use of external customers (in this case, prospective insurance purchasers). Midway through the project, a new set of users was identified as essential, the company's customer service representatives who would receive customer phone calls requesting insurance rates and other information. Although the functional requirements did not change, the addition of this new set of system users increased the response time and system availability requirements above what would have been acceptable for external customers. This necessitated a different kind of system design that required the renegotiation of contracts with several external companies and stretched out the project schedule.
All too many executives have discovered - to their regret - that the system delivered is not the system that was expected or wanted. The cause, frequently, is that not all users were identified at the project's outset and that nonfunctional requirements were neglected.
Kozak-Holland illustrates this point by pointing out that part of the Titanic tragedy was caused by neglecting the requirements of passengers other than the first-class passengers, namely the steerage passengers and the crew. Because the ship was considered "unsinkable" due to innovations in the construction of the hull, inadequate provisions were made for escape in the event of a collision.
Kozak-Holland also relates an edifying tale, that most managers will recognize quickly, about cutting back on the production characteristics as a result of time and cost pressures. The hull had originally been designed to have an outer and inner hull that would preserve the ship afloat even if something penetrated the outside hold. This was cut back to less than half the height of the ship's hold, well below the waterline, in the interests of saving time, meeting production schedule, and reducing expense. In another example the vertical bulkhead walls of the 15 watertight compartments never reached the top deck as they were compromised by a long ballroom running horizontally, reducing their height to a mere 10 feet above the waterline.
Testing is another process that many business executives don't sufficiently attend to. Of course, making sure that a system meets the specified requirements is absolutely essential. Yet, once the system is constructed to meet the functional requirements, most business people are willing to let the systems people just verify that the system can perform the positive functions for which it is designed before putting it into production. Especially if deadlines are looming, the tendency is almost inevitably to make the system available without testing it in a simulated live environment.
This happened in the case of the Titanic. Rather than doing a full sail to shake out the ship, the assumption was made that it was sufficiently similar to its immediate predecessor that a full shakeout cruise was not necessary. Had the cruise been conducted, it is highly likely that some of the defects that ultimately caused the deaths of over a thousand people would have been discovered. Kozak-Holland explains in a succinct and convincing way what an executive should expect and require by way of testing, using the Titanic as a rich case example.
As Kozak-Holland reaches the end of the Titanic's journey and draws the final lessons, it is easy to see that a business executive responsible for a major systems implementation with large financial impacts on a company's business has a lot at risk in doing the job wrong. The book gives flesh-and-blood reality to the need for honesty and integrity, the importance of creating a sensible project management process, and the general management responsibilities of delivering on-line, on-time, and on-budget systems.
Kozak-Holland provides sound advice to business executives and tells a whopping good story to illustrate it and make it memorable.
© 2002-2003 IBM Advanced Business Institute
All rights reserved