Work Management and PM2.0: What's All the Hubub?

A recent blog post by Geoff Crane, the PaperCutPM, has created some discussion around the office.  In his post Garbage in, Garbage Out. Haven't We Learned That Yet?, he shares his view regarding PM2.0.  His comments were interesting enough that I thought I would weigh in on one or two of them myself.  His blog post is an interesting read, which I am happy to recommend.  Although I don't know if I agree that the next generation of project management software will be a non-event, I do agree that without a proper framework for project management tools to operate within, PM2.0 will fall short.

I hope he won't mind if I borrow his format:

1. Tools don't manage.  People manage.  I couldn't agree more with Geoff when he says, "...I don't have any illusions that a tool is anything other than an inanimate thing waiting to be put to use by someone who knows how to use it."  However, I'd like to push this a step further.  The real goal of PPM software should be to automate those processes that can be automated (like data collection and report building), so project managers can successfully lead project teams.  I don't think you can "manage" a report or status update, but a good project manager can motivate and lead the people on a project team.
2. Hiring managers and financial control are as desperate as ever to find ways to save money.  Yes they are.  That being said, I don't think we articulate our value to the process as well as we could.  In a post from last January, I addressed a comment made by a fellow project manager who described what she was doing as being Knee Deep in Project Management.  As a profession, we need to talk more about the business value project managers provide and less about the process that is managed.  If we can successfully do that, the "irresponsibility" of assuming that a software solution could replace a skilled project manager will be obvious and laughable.
3. Collaboration is worthless without a framework.  According to Geoff, "Frameworks are not one-size-fits-all.  They are unique to each project.  Software is not going to define your framework for you."  Geoff is correct, and what's more, if you don't have a framework or work management methodology in place before you implement a new project management software, the implementation will be lengthy and cumbersome—and adoption will suffer.  After speaking with dozens of customers over the years I have observed that successful implementations are generally preceded by an established methodology.  Software, by the way, should adapt to your processes, not the other way around.
4. Projects require decision makers.  AMEN.  Projects are highly fluid and never follow the plan with exactness.  The ability to make decisions, often on incomplete or even sketchy data, is something that software can't do.

"Regarding this very naive notion that software can somehow replace leadership, experience and knowledge, and that team members will play nicely together by default, collectively united towards a common goal?  To that I say, 'nonsense,'" says Crane. 

I must agree.  There may be companies who look to software as the silver bullet that will solve all their problems, but like Geoff, I think that is a pretty naive view.  Will an organization doing project based work benefit from the tools available today?  Absolutely.  However, you wouldn't put a nail-gun on the shop table and expect it to build the furniture itself, would you?