Failed Project Mangement Software initiatives

Replies to This Discussion

Permalink Reply by Rhonda Avlonitis on August 18, 2008 at 10:23am

Good Morning Jack,
I have been on many accounts where the company had adopted Primavera or MSP Server and it did not serve its intended purpose. I think the main reason is the ease of use. MSP has long been the standard for PM tracking/planning in many cases supporting teams did not have real-time input into the plan, once this was introduced the added "work" to accept work and update seemed to take a back seat to the actual project work. I found that I spent many hours trying to reconcille what was assigned and what was completed.
Not to say that these tools are not useful, they are. The company really must be alligned and prepared to accept the limitations and learning curve associated with such an implementation.

▶ Reply to This

Permalink Reply by Jim Ilievski on August 20, 2008 at 3:38am

Hi Rhonda,

90% of the time it is not the tool. Our company has recently managed an implementation of all of the 3 major players in this space Primavera, CA Clarity and HP PPM. I can tell you which is the best tool in specific areas based on theory as real life, however to answer your question specifically, the major issue is in business process or understanding the real need of the organisation and not the tool itself. An example is one organisation decided to stop using Primavera because they believed that it was causing the issues in the project management space. We have just completed a review of their capability and guess what ... taking the tool away has not fixed their problems, and neither will replacing it. Reality is approx 90% of the time (don’t quote me on that) it is not the tool.

Feel free to contact me if you would like to see a copy of some of our findings in relation to tool selection and integrating it into the business.

Jim

▶ Reply to This

Permalink Reply by Uday Sekar on August 24, 2008 at 9:19am

Jim,

We are also in the same pipe line process of assessing out which PM tool would suit our needs, but all products seem to have their own area of advantages. It would be highly beneficial if you could share your observations so that we can benefit from it also. My email id is catia.flower@gmail.com and certainly appreciate your findings.

Regards,

▶ Reply to This

Permalink Reply by Andrew Brett on November 6, 2008 at 2:43am

Hi Rhonda

I have just seen this article and your comments and, although I have to agree with Jim that in the majority of cases, it is not the tool that is causes project problems, your point about reconciling what was assigned and what was completed is a good one.

There are a range of tools that help to some extent with this - the Atlassian suite mentioned elsewhere is a good example - but they all rely on human intervention and reconciliation of data to give you some idea of whether your project is on track or spiralling out of control.

Recently however, I have come across a software product that can reliably, objectively and accurately track developer's activities against tasks, toolsets and projects. Over time it builds up a profile of your team's capability so you can confidently estimate future projects based on a detailed understanding of the abilities of your team and/or individuals. Furthermore, there is seamless integration with the standard PM tools such as MS Project, Primavera etc.

In order to avoid blatant advertising in this forum I will not name it here but of you are interested, please feel free to contact me and I'd be happy to discuss it further.

Andrew

▶ Reply to This

Permalink Reply by David Levine on August 19, 2008 at 9:56am

Jack,
I am a principal of a consulting group that establishes PMOs and does some PPM Tools implementation. Some of the challenges are common for all new projects - executive and organizational support. These tools always come with some level of organizational change that has to be managed, communicated and supported. You can't just install the tool and leave. The installation/go live might be successful but the long term value from the tool won't be realized. I have found that starting with basic functionality and building once you have good user adoption is critical. These tools also that the dynamic that much of the value is at a management level by the data (and additional work) comes from the front-line staff.

Thanks, David

▶ Reply to This

Permalink Reply by Josh Vitello on August 25, 2008 at 1:19pm

Hi David,

You touched on a key point, from my experience in sales of PPM solutions (www.daptiv.com), and that is taking a crawl-walk-run approach with whatever solution you go with. My most successful clients are often organizations that had robust functionality requirements (long term), but kept things simple, simple, simple in order to get the first big wins (visibility and adoption). Then, we worked with them to the additional layers of their processes into the system, as appropriate.

▶ Reply to This

Permalink Reply by PAUL LEVINE on August 19, 2008 at 10:33am

Jack,

Check out www.qtask.com. It is a revolutionary low cost project management collaboration SaaS tool. The service provides on-line document collaboration,eliminates the need for email by wrapping discussion threads around tasks,calendars, projects, wikis etc. The ability to post Wikis, files (any file type) forms, manage both a global and project calendar, syndication of links,and compliance questions to manage projects and tasks. Access to this service can be acquired from any web connection including a PDA or cell phone. I am offering a 1 year free trial for up to 5 users for members of this LinkedIn group. My contact info is paul.levine@qtask.com 781-784-6001 I would be happy to arrange a demo of this Saas tool.

Regards,

Paul

▶ Reply to This

Permalink Reply by Alessandro Miodini on August 19, 2008 at 10:36am

Hi Jack,
I am working in the SharePoint/EPM (formerly MS Project Server) area.
In my opinion the biggest misinterpretation people do with this product is to consider it a planning tool. It is not. It is very good as a tracking tool, provided a certain amount of change in the organization and way of working of the companies that adopt it.
As any tool, it helps professionals, but has an overhead of installation, configuration and learning curve that has to be considered before adopting it. More than one company I have worked with just thought that installation and basic configuration were enough... wrong.

Alex

▶ Reply to This

Permalink Reply by Mark R Friedman on August 24, 2008 at 11:19am

Hi Alex,

Aside from the fact that most projects fail, I think your observation that PM tools are primarily used to track the project plan.

There are many reasons why senior management will be unhappy with the results, among them are:

Acceptance of unrealistic deadlines for the project by the PM who isn't managing scope.
Inadequate planning (insufficient detail in the WBS).
Insufficient or inaccurate reporting by the team members on their work.
Inadequate management of project risks.

No tool will correct those problems. I can manage a project with excel or a white board.

Given the right organizational structure and authority, I can manage a project more effectively and efficiently using any of the newer tools.

I admit a bias against MS Project. I believe it is a tool to be used by one person for a single project. It's not effective as an enterprise PM tool.

With regard to software development, I haven't seen a tool that manages XP, JAD or Agile development methodologies -- they all seem to be based upon the waterfall model and will have to lead to inaccurate planning results.

Of course, your mileage may vary.

▶ Reply to This

Permalink Reply by Jelle Koning on August 19, 2008 at 10:53am

Hello Jack,

I am software supplier for a special kind of PM software, so my opinion might not be that objective. In my opinion a lot of the tools you mentioned are not only complex as mentioned by Rhonda but mainly used "stand alone" and therefor difficult to maintain actual, especialy in (multi) project environments where people normaly are not very fond of adminstrative tasks. Especially not when these tasks are allready done by others. Interfaces must be build then. The tools themselves are all great tools with their own (dis) advantages.

A previous "hype" in PM software was offcourse the introduction of Professional Services Automation (PSA) where projectmanagement tools tried to be the next ERP wave and cover all the functions needed in a company. Companies like NIKU and AUGEO tried this road, as many more.

Nowadays best of breed is commonly accepted, and now techniques based on SaaS (and SOA) should make it possible more easily to integrate. When integrating with ERP like tools it kills sometimes the flexibility needed by the projectmanager.

As fot complexity, scheduling algorithms are beautifull. But some PM products are so good at it that a lot of users are affraid to use it. For multi project multi resource environment working with skills it is too complex to handle by a person. Standard features as critical path (or chain when looking at goldratt) and some earliest start or finished calculation is offcourse allways welcome and does not have to be that complex.

In a lot of companies I have visited in the previous years a lot of MS Project, primavera and powerproject (and several others) were used mainly for setting up a plan to communicate, not to keep track. But then I work in Project manufacturing environments.

Hope this contributes to your search

Regards
Jelle

▶ Reply to This

Permalink Reply by Andreas Wolf on August 19, 2008 at 11:58am

Jack -

I am currently heavily involved with a team trying to clean up an implementation of Expedition/Contract Manager from Primavera Systems. It has the classic fingerprints of good intentions gone completely haywire due to a lack of understanding.

The implementation was to be done at the Enterprise level. The roll-out was done under the assumption that the tool could be customized to match then-existing forms and naming conventions, and the tool was rolled out with only a few modules active, reflecting a plan to at some point, maybe, move into the other modules. Why was this plan bad?

For several reasons. Part of the advantage of this tool over stand-alone tools doing similar functions is that data is tied together and reused, eliminating or reducing non-value added work. For example, the act of entering data about a drawing automatically updates the drawing log, and makes the updated drawing information available to be linked to RFIs, contract document sets, etc. When you roll out only a few modules, you lose much of this advantage.

The failure to turn on all modules then led to the need to add some tidbits of data from the unused modules within the modules that were turned on. That meant creating custom fields to track redundant data. The customization of data, such as status labels, report formats, form field names, etc. created several problems.

First, while some of these changes should have little impact, they turned out to have big performance impacts. The use of brute-force methods (cross-linked tables, data lookups, etc.) rather than more elegant options also available to reach the same result, meant that, at an enterprise level with hundreds of users and countless software calls to these routines, the server got bogged down and performance suffered for all users. Some of the customization turned out not to make any sense when new modules were reviewed to be turned on, meaning that the customization had to be undone or further complicated.

In the end, we were forced to go back to a more "out of the box" implementation for the tool. The tool, as purchased, works for the majority of cases with no more customization required than logos on reports. Properly constructed reports can and will augment the basic functionality. All modules will be made available to users to maximize benefit, along with training and user guides for all modules.

One of the issues related to the implementation had nothing to do with the tool itself. Executive management approved the purchase and implementation of the product as an enterprise tool. The user community was given training and documentation for the truncated deployment of the tool. however, MIDDLE MANAGERS WERE NEVER GIVEN ANYTHING. That meant that the use of the tool to monitor team performance was never made clear or supported to the mid-level managers. Thus, the mid-level managers saw no direct or personal benefit from the use of the tool. Therefore, they did not mandate the use of the tool, did not know if it was being used correctly or not, and they did not support the use of the enterprise tool. This led to lots of problems for the actal use of the tool.

One cannot roll out an enterprise tool without effective support from the executive suite to the end user and all points in between. Failure to have this support leads to failure of the implementation, for many reasons, none of them having any relation to the actual tool being implemented.

A harsh lesson, but one repeated often. In this case, we will be able to salvage the implementation, but not without additional cost, frustration, and political expense within the organization.

Good luck.

▶ Reply to This

Permalink Reply by Alan Kitty on August 19, 2008 at 1:06pm

Rhonda's observations are on the money. Alignment from both the top down and bottom up is cruicial. A lack of a phased approach to implementation, and poor understanding of the skillset of end-to-end project leads and subleads can contribute to failure. Implementation in a siloed environment will also require a fair amount of facilitation may be necessary to reduce resistance to changes that MPS implementation may imply.

▶ Reply to This

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page