I've always thought of software project management as kind of a sheep herding process, although I'm sure most project managers ( PM ) would think of it as more of a cat herding process. However for most of my career there's been, for the most part, no process whatsoever no matter where I worked.It wasn't because of the lack of methodologies to adopt. At one place the PMs decided they would start practicing RUP - Rational Unified Process. Personally I never believed they got it quite right beyond assigning tasks. But it was only after several more years of doing software that I finally realized why they got it wrong.
Essentially I think it goes like this:
The reason so many projects cannot be classified as successes is that they are "managed" - hence the title of those who "manage" them - Project Managers. Management is for resources. Resources are nails, wood, dirt, concrete, time - the kind of stuff you use up ( think "consume" ) to complete a project. People are not resources no matter what that department down the hall likes to refer to itself as. You know the one, the one whose name begins with "human." Do you consume people to finish your projects? I hope not!! Are you making Soylent Green?
Most PMs will look at a situation like this . . . some tasks need to be completed in a specific time frame. Naturally the PM asks a senior developer how many developers, UI people and time will be needed. While many senior developers will do the best they can, they leave out some very important things like access to systems, databases and data, testing coordinators, software and the appropriate environments. The PM doesn't know any better because they have good people skills, but very little technical knowledge.
Some managers ( I'm not referring to PMs ) know this kind of stuff if they have the appropriate background, however they're not often involved in the task assignment process. They might become indirectly involved via other meetings. Perhaps if they were involved earlier they might be able to provide the appropriate facilitation recommendations.
I believe that the Project Management title should really be changed to Project Facilitator ( PF ). Really the only things that PMs manage are the expectations of the client with the reality that is happening as the software ( or other project ) is being built. Of course a whole mindset change will be involved to actually make this work. Instead of a PM asking, "How many hours do you need to finish this?" a PF will be heard asking, "What is needed in order to complete this as requested?" Afterwards, the PF will remove the necessary roadblocks so that the developer ( or developers ) can complete the tasks.
Unfortunately the bulk of PM is completed now with software. A PM creates the project, makes some pretty pictures and starts creating tasks and assigning developers to create the tasks within the time lines that may or may not be realistic. Hopefully the PM has actually asked someone with a technical background if they are realistic.
Since you have to pick your battles and lead by example in the coming months my thoughts will be more than just words on a blog. Project Facilitation will be a concept that I'll be blogging about more frequently as well as things related to software creation and my soon-to-be-released flagship product.
I'm one of those people that most likely would have been diagnosed with ADD had it been as big an issue when I was a kid as it is now. I start projects, get to a certain point and then lose interest as another project pops up to take its place.