This is a list of books currently on my To Read shelf... literally. I do not suggest or anti-suggest any of them at this time as I haven't read them yet.
Current Efforts:
Blue Parabola, LLC
HubAustin
web2Project
PHP'ers:
Cal Evans
Eli White
Elizabeth Naramore
Joe LeBlanc
Matthew Turland
Matthew Weier O'Phinney
Planet PHP
Tony Bibbs
Business/mISV:
Bob Walsh
Eric Sink
Joel Spolsky
Micah Baldwin
Paul Graham
Past Projects:
CodeSnipers
HOBY
Judicial Watch
mobile FoxNews.com
NRTW
Great Tools I use:
Drupal
GitHub
NetBeans for PHP
phpUnit
Subversion
Zend Framework
This is not the home of dotProject or web2project. It is the home of CaseySoftware, LLC. Any dotProject support questions should be referred to their support forums.
On my daily blog tour, I came across a post via the Professional PM News Blog where he points to a Project Manager Checklist and I found the list informative.
I've worked for a number of organizations - both public and private and both commercial and government - and the variances in Project Management Processes has always fascinated me. One organization used something very close to the eXtreme Programming methods, another used a strict Capability Maturity Model (CMM), a third used the "mushroom model" - or "Keep the developers in the dark and feed them sh..", and finally one used a pure firefighting model. At that final one, the division head kept a priority list with three rankings - Low, High, Very High - but I digress.
These Checklists serve as a solid foundation, but don't let them lull you into a false sense of security. No process or checklist can make a project successful. Let me repeat that, NO process or checklist can make your project successful. A process can deter specific failures/errors, but there are always new ones lurking out there waiting to bite you.
If you don't have a process in place at all, these Checklists will help you get started. They focus on simple aspects such as having the proper resources in place, tracking defects/issues, ensuring quality, clearly defining milestones and deliverables, addressing risks, and managing change. These areas are the most problematic and potentially damaging parts of any project. There is no point in reinventing the wheel, get these documents, customize them for your organization, evaluate their usefulness, and then make a decision. That's the nice thing about a process. Once you have a process established, there can be changes to it, you simply must evaluate the value of the change and figure out how to do it.
As I've told quite a few developers, team leaders, and clients: When there are mistakes made, I want them to be completely new and extraordinary.
Your processes should be the same way. Your base process should cover the majority of the situations your team will face. They WILL NOT cover all of them, but those serve as perfect opportunities for growth.
Post new comment