Over the last couple of years, the PMP title has become the latest fashion accessory. Unfortunately, most of the people I've dealt with have tried to enforce every facet of PMP on even the smallest of projects. They've also mostly been freshly minted so they really don't have any experience. All this has lead to projects mired in paperwork, behind schedule and ticked-off users.
Over the years, I'd developed my own style that seemed to work and got a few requests to teach my style to some of the other developers. Problem was, I'd never really formalized anything. I just kinda did things. So over the last couple of months, I've been working on formalizing some things.
I spent some time looking into the PMP and can see where it would bring extensive value to lots of projects, especially construction or manufacturing. There are pieces that I can see would be beneficial to the contractual side of software development. The main thought I had was that PMP would never directly lead to even one line of code! Worse, a manager would never be able to tell the true status of a software project really because they don't work like that!
PMP is based on dependencies between segments and developers actively try to avoid those dependencies to prevent fragile designs. It also considers something complete when we know that change is inevitable! The specs from yesterday are not the specs for today. That library we completed yesterday can, and probably will, change today!
I'd looked at Test Driven Development and found I was doing some of the techniques but not all. I'd also looked at Agile software development and found the same thing. Further research into both lead me to a book that pretty much had everything I used. The book? Agile Principles, Patterns, and Practices in C# by Robert C. Martin and Micah Martin.
This book truly lays out a process for developing software. Manager, architect and developer will find what they need. For the developer, it has how to get stared coding now while still being able to answer the managers questions (can you say Status Report). The architect will find all of those things you've been thinking or saying for years neatly. Design patterns, UML, code smells and my favorite, design smells are all found in this book.
The best part about this book is not what is says to do but what it says not to do. The mantra carried throughout this book is "Don't produce a ton of paper that will be thrown away or change tomorrow". Since I hate wasting time on needless documentation, this book spoke my language. Before you say that your bosses will never go along, remember this. I work in a shop that defines anal. They believe that if you don't have it in triplicate, it's not real. This book gave me all the ammo I needed.
Another book you may want to invest in is Head First Design Patterns by Eric Freeman, Bert Bates, Elisabeth Freeman and Kathy Sierra. This presents the top design patterns in a funny manner. Head First books are definitely not your standard tech books.
Between these two books, I have been able to "formalize" my style and have actually enhanced it. Things that I did because they seemed right, I now can name and articulate the reasons for using or not using them.
What about PMP? Is PMP bad? No. Should I avoid PMP like the plague? No, but don't do it because it's cool. Pick the parts of PMP that bring value to the project and use them. If someone can't show or explain the benefit of a document, don't produce it! Most of all, skip the PMP checklist.