|Book Review: Rainbows and Ratholes|
Rainbows & Ratholes: Best Practices for Managing Successful Projects
Written by: Dhanu Kothari. Charleston, SC: Booksurge, LLC, 2006. 147+xii pages.
This book about project management is definitely the best down-to-earth guidance I have come across in one place in more than 30 years of reading about, writing about, and doing project management. It doesn't describe the details found in most thick project management texts and how-to books but is more a guidebook for doing the right, practical things and for knowing what wrong things to avoid. Whether you are brand new to product development or an accomplished project manager, there is much in this book for you to learn.
The funny name of the book comes from Dhanu Kothari's metaphors of finding a pot of gold at the end of a rainbow as successful project events (i.e., catching rainbows) versus keeping a project from going down a rathole, which by innuendo is a nasty, dirty, dangerous place you don't want to be. I think most project managers would agree, and many have found themselves in a rathole from time to time. Kothari's stated purpose for the book “is to bridge the gap between theory and practice of project management” (p. 1), and it offers some great practical advice about how to do this, whether for managing product development projects or any other kind of project.
Organized in a series of short essays—17 to be exact—this small paperback from an experienced project manager overflows with common-sense guidance for making projects succeed. There are lots of lists of practical definitions and steps to take to achieve success regarding the particular item being discussed. These are provided at the end of each section as learning lessons to help avoid the ratholes and as best practices for finding the rainbow's pot of gold. The author's method is a refreshing approach of asking basic questions (e.g., What does a project manager do? What does that mean? Why are we doing this project?) and then answering them in clear, unambiguous language. The author obviously understands what someone managing a project needs to do to succeed and creates an understanding of what each of these things is that really needs to be done.
The book opens with 10 prerequisite characteristics of a project. This ensures that the reader clearly understands the author's definition of a project, which fits any project, big or small. The nine knowledge areas of the Project Management Institute's (PMI) project management body of knowledge (PMBOK)—scope, time, cost, human resources, risk, communication, contracts, quality, and integration—guide the rest of the book's discussion. But this is not just a rehash of the PMBOK. The author provides a compendium of real-life, practical things to do and not do while managing any project. For example, the section about the scope of the project includes questions and a list of things that making scoping difficult, techniques for how to do it, and emphasis on the importance of the work breakdown structure.
Uncertainty receives appropriate attention as it is an abundant quantity in nearly all projects and leads to significant risk. This is especially true at the project start when the most unknowns occur but also throughout a project where new or unknown risks can be a death knell. To stay out of ratholes because of uncertainty, the project manager must know and understand the risks involved and have plans to deal with each of them should they occur. In fact, this may be the project manager's most important role for ensuring that a project meets its constraints of time, cost, and scope. The author identifies the necessity to clearly separate risks from assumptions (which may lead to significant risks), issues, and changes. He accurately states that, even though risks are future events, issues deal with present situations to be resolved, and changes are deviations from previously defined plans.
The need to communicate in the right language to stakeholders (i.e., anyone who has a stake in the project) leads to a set of 10 questions about return on investment for which senior management needs answers. Without clear answers, “the project is in a rathole” (p. 17). These questions need to be answered before the project is approved, so they arise after collecting some basic information about the project. The project manager must also be clear on answers to questions about the business case. Some of these questions include the following:
How does it help meet our business goals?
Where is the budget coming from?
What is the return on investment and business risk?
What is this project's priority?
A list of 10 roles from management to user includes descriptive material about each role and how the project manager needs to understand and manage the relationships among all of them: “The project manager's role is to do the right thing for the project” (p. 135). This is easy to say but often difficult to know the right thing to do. Senior management's role is to ensure the project's alignment with the business and to establish the rationale for authorizing projects. Two main questions for the project manager to focus on are as follows: (1) Why are we doing it? and (2) When will it be completed? There are also six basic steps for the project manager to follow with senior management when assigned to a new project. Perhaps the two most useful points are to remember that (1) “a project is a means to an end, not the end itself” (p. 21) and “scope follows objectives” (ibid.). The role of others on the project is made clear through a roles-and-responsibility matrix. For this, Kothari uses the RACI matrix model (Responsible, Consult, Approval, Inform) to identify who does what and who decides what. A lot of the good advice found in this book will help any project manager reflect on the right thing to do.
One frequent topic of discussion in the world of managing projects—often claimed to be the most serious problem facing a project manager, especially among weaker project managers—is the dilemma of having more responsibility than authority. Kothari brings up the need for leadership to exercise authority, to delegate responsibility, and to get accepted commitments, and he labels the perceived lack of authority as a myth. By virtue of being positioned as a project manager, “you have all the authority you need to do the right thing for the project and your client” (p. 12). Authority is often quoted as a problem for project managers but Kothari's view was also recently emphasized in a book about alpha project managers (Crowe, 2006). Both say that the authority to do the project is both formal from the project charter and implicit in the role of project manager. Superior project managers (alphas) take the authority necessary to get the job done.
Throughout the book, there is a strong focus on the importance of “getting the baseline right” (p. 23), because of a bias by many who want to get started on the work right away. Some good advice is that project management is a tool, but if you only need tools, templates, and forms then there is no need for a project manager. Among the 10 steps for creating a sound baseline schedule is the warning to keep in mind that “the schedule is not the plan…. It is a result of the planning process” (p. 28).
After planning the project, the development of the implementation roadmap—a network diagram—begins. Three stages described in the book for doing this are (1) what is dependent on what, (2) where is the critical path through the project, and (3) what is the final schedule based on the results of earlier stages. To complete each stage Kothari describes multiple activities and provides additional steps as guidance to create the network diagram. Documenting what needs to be and has been done follows the philosophy that for something to exist, it must be documented. The guidance to accomplish this is found in a detailed table of contents of a project workbook that contains 15 items for the project plan and 5 working documents. When completed, each step is accepted by a signature. This workbook provides a great template for the project plan.
Kothari ends the book with several sections about people, soft skills, and the importance of communication. This author clearly understands the importance of people for projects to be successful and therefore the need for a project manager's people skills. Adding people on any project causes more work for the project manager. His guiding statement about this is, “Who's doing what to whom?” (p. 41) “People make things happen” (p. 111) is something Kothari understands well, and this is perhaps the most difficult area for many project managers. The book concludes with a set of best practices about customer focus, sponsorship, relationships, teams, and process that could easily be the opening pages of the book. This book is a best read for all types of project managers.