I’m sure if we all sat down and thought about it for 30 minutes we could come up with a list of a hundred or more causes of project failure. But I’m also fairly sure that if we thought about it a bit more we could fit all 100 of those into one or more of the listed items above. My experience has taught me that project trouble almost always comes from two main sources – personnel issues and poor choices by management or a combination of the two.

Everybody knows when a project is going south – most won’t admit to it, except by jumping ship or by pollinating poison through negative talk and gossip.

Once you know that the project is in trouble you need to act – next post

Over the years I’ve developed a process I use to accomplish a recovery. I didn’t invent this process all by myself it has bits and pieces from others who’ve gone before me, but it has been tailored over the years to provide a framework that is most effective for me. This project recovery process is what I introduced the folks within SoWY IT to and what I left behind for them to use to hopefully recover the WCIS project. Here is a picture that provides an overview of the process:

My meeting with SoWY Department of Health is a perfect excuse to discuss, once again, the process for project recovery. So I’ll be breaking it up into bite size chunks over the next month and posting about the specifics. Stay tuned!! Hopefully this refresher will be beneficial.

I’ve often thought that at times like these training in Project Management and especially niche areas like Agile have got to be attractive to companies that are forced to do more with less. I’ve also often made the argument that at times like these companies figure out what their minimum levels of staffing are.

What are your thoughts? What experiences are you having right now as a result of the faltering economy.

We certainly don’t have the number of users that Drupal does – hundreds of thousands – but we have a fair number and trying to get feedback and then incorporate that feedback is always a challenge. Drupal has solved it in a very forward thinking, web 2.0 manner by opening a twitter channel, utilizing Flickr and by using the notion of groups which in Drupal’s case is a simplified forum.

I like the way Drupal has involved the users and the methods they’ve chosen to do so and to organize the information they’ve gotten back. I’m anxious to see how Drupal changes their application in response to the feedback in order to determine the level of success.

I can’t tell you how many times I hear these very same complaints from clients and prospects alike.  On one hand this fact is a good thing since it keeps me employed and the root causes are almost always the same so it is familiar territory and I can fairly quickly identify the causes, define a solution and put together a plan to help my clients resolve these issues.

On the other hand, however, the fact that many organizations are experiencing the same project management problems is very frustrating to me.  If one does a search on Barnes and Noble’s website for books on Project Management one will be presented with 5,570 results.  My frustration comes from the fact that despite this wealth of literature on the subject, organizations and the people in them continue to suffer from the same project management malaise that has plagued the industry for the past 20+ years.  Why is this?

There are a number of reasons:

1)    Buying a book doesn’t solve your problems – if it did therapists would have been put out of business a long time ago, global warming would be a thing of the past and George Bush would have been impeached a long time ago.  By and large books talk about problems and pose solutions in the abstract.  It is very difficult, especially with subjects of a technical nature, to apply abstract solutions to specific problems and achieve meaningful results.  This is why consultants are in demand; we provide specific expertise for specific solutions to very specific problems – at least the good ones do.
2)    Even if a book has specific information or advice that applies to the reader’s specific situation the reader has to act on that information and usually not alone.  Troops must be rallied, information disseminated, plans created, measures put in place and then there must be execution.  Typically it is very difficult for one person to accomplish all of this after having read a book.  Again this is why consultants are beneficial – if an organization is spending money on an outside resource there is usually motivation to act on the fruits of that investment.
3)    In almost every instance it is nearly impossible for an insider to see the root causes of an organization’s project management issues.  This is the ‘forest for the trees’ scenario wherein someone in the middle of a forest has a hard time distinguishing one tree from another.  Yet again this is why consultants are so important.  We bring a fresh and objective perspective to the situation and we have, in most cases, no encumbrances which will cloud our vision.
4)    Finally, and this one really bugs me, most of the books that have been written on the subject of project management talk about process and checklists and methodologies.  Don’t misread me these are important topics but they are NOT what ultimately makes a project successful or unsuccessful.  At the end of the day no matter what kind of project you are faced with it is NOT the technology, the process or the tools that make it happen.  It’s the people.  This is where the problems start and stop and this is what the majority of the books on the subject of project management fail to address.

Let’s return now to my prospective client the telecom infrastructure company.  Their problem again is:

•    Projects are either grossly under or over estimated and no historical data is being collected and used for repeatability or future process improvement.
•    When planning future projects PMs have no consistent method for determining potential cross-project impacts.
•    Risks and issues are not being tracked and managed effectively and consistently.
•    PMs are fighting fires instead of proactively managing.

And as a result of all of this the PMs are stressed out, overworked and not enjoying their jobs.

So what’s the solution you ask?

My proposal to them has two parts one technical and one non-technical.  From a technical perspective, because of the size of the organization, the matrixed and distributed nature of the resources and the complexity of the projects, they need an Enterprise Project Management tool.  It just so happens that they already have Microsoft Project Server 2003 and all of its components in house, installed and paid for.  So it was an easy recommendation for them to use this tool.  Of course they need to ensure that it is installed and configured correctly, it needs to be customized for their specific environment and they need role-based training on the tool.  Good thing I’m an MS Project Server expert.

The second part of the proposal, the non-technical part, involves analyzing the way in which the staff does their jobs.  Not just their internal processes but their interactions with other departments and external resources.  Areas for improvement need to be identified and an improvement plan created.  Once that’s done the staff needs to be shown how to implement the plan, monitor results, adjust/correct the course and develop and foster an environment that supports continuous improvement.  Sounds easy but this is the hard part because it involves changing the way people approach their jobs and helping them learn to objectively evaluate themselves and each other without fear of judgment.

If more organizations would bring me or someone like me in to do this kind of work we really could revolutionize Project Management in the US and take back control of our projects.

Larry talks about how difficult it is to correct problems in MS Project once you have a schedule built and how the dependencies that drive project’s automated schedule updating can have ripple effects that are both unintended and nightmarish to find and correct.

Larry isn’t a novice. He’s been in the business for quite a while. His experiences aren’t unique. In almost every PM consulting engagement I do I find that PMs across the experience spectrum share Larry’s frustration with the tools used to manage projects. In almost every engagement I end up providing specialized and specific training on these tools – especially Microsoft Project and Microsoft Project Server – designed to show PMs how to better use the tools to do their jobs. My goal is always to remove roadblocks to success and make the PM’s job easier – this is what the tools were originally designed for after all.

Larry has inspired me to post some tips and tricks about MS Project which I will be doing over the next week or so. It coincides nicely with work I am doing for a current client where I am helping them implement MS Project Server 2K3 and providing basic PM and PM Tool training.