Management Consulting
Project Jump Start
Management Coaching
Workshops AYE Conference
Project Management
Management
Hiring
Requirements
Consulting
Process Improvement and Quality
Managing Product Development
Hiring Technical People
Manage It! Your Guide to Modern, Project Management
Behind Closed Doors: Secrets of Great Management
Hiring the Best Knowledge Workers, Techies & Nerds
Corrective Action for the Software Industry
Amplifying Your Effectivess
Speaking Calendar
Testimonials
Resume
Contact
Book Commentaries from Reflections, Volume 3
- Software Project Manager's Handbook, Principles that Work at Work
- Software Requirements
- Adaptive Software Development
Book Commentary:
The Software Project Manager’s Handbook, Principles that Work at Work
Dwayne Phillips (1998)
If your software projects are unbalanced or unpleasant, buy this book.
Dwayne Phillips’s project management handbook is full of suggestions for the experienced and not-so-experienced project manager, focused on finding a reasonable way for the project to proceed. With a sense of humor and a direct way of saying what project managers need to know, he talks about balancing the 3Ps: people, process, and product.
Project managers need to consider the people, because the people get the work done. Many of you may think this is nothing new, but I meet project managers (PMs) s all the time who are very attentive to the process, or to the product, but forget about the people. Sometimes, I meet PMs who consider only the product, without considering the cost of using a particular process, or the cost to the people of working this way on this particular product. Phillips says we work for the product, and the best way to work for the product is to balance the 3Ps.
Not only does Phillips consider the people on the project; he considers the project manager. In Chapter 1, he makes four suggestions for project managers: be flexible, have compassion, know when to lead and when to manage, accept the role of meetings. In Chapter 2, he says, "You cannot build a more difficult product without increasing capability." Then, Phillips goes on to suggest ways to increase capability, such as training or prototyping before development. Although Phillips doesn’t directly say it, this book is a great way to increase capability of the project manager.
In chapters 5 and 6, Phillips addresses the fuzzy front end of the project: requirements and planning. I particularly liked part of chapter 6, Making the project visible: Estimating techniques. When I teach project management workshops, estimation is the one piece with which even experienced project managers still have trouble. Phillips has suggestions for tailoring estimation techniques for waterfall, evolutionary, and spiral lifecycle projects.
Phillips suggests time boxing as a technique for managing schedule risk. Time boxing isn’t a new approach for project managers, but Phillips discusses ways to make time-boxed projects work. From page 181: "If time is important, don’t buy time by adding people. Rather, cut features (find the 20% that meets 80% of the needs). Turn time into a time box, reduce the product to fit the time box, save money and reduce risk."
In Chapter 11, Phillips has indispensable suggestions for project managers, such as to use a journal. In a recent project management workshop, I suggested the participants start writing a daily journal, as a way to track what they were doing. The newer PMs were shocked. However, an experienced PM said, "Oh, I’ve been doing that for years. It’s a great way to learn from my mistakes, and become a better project manager. I especially use my journal when I’m angry about what’s happened at work. Journalling helps me understand why I get so angry, and what I can do about it."
Chapter 11 also contains a "cookbook", where Phillips describes how to plan and manage three projects: waterfall, evolutionary, and spiral projects. He includes details for each project, including major milestones and risks.
Whether you’re experienced or new to project management, you will get valuable tips from this book. Moreover, if you’re having trouble keeping your projects balanced, this book can help you pinpoint your problem areas, and fix them.
Software Requirements
Karl Wiegers, 1999.
"Ok, I'm ready to start on requirements. What do I have to read to get started?"
Engineering managers ask themselves this question with a large sigh and a look as if the weight of the world was on their shoulders. When I teach requirements workshops or talk to people about how to elicit and manage requirements, I recommend two books to start: Gause and Weinberg's Exploring Requirements, Quality Before Design, and Wiegers' Software Requirements. If they need the structure of the Volere template or fit criteria of the Robertsons' book (see Reflections Vol. 2, #4), I also recommend Mastering the Requirements Process.
You may have noticed that both Weinberg and Wiegers are on Reflections' advisory board. However, I'm writing about their books not because they are on the board, but because their books, like the others I write about in this column, are ones I can highly recommend.
Wiegers has created a readable, practical book about gathering and managing requirements, focused on best practices. Wiegers says, "The best practice approach emphasizes stocking your software tool kit with a variety of approaches you can apply to diverse problems." Wiegers uses examples to illustrate the problems and how to apply the possible solutions to your requirements concerns. Here are two examples, in particular, that caught my attention.
In Chapter 13, "Setting Requirement Priorities", Wiegers addresses the real-world problems of juggling project priorities, even after the project is well underway. Wiegers provides a spreadsheet to help decide on the relative priority of a requirement. The spreadsheet lets you assign values for benefit, penalty, cost, and risk, to derive a priority. I have suggested this spreadsheet to my clients as a tool for decision-making. Although the ones who tried it have never completely filled out the spreadsheet, they found the discussion it stimulated about the requirements extremely helpful in deciding the relative priorities of the different requirements.
In Chapter 17, Wiegers uses a familiar example to discuss how to manage change requests. The customer or marketing person looks for team members who will say "yes" to a change request, and then presents the change to those people. That's not an effective way to manage scope creep. Among the more robust ways to manage scope creep, Wiegers suggests clearly defining the project's scope, establishing a change control board and using a template he supplies for a change control process.
At the end of the book, Wiegers includes a 20-question self-assessment so you can see how well you currently manage your requirements. I've used the self-assessment with some clients who initially thought they were doing a great job managing their requirements, Although they couldn't understand why their projects were late, the self-assessment was valuable in helping them see why they couldn't keep their projects scoped.
Software Requirements is full of examples, checklists, and spreadsheets to help you organize and manage your requirements.
For more information:
Karl Wiegers web site is www.processimpact.com
Microsoft Press web site is www.microsoft.com/mspress
Book Commentary:
by Jim Highsmith (2000)
"The greatest risk we face in software development is that of overestimating our own knowledge" Jim Highsmith, Adaptive Software Development, A Collaborative Approach to Managing Complex Systems, page 14
Jim Highsmith takes an alternative approach to managing software projects, saying that adaptivity is much more important than a repeatable process. He says the "CMM is a workflow model, based on the belief that complex products can be effectively attacked by breaking a large process into ever-more-refined subprocesses." Jim goes on to say, "The secret to managing complex adaptive projects is to apply increasing rigor to the results, not to the process."
Jim claims there are three components to adaptive software development: the adaptive conceptual model, the adaptive development model, and the adaptive (leadership-collaboration) management model.
An adaptive conceptual model of a project is a self-organizing, evolving system, where the people understand what they have to do, even if they don't always understand exactly how they're going to get there from the start. The adaptive development model starts with an iterative development lifecycle, modified by the developers' ability to generate an emergent system. The adaptive management model is the change of managers from command-and-control to a leadership-collaboration mode of working.
If you are working in an environment where there is tremendous pressure to ship quickly, and where change happens constantly, then you may have seen some successful projects emerge from very fuzzy starts. Highsmith has suggestions for continually creating a project environment that helps people live with those fuzzy starts, and create a project and a product of which they can be proud.
One of those suggestions is iterative lifecycles. In chapter 4, Jim discusses characteristics and examples of adaptive lifecycles: mission-driven, component-based, iterative, time-boxed, risk-driven, and change-tolerant.
In addition to the lifecycle discussion, Jim includes eight guidelines for applying rigor to project work in Chapter 10. He focuses on how to make the collaboration between groups work, not on how to make each group work better by itself. This part shouted at me: Break down the silos!
In my experience, management is the most critical component of a project, and the hardest to change. I particularly enjoyed Jim's discussion of how some managers who are stuck in command-and-control have a static view of the world, which prevents them from making sense of their current environment. Adaptation is a necessary and critical skill of competent managers. He contrasts the command-and-control managers to leader-collaborator managers, who learn how to make sense of the world, even if it doesn't conform to their well-understood beliefs.
Adaptive Software Development is a thought-provoking book. I enjoyed the mountain-climbing examples, and was able to adapt those examples to projects that I have worked on.
For more information:
Jim Highsmith's web site: www.adaptivesd.com
Publisher, Dorset House: www.dorsethouse.com