For this week’s column, we’re featuring a scenario submitted by an IT manager in the midst of an e-mail administration crisis. Read her story and let us know how you would resolve her situation. After reading the new scenario, find out how members responded to our previous column, which asked for a cure for project failure.

Rachel’s story
“Six years ago, we replaced our infrequently used freeware e-mail system with Exchange server running on NT. At the time of installation, none of us had any idea just how dependent on e-mail we would all become. Within a few months, the information store grew to 3 GB. Alarmed at this rate of growth, we requested a meeting with the original e-mail upgrade team to discuss imposing limits on the amount of mail any one individual could store on the server.

“The team consisted of me, the tech with the responsibility for the daily maintenance of the server, my immediate supervisor (who is the CFO), and his boss (who is the CEO). The meeting was completely unproductive. Despite our attempts to explain the eventual outcome of allowing unlimited use of the server to store e-mail, both the CFO and the CEO categorically refused to endorse the imposition of limits.

“To exacerbate the situation, the CEO had just launched a very vocal campaign encouraging all employees to take full advantage of our Internet access for personal use during lunch, after work, and on weekends. We could not even begin to imagine the vast quantity of spam this uncensored Internet usage would generate.

“Over the last six years, however, various changes in our favor have occurred:

  • Personal use of the Internet is no longer encouraged.
  • We use Websense to restrict Internet access and eSafe Gateway to filter incoming e-mail.
  • We have a policy banning storing personal files (including e-mail) on any company-owned media.
  • The employee handbook states that all e-mail is company property, and there is no expectation of privacy.

“All of these factors have helped us limit the growth of e-mail without the imposition of actual limits on the size of mailboxes. In addition, we have adopted the following practices:

  • Any user who is not on a notebook and who does not share any e-mail folder has delivery set to a personal storage (PST) file.
  • We routinely review mailboxes and search for personal mail. We do not read the mail but simply look out for user-created folders with names like “Jokes,” “Mom,” etc. If we find such a folder, we ask the user to remove it. If it is not removed within a reasonable length of time, we remove it ourselves.
  • Automated defrag utilities run on the information store every lunchtime, evening, and in the early hours of the morning after the backup has completed. This does not reduce the size of the information store, but it does create space within it.
  • We disabled the hard deleted e-mail recovery option so that once mail is deleted from Deleted Items, it is completely erased from the server.
  • Once a month, we take e-mail offline to compress the information store.

“Despite these efforts, we are rapidly approaching a crisis. Our information store is now 11.6 GB, and only 3.4 GB more will cause the server to shut down. Should a shutdown occur, our only option will be to run the eseutil utility with the compression option turned on and hope that it reduces the information store sufficiently to bring it back online, allowing us to start deleting messages.

“Once again, we have requested meetings with the CEO and CFO to discuss the imposition of limits or an upgrade to Exchange 2000, but our meeting requests have been denied. The CFO’s and the CEO’s mail alone is responsible for over 2 GB of the information store, so imposing any limits would cause them a great deal of inconvenience. In addition, the company is struggling financially, making it difficult to get approval for any unnecessary spending. We estimate that in less than three months, the information store will reach 16 GB and simply cease to work. Despite all our well-documented efforts to avert this crisis, our jobs will still be on the line.”

If you have any experience dealing with similar situations, or any suggestions for how this impending crisis can be avoided, please let us know.

What would you do?

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.

In search of the cure for project failure
In our previous “What would you do?” column, “In search of the cure for project failure,” you read about a project manager on an urgent quest to find the solution to the recurrent project failure syndrome endemic to the IT industry. The project manager provided us with the details of one example to consider, but bemoaned the fact that such failures seem “to be an industry standard” to which he is “still trying to find a cure.” We are happy to report that several Tech Republic members rose to the occasion by offering our distressed project manager some guidance to aid in his quest.

Tech Republic member info presented a very comprehensive solution focusing on three major factors:

  • Risk management: Identify the “risks/causes/mitigation/warnings/criteria” as an integral part of the project plan.
  • Quality management: Producing a quality product requires applying the PDCA (plan, do, check, act) cycle.
  • Strategic alignment: Check the alignment of the project with the business strategy.

For more information on this detailed solution, follow this link to info’s discussion thread.

Member maurice_liddell augments info’s strategy with the following suggestions:

  • “For this large of an initiative, an IT steering committee should be established.”
  • Conduct a business requirements analysis to “identify and prioritize the processes as to how critical they are in supporting business objectives.”
  • Improve communication. For example, “once it was identified that you would need three apps instead of one, the risk analysis should have been updated, along with the business case, and it should have been reviewed with the IT steering committee.”
  • Plan for any required training to meet “the long-term support requirements.”

Member wvanexe also noted the importance of providing adequate training or ensuring that a sufficient number of staff already possesses the requisite knowledge, especially when a new technology is to be implemented. “Having only one or two people up to speed on newer technology is a sure point of failure….My feeling on newer bleeding-edge technology is that until it becomes a tried-and-true method, I would not consider it unless I had a majority in my team who were familiar with it.”