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
From Vol. 1, No. 1:
Book Commentary:
Quality Software Management, Volume 1, Systems Thinking
by Gerald M. Weinberg, Dorset House Publishing, 1992
I originally read and used this book while I was an SQA Manager at a Boston-area company. I was trying to understand why my quality initiatives were only sometimes effective. I bought the book because I was sure there was something in my system (the company, the other employees, me, the products, etc.) that was preventing me from succeeding.
The book is divided into five sections: "Patterns of Quality", "Patterns of Managing", "Demands that Stress Patterns", "Fault Patterns", and "Pressure Patterns". Each section has a number of chapters that examine different systemic aspects of software product development.
In "Patterns of Quality", Weinberg challenges our assumptions about what quality is, how to obtain it, and how to recognize how to change it. This section provides compelling reasoning about quality models, and about how just repeatable processes can be antagonistic ongoing quality improvement.
The "Patterns of Managing" section was truly eye opening for me. I had been working on a measurement system at the company, and had been spectacularly unsuccessful at obtaining useful metrics. When I read this section, I understood more about how other people perceive their work. That help me modify my approach to gathering metrics, and I became successful over time.
"Demands that Stress Patterns" discusses what happens in real organizations with real customers and real products. Weinberg has a number of ideas about how to keep the development organization working productively.
"Fault Patterns" discusses types of defects and how they occur. In addition, Weinberg defines software faults (defects and failures). He gives a number of examples of how organizations generate, find, and fix software faults.
"Pressure Patterns" examines managerial behavior and why managers lose patience and feel helpless.
I had originally hoped to solve specific metric concerns by reading this book. But, I learned much more about my behavior and how it fits in a system. Once I read the book, I understood more about how to effect change with my peers so that I could improve our quality practices and we could all succeed at turning projects into products.
Both Dorset House and Gerald Weinberg have web sites. See www.dorsethouse.com and www.geraldmweinberg.com.
From Vol.1, No. 2:
Book Commentary:
by Tom DeMarco, Dorset House Publishing, 1998.
Webster Tompkins thinks he's in a little trouble. He's almost right. He's really in a lot of trouble. Lakhsa Hoolihan is Moravian and mysterious. And beautiful. She's got Webster Tompkins enthralled and challenged. To live up to Lahksa's expectations, Webster agrees to manage three parallel software projects.
Tom DeMarco may be best known for his 1987 classic with Tim Lister, Peopleware. His management experience and stories of management made Peopleware valuable for managers and people who planned how software people would do their work.
In The Deadline, DeMarco uses a novel to convey smart project management ideas in story form. A beautiful Morovian woman, Lahksa Hoolihan, kidnaps Webster Tompkins (our hero) after Webster is laid off from a large software organization. Lahksa challenges Webster to run a state-run project laboratory in Silikon Valejit. Tompkins has the resources to run three parallel projects, and see what happens on the different projects with different goals.
Tompkins keeps a journal of tips and important things he learns during the project. Some things he knows in advance or learns by himself and some he learns from somewhat-disguised software engineering authors and gurus. (I had fun identifying the people--I hope you do too!)
During the project, Tompkins gets to deal with an interfering Morovia president, an administrator who measures the wrong things and wants to shorten the project's deliverable dates, managers who don't want to manage, meetings that don't have agendas, difficult people, and more.
Tompkins starts his journal with the four essentials of good management:
- Get the right people.
- Match them to the right jobs.
- Keep them motivated.
- Help their teams to jell and stay jelled.
(All the rest is Administrivia.)
I've worked with some managers who use stretch goals as their estimates. Then they have the nerve to be disappointed when the project doesn't meet the goals. Webster has some radical common sense:
- A project needs to have both goals and estimates.
- They should be different.
During his time managing the project laboratory, Tompkins and his managers, a bag lady and an ex-general:
- Model and simulate the project using systems dynamics;
- Measure the projects' size with function points;
- Understand how people's humanity can help or hinder the project;
- Deal with externally-imposed process improvement;
- Deal with externally-imposed date changes;
- Rethink the product development process to deal with project success!
DeMarco has written a very readable and engaging book. If you are a project manager, if you manage project managers, if you work with project managers, or if you work on a project, you should read this book. Remember, as Tompkins says just before he marries Lahksa, "Miracles may happen (but don't count on them)."
Tom DeMarco is part of Atlantic Systems Guild, www.atlsysguild.com, and the publisher is Dorset House, www.dorsethouse.com.