In this week’s column, a TechRepublic member is trying to find a cure for the pattern that causes projects to fail time and time again. In her quest for the holy grail of successful project management, this Tech Republic member has provided us with the following scenario to consider. All background information and details that might identify the company or the particular project have been removed because, at the time of writing, the situation was still unresolved.

“My IT team spent some months and a large commitment in time and consulting fees to create an ’Enterprise Plan.’ The plan stated that we should:

  • Consolidate application functions across the enterprise.
  • Attempt to create a common consolidated data store for all enterprise-wide data.
  • Consolidate servers.
  • Follow an enterprise-architected approach and technology stack.

Central to the success of this plan was the replacement of a core application. This application had to be replaced because:

  • It was a custom application.
  • It could operate only on an unsupported OS and platform.
  • Only two people in the company had any knowledge of the application, and one of them was retiring while the other had recently accepted a position with another company.
  • The user interface was outdated in feel and functionality.

A project team was formed with the express purpose of replacing this mission-critical application and its associated interfaces, which were currently comprised of a series of download FTP processes. To date, the project team has achieved the following:

  • Completed documentation of the existing business process
  • Searched for replacement off-the-shelf products
  • Selected three off-the-shelf products and developed one custom in-house application (because no single product to perform the all the functions of the original application could be identified)
  • Hired outside consultants to customize the three applications, write the interfaces, and implement security for the resulting application

The team decided to author the application in XML, so the team member with the most XML exposure was sent out for intensive training. Unfortunately, before his newly acquired knowledge could be put to use, this employee left the company, severely delaying the project. The choice of XML was suspect in the first place because not only is it relatively new, throwing us into the realm of ‘bleeding edge’ technology, but its prime advantage as an agreed upon standard between organizations is not even an identified business need.

In short, we ended up replacing our legacy, unsupported custom application with a system that:

  • Requires more servers than the original application.
  • Uses a bleeding edge technology of which we have little in-house knowledge and no experience.
  • Requires more interfaces.
  • Is still awaiting the latest releases of software for all the interfaces to work.
  • Requires that all applications created ‘downstream’ from the application be heavily customized by outside consultants.
  • Requires more complex time-consuming administration.

We are violating every one of the guiding principals of the Enterprise Plan in creating this application. One set of managers who ’saw the writing on the wall‘ has already left for other opportunities. Heroic efforts will be made, some further compromise of ideals will occur, security will suffer a bit, and the project will be hailed a grand success, even through it will never be able to hit the target of supporting a business function since no target was ever identified.

Unfortunately, this particular project is not an isolated incident; it’s only my most current example. In my career, I have been a ‘troubleshooter’ on many projects that were started off incorrectly and had to be saved. Failure to analyze the business need seems to be an industry standard. But if you don’t know where you are going, you can’t get there—even by accident.

If you have any experience or ideas for how this pattern of misdirection can be avoided, or more easily identified and fixed once it has occurred, please share what you know.”

We want to hear what you have to say!

You can submit your ideas either by e-mail or by posting a discussion item at the end of this column. A week after the publication of a scenario, we’ll pull together the most interesting solutions and common themes from the discussion. We will later present them with the situation’s actual outcome in a follow-up article. You may continue to add discussion items after the week has elapsed, but to be eligible for inclusion in the follow-up article, your suggestions must be received within a week of the scenario’s publication.

Betray an employee or put the company at legal risk?
In an earlier column, TechRepublic presented a scenario in which a manager was informed of a possible incident of sexual harassment but was asked not to report it—yet. We asked you to review the scenario and advise the manager as to his best course of action. Here are some of your suggestions:

  • Report the incident to the “victim’s” manager against her wishes.
  • Document the conversation, make a point of observing the alleged offender, but do nothing more unless asked.
  • Have the victim document the incident in case it happens again.
  • Report the incident to HR regardless of the victim’s wishes. Her only inclusion in the decision should be whether she would prefer the report to be anonymous.
  • Approach the alleged offender and make him aware of what he has done—not everyone realizes that such actions are perceived as threatening.

Everyone agreed that, at minimum, the incident should be documented by the manager to offset the possibility of a recurrence in the future. But many disagreed about how to handle the victim’s desire to not have the incident reported. Some felt that her wishes should be respected, while others felt that the individual’s wishes should be subservient to what is best for the company as a whole, not to mention other future victims.

What did the manager actually do? He agreed with the majority of respondents and reported the incident to HR, along with the information that the victim did not want the incident to be reported, or acted on, at this time. He also informed the victim that, in his position as a manager, he was required to take this course of action.