Messaging Architects

The customer had previously purchased Messaging Architects’ M+Archive product because experience from a recent lawsuit had proved they needed a reliable way to preserve, manage and search email. However, the customer had been unable to implement the product due to a lack of a policy on email retention and destruction.

Earlier internal discussions on how to draft a policy had made little progress, and the IT department worried that nothing was in progress to make a policy come into existence. The IT department knew that it possessed no authority to impose a policy on their own. They needed a breakthrough.

The IT department scheduled Messaging Architect’s ePolicy workshop which I have been leading for over 2 years. When the workshop was announced, the IT department was able to ensure the participation of the key stakeholders: Legal and HR.

Compared to other workshops, this one was intimate, involving only a lawyer, an HR representative and two IT representatives. From the start, I engaged with the customer’s lawyer in a professional dialog about what the big issues are and what I have seen other organizations do. This led into a spirited, freeform discussion among all participants about the many places where copies of emails can reside, the challenges involved in confirming that all copies of any given email are ever destroyed, and the numerous new message types that people are using in business, including text messages and social networking.

Eventually, the customer’s lawyer admitted our discussion had changed his thinking. Electronic records behave differently from what he thought. This change of position became the foundation upon which the workshop eventually drafted a policy.

Two participants in the workshop said they wanted to hear about case examples from other enterprises and to examine the policy template I had brought. They debated which kinds of records needed to be kept for longer and which for shorter periods. They knew from experience certain records need very long retention periods.

As the day progressed, common ground began to emerge of which I kept track on a flip chart. By the end of the day, the group seemed to have direction. Using the agreed points from the flip chart, I drafted a sample policy for their review the next morning.

On day two of the workshop, the participants asked the Messaging Architects' systems engineer technical questions on how specific policy objectives could be met with M+Archive, which they already owned. Then the group reviewed the draft policy, followed by more discussion and changes.

Something surfaced in this workshop that had not surfaced before: a thorough conversation about documents on the customer’s document management system. The group decided the retention policy should be expanded to cover managed documents in addition to email.

The group believed it had reached consensus on policy. I made the changes to the draft and provided the revised policy to the customer’s lawyer. At the group's request, I also devoted some time discussing two optional sections from the ePolicy curriculum on how to implement legal holds and promote attorney confidentiality and on data security law.

As the workshop concluded, the participants expressed great satisfaction with the process and the outcome.

As part of a recent client interaction and whiteboarding session, I was asked to express my views about the benefits that Unified Messaging might deliver in terms of enhanced collaboration. In my reply, I acknowledged that we are well into the era of Unified Messaging (UM) as close to 1/3 of enterprises are in the process of deploying infrastructure to unite telephone and email systems. This trend started off as a way to lower operational costs and deploy IP telephony, but has now grown far beyond its original scope. The future of Unified Messaging will enable an entirely new class of rich and interactive collaboration as well as much smarter infrastructure management. High definition video is certainly only a few steps behind voice as the next logical media-stream we will add to our networks.

One of the changes we will soon see to workgroup collaboration is what we call “Asymmetrical Messaging” whereby a voicemail may be replied to with an email (and vice-versa), or a message instantly converted to text by speech recognition agents. This text could then be automatically appended to a client’s record for future reference. These new types of interactions will dramatically enhance our collaboration experiences since voice is a much richer communication medium than plain text.

Research (and human experience) clearly demonstrates that it is far easier for us to detect emotions and intent from listening than from reading. However, it is usually much easier and faster to scan through a long text (speed-read) to get a feel for a situation. Trying to “speed-listen” to a lengthy recorded conversation would not be effective and might give most users bad headaches. UM will enable us to choose the media best suited for the task at hand.

The integration of calendaring and voice systems will also enable us to conduct more effective meetings – by simply inviting a conference bridge to a meeting, we can have the bridge agent record the entire meeting and automatically send a link of the conversation to all attendees. Smart voice tags can be used to identify action items, tasks and due dates, and automatically update our calendars or project plans.

The ability to consult our calendars and interactively book meetings while on a phone call will soon be as simple as conferencing in our calendar agent who will be able to reply to spoken commands such as “When am I free next week?” The same will go for address book lookups – “Call John Smith on his mobile” and smart reminders – “SMS me at 4 PM to remind me of my dentist appointment.” All these interactions will be logged in our collaboration systems for consultation and review. It will soon be easy for a user to request a unified composite view of the communications he has had in the last 60 days with an individual, whether via phone, email or other social networks.

Another exciting possibility is Intelligent Attachments & Smart Delivery. Intelligent Attachments are documents that a user can have emailed out by simply requesting them from the phone server. Smart Delivery is the ability to request that an email message be forwarded as a synthetic voice message, or request that a voice message be forwarded to an email account, in effect choosing the way a user wishes to interact with the content.

These applications and more we have not yet imagined will augment our capacity to deal with complex projects, shifting schedules and distributed virtual teams. Our productivity will be enhanced and soon we will not be able to remember how we functioned without these applications at our command. However, they will also need to be well designed against abuse and hacks so that users feel confident using them. The management capabilities will need to be fully integrated with existing directory services and identity management platforms for fast provisioning and de-provisioning. Of course these new capabilities will require copious amounts of additional processing and storage, but this will be a small price to pay for the enhanced collaboration and productivity they will enable.

A few days ago, I posted an article in our blog that was written by the CEO of Messaging Architects, Pierre Chamberland, on how CFOs and CIOs can help to minimize the risks associated with major IT projects by understanding the importance of project management. Entitled The 10.5 Essential Steps of Successful IT Projects, the article created a lot of buzz around the water cooler and led one of our Account Managers to forward me the following article as a potential companion piece to Pierre’s earlier submission. The article, entitled Successful IT Projects: Getting What You Want, includes a few more steps to help you make the most of your IT budget. It is reprinted below with permission from the author, James Flowers.

Media reports are awash with stories of information technology systems and infrastructure projects gone wrong and cost overruns. This creates an impression that significant IT projects are 'risky', particularly in tough economic times where the emphasis is for IT departments to make the most of their information technology budgets.    

Whilst the success of an IT project can never be 'guaranteed', particularly if it is a complex project, the risks of failure can be greatly reduced, and acquirer's ability to mitigate the consequences of failure greatly enhanced, if that acquirer has satisfied each of the following steps:

1. Scoping the project before approaching the market

If an organisation does not have a clear sense of the outcomes it requires (functionally and otherwise), then inevitably it places greater reliance on the supplier to provide or deliver those outcomes. In such a case, it should never be assumed that the supplier's interests and objectives will be aligned with those of your organisation. A supplier will seek to supply a solution that meets its understanding of the requirements but also maximises the returns to it.

Further, if the customer is relying on the supplier's expertise not only to supply the solution/system, but also to determine what the solution or system should be, it becomes harder for the customer to manage project scope and costs.

The customer should therefore take time to determine what it requires, what is available, and whether the available solution(s) and systems are compatible with its requirements. If your organisation does not have that expertise internally, it could engage a consultant to assist with this process, or undertake a 'request for information' process – a precursor to a request for tender or proposal in which the customer seeks information about possible solutions or systems from the market.

2. Due diligence of suppliers – will the supplier see it through?

Whilst price and technical compliance are clearly important elements in evaluating a proposal or offer from a supplier, the history of IT projects is littered with examples of suppliers offering outstanding solutions or pricing that are too good to be true. The result is that such suppliers are not able to deliver on the solution, either because their proposals are not matched by their capabilities, or they lack financial substance.

Customers need to insist that prospective suppliers demonstrate both technical capability – regarding expertise and depth of resources – and solvency. To the extent that there is doubt on either front, customers should either steer clear of the suppliers, or require that those suppliers produce financial and/or performance guarantees. However customers must then ensure that the guarantor(s) has the capability and solvency that the supplier may lack.

3. Avoiding standard supplier contracts

Increasingly, many suppliers – particularly the large suppliers – are insisting that they will supply goods and/or services only subject to their standard supplier contracts. This may occur even where the supplier is responding to a request for tender.

Not surprisingly, standard supply contracts contain terms that are geared to maximise the supplier's position, usually at the cost of legitimate protections and rights for the customer. However, more fundamentally, if a customer accepts a standard supplier contract, it also accepts that its project will proceed in a manner that is largely mandated by the supplier, and is subject to the supplier's processes.

That may not be what the customer requires. For example, it may wish to ensure that the project is subject to its own project management and governance processes, and it may want to tie payment of fees to receipt of actual outcomes and benefits.

Therefore, at best, customers should challenge the notion that it must engage the supplier under the supplier's own terms. Naturally, if customers want to avoid supplier terms, they will need to develop their own template agreements.

4. Incorporating appropriate governance, reporting and oversight processes

A common feature in projects that 'come off the rails' is that problems or delays identified by one of the parties are not raised with the other party, then discussed and actioned in a forum that enables quick and effective decisions to be made about how to address that problem or delay(s). In many projects – particularly more complex projects – the prospect of unforseen matters and delays is relatively high.

However in the absence of an effective reporting, oversight and governance process, there is a real possibility that one party – usually the customer – will be kept in the dark about the existence of problems and delays, and may only find out about them at a point where the project is delayed, or where the costs have gone well beyond budget.

Appropriate governance will not of itself ensure that projects proceed smoothly, but transparency and effective communication will enable both parties to be more proactive as to how they address problems and delays. IT project contracts should therefore incorporate measures such as mandatory periodic meetings of project principals, and periodic reporting of progress and issues (which also tracks action taken on past issues raised). In projects of strategic importance to the customer, measures such as a governance committee, comprised not just of project principals but also other stakeholders of the party, would be worthwhile.

5. Tying payment to achievement of required outcomes and timeframes

For an organisation that has embarked on a business-critical or expensive IT project, there may be two nightmare scenarios.

It could be that the organisation is either contractually bound to continue paying the supplier for the work it is undertaking (even though the supplier is not delivering the contracted outcomes), or that the organisation has paid the supplier all of the fees and charges due only to discover that the supplier has not yet completed the project. Aside from the fact that the project is not delivered, an organisation in that position has largely ceded all of its commercial leverage: it either has to persevere with its supplier (at additional cost), or cut its losses and potentially have to start again.

From the customer's perspective, the preferable arrangement for payment of fees is that payment of particular amounts is tied to the supplier's achievement of milestones and/or delivery of required outcomes. This is not to say that the supplier should not receive any payment until the project is completed, but that the project should be divided into milestones, with instalments of the overall amount payable then tied to the supplier's achievement of those milestones. The amount received should depend on the relative importance of each milestone.

Nevertheless, the best form of arrangement is one where the bulk of the overall amount payable (at least 50% to 60%) is paid when the project is completed. Instalment payment arrangements do not provide the supplier with much incentive to complete if it has already received 90% of its payment.

6. Proactive contract enforcement

A well-drafted contract will give the customer a range of rights and remedies to address the supplier's failure to comply with that contract. If a customer feels that its proposed contract does not offer it the kind or range of rights or remedies that it would expect, then it should not sign it.

Assuming that the customer has all the contractual 'tools' at its disposal, the question will be which one of those rights it should use in particular cases. Regrettably, many customers feel that exercising any rights given to them to enforce their contract will in some way be a precursor to ending that contract, and so they do nothing. Once again, such an approach cedes commercial leverage to the supplier.

Issuing a notice of default, disputing an invoice and invoking requirements for a party to provide a guarantee are appropriate and usual actions for a customer to take (assuming that it has a right to do so). Customers should not feel that taking such action is a sign of failure. Rather, it should be seen as a proactive attempt by the customer to rectify problems, and a reminder to the supplier that legal obligations must be satisfied, or it will face consequences in the form of financial compensation or other remedies.

If your organisation is contemplating an IT project, it will be the one that has to live with the outcome of that project. It should therefore not be shy about requiring a contract and contracting process that ensures that the outcome aligns with its objectives.

Where is Greg Smith? This has been the leitmotif of several emails I received ever since we changed the format of our presence at Novell BrainShare this year by having one giant Brewfest meet-and-greet. It doesn't mean that Greg's not around…

Truth be told, Greg has been busy. With what, you ask? Here's a list of some of the things he's been involved this year: Greg has supervised tons of email archiving deployments, done half a dozen or so GroupWise audits, and assisted a few organizations in their legal discovery quests. At present, he's preparing to speak at the SANS Institute e-Records Summit on "Finding Email Records in the Real World." Not to mention the tidbits of advice on email retention and compliance he has been giving us internally - so we are really knowledgeable in our interactions with clients.

So, you see, Greg has really been awfully busy. However, after a lot of nagging supported by your adoring emails, we did manage to get him to agree to make a live Webex appearance this coming week.

On July 28, Greg will talk about email storage optimization and some of the innovative options you have to tackle this pesky issue. He will share real-life stories from the trenches, the problems our clients face with dealing with storage bloat and why he recommends M+SecureStore to solve them. It's a must-attend event, so reserve your spot now.

Greg Smith is here and now's the time have him advise you on your challenges.

Messaging Architects has held its ePolicy workshop in numerous, diverse organizations throughout 2009 and 2010.  One such organization was a sizable state government agency, which had approximately 5000 email users. One year prior, the agency had purchased Messaging Architects' M+Archive product, but it had not implemented it beyond the pilot stage because the agency had not settled on an email retention policy. Although stakeholders within the agency had discussed policy, they had not reached consensus.

With a view to breaking the logjam, the agency’s CIO invited Messaging Architects to bring its ePolicy workshop to the agency. Believing that she had not been able to get sufficient attention from the Legal Department, the CIO hoped that the workshop – led by an outside lawyer – would motivate more engagement by Legal.

Although the workshop is normally scheduled for two days, the CIO preferred to hold the workshop over only one day. Her objective was not really to have a policy drafted by the end of the workshop.  Instead, it was to break the logjam, get the stakeholders to work together, and to propel them toward final drafting of a policy.

Participants in the workshop expressed some strong, contradictory opinions. One opinion emphasized that each employee should (consistent with statewide guidelines) have responsibility to review each email, delete those that are not official records, and file the others into specified categories. Another opinion stressed that employees do not have the time and will not take the time to review emails in this way; this opinion argued for generous retention of email in an archive system, where it can be found through searching rather than through categorization.

Messaging Architects was represented in the workshop by attorney Benjamin Wright and system engineer Michael Dybala. Their primary role was to facilitate an orderly, informed discussion on e-records law, experiences in other enterprises, and the technical functions of M+Archive.

Agency stakeholders participating in the workshop included representatives from IT, Legal, Operations and Records Management.

After spirited debate, compromises emerged. The group agreed on an outline for drafting policy. At the end of the day, the workshop closed with a commitment between the IT department and the Legal Department to work together to draft that policy in an expeditious fashion.

I was recently involved in a consultation session with a Client who was looking to consolidate his email infrastructure from a decentralized model with many servers and domains in 10+ countries, to a centralized model where all the servers would be located in a single country. The stakeholders wanted to understand what shifts this would cause to their regulatory obligations and how they should consider various deployment options in this context.

Here is a summary of our discussion:

There are no hard int'l rules that have been tested to my knowledge, at least not formally in court with regard to moving electronic records around. In fact there is 2 contexts to your query: i) moving the records around and then what is the optimum email storage structure to minimize risk, and ii) how does discovery and rules regarding official corporate records work across multiple geos.

Regarding point i:

What I have read about and also discussed with clients is the following 2 approaches:

[1] Consolidate all servers and content in new geo, and have this geo's rules & regulations apply to all content (historical and future). A smart twist on this is to set an Archive anchor point at the day of consolidation, and manage historical (now archived) content as per old policies set while server was in original geo, and all new content managed according to regulatory frameworks in new geo.

[2] Consolidate all servers & content but continue to manage content as if it was virtually still in geo of original creation. Under this scenario, content created in France (sent or received) would be stored in Canada but not discoverable under Canadian laws or regulations, only under French ones. Of course from a technical perspective, I would recommend encryption on the message store, with the encryption keys being kept in the geo where the data was originally created.

Depending on the Risk Management strategy of the company and the value of the data, an option to strongly consider would be to keep the smallest minimum timeframe of international email on production servers (max 90 days). Everything older would be moved to Archival storage. Search indexes (which are not the messages or attachments) can be stored in Canada since these are not the actual record and as such is not discoverable. The archived actual messages are stored in an Object Storage system (like M+Securestore) with an off-site instant mirror.

So in essence there is a primary write of the message to a device here, and then an immediate replication to a device in the geo of origin, followed by the deletion of the original write. In this way it can be clearly demonstrated that the message was in fact never stored in Canada but simply "in transit" to its long-term storage location in the originating geo. If they wanted to also keep a copy of the message locally as a back-up of the remote location, this is both possible and OK. The local copy (Canada) is being made solely for disaster recovery, it cannot be discoverable - only the original record can be requested and it would sit outside of Canada.

Under civil law and copyright interpretation, the fact of where the digital content resides (stored as bits) can be disconnected from the regulatory obligations, or lack thereof attached to it. For example, if a contract is created, printed and signed in France, then an scanned copy is sent via email, and the email is stored in Canada - nothing about Canadian discovery regulation or laws will apply to this email or attachment.

Another example is e-commerce web sites that are hosted in other countries - the authorities of the hosting country does not have the right to interfere unless the complaint originates from a matter brought to a Canadian court, and then will likely only be allowed to request discovery for content created by Canadian workers.

Under criminal law, (think child porn) this construct does not apply and the country where the data is stored has full rights to exercise legal intervention on its soil and courts will not hesitate to provide the required search warrants or subpoenas.

Keep it Simple....

My advice is that simplicity dictates that a multi-national org should try to have a single retention/discovery policy that meets the baseline requirements of all geos, and then manage the occasional exceptions. If one thinks of a corporate Code of Ethics, there is usually only a single version.

Regarding point ii - it gets pretty messy, pretty fast:

Let us set the stage; a Canadian company, with a French wholly-owned subsidiary where email is considered private and requires a court order to discover, employing a German resident contractor working on a project for a Japanese client. The Japanese client decides to claim negligence on the part of the German contractor and sue the Canadian company in a Japanese court for damages and breach of contract.

Part of the lawsuit involves requesting access to encrypted email messages on the German Contractor's laptop that were circulated between the French and German, and that are believed to exist archived (in cleartext) on the corporate email servers in Canada.

What can be discovered? Who can decide who needs to produce what? How much will be spent in external legal fees? Experience to date shows that there is no cut & dried answer, there is no "good & perfect" response, only a bunch of "it depends" - and alot of the "it depends" has to do with the amount of money at stake.

So how can a company mitigate against these types of risks? There is really only 1 way - via a clear and well implemented Acceptable Use and Retention Policy that will ask exactly these types of questions and set the tone for the scope of involvement and technology deployment required to match this scope. Letting courts or lawyers decide about matters of internal policy is usually not a good choice. Being well prepared and having predetermined answers put the organization in a position to respond as needed, and in a matter that is consistent with its best interests and the ever-evolving legal & regulatory framework.

Best,

--Pierre 

The amount of data within your messaging environment is constantly expanding as email communication continues to increase, replacing other types of communication. More messages each day, and message sizes that balloon due to large and numerous attachments. According to Gartner, the average number of email messages per user, per day has increased to over 130 and the average message size is over 100 KB. Many users will try to preserve between 1 and 2 GB of email data per year. In large organizations, this adds up to alarming figures for which email servers were never really designed.

In many cases, the response from IT has been to deploy complex, costly and fragmented email infrastructures just to keep up with the storage bloat. To further combat this growth, many organizations have also enforced stringent deletion rules such as a 90-day retention policy. The behavioral impact resulting from these policies is often the premature deletion of potential business records or the use of personal archives to maintain data beyond the stated periods.

When personal archiving is used, it moves data off the organization’s production servers and storage to a system-defined location that may include the user’s local machine. The data is then no longer accessible from the corporate messaging system, resulting in idiosyncratic and highly-interpreted data retention, based on end users’ perceptions of what should be preserved. Trying to recover messages as part of an internal audit or litigation rapidly becomes a costly nightmare. All to often data simply cannot be found, or the organization runs the risk of losing critical information when PCs or laptops are refreshed.

In addition, personal archives are not storage efficient. Since they re-create copies of all attachments in each personal archive, data sizes are usually between double and triple of the original size. The increased data, combined with the inability to run centralized searches, adds stress to most discovery requests, which are typically on tight timeframes to begin with. Collecting, processing, reviewing, analyzing, and producing large sets of disparate personal archives for external parties becomes an expensive and error prone exercise in redundancy.

As part of most recent litigations, an organization’s policy definition as well as the consistency of enforcement of this policy is reviewed so as to identify alignment with legal requirements. When daily practices are found to be inconsistent with policies or compliance frameworks, or if relevant data is discovered on other storage locations, it rapidly opens the door to in-depth questioning of what the organization may be trying to hide, or if legal holds are being adequately respected. Attorneys are now well versed in eDiscovery and have very good understanding of the technology at play. Their objective will be to cast a doubt on the preservation practices and the completeness of the data set provided – which if successful, can make the difference between winning a fair settlement and losing a case on technical deficiencies.

This risk is compounded by the nature of the legal hold process itself. Was the hold applied when “reasonably anticipated” and were appropriate actions taken to preserve “all forms” of relevant information, which may include requests to include personal archives. Personal archives represent a subset of e-mail that either was selectively or automatically maintained but is not necessarily captured at the time a legal hold is initiated.

Since personal archives effectively remove data from the corporate messaging system it may well also create questions about the effectiveness of the organization’s legal hold process. If personal archives are part of the ediscovery scope, this data will need to be handled appropriately. This may be stating the obvious but in many cases the consequences and impact are not considered, and as a result fall well outside the organization’s acceptable level of risk tolerance. The trend in litigation indicates a broadening definition of what is a record and what is considered relevant and discoverable. As with backup tapes, which at one point were rarely requested as “in scope,” they are now routinely considered a standard request.

Notwithstanding the philosophical debate which has been ongoing at the academic level, legal hold for email means really preserving all data from the point when “reasonably anticipated.” Thus it should include personal archives if the organization allows for this functionality to exist. Under those assumptions, the email data may be considered potential evidence and even unwillful destruction could be considered spoliation.

1. Can you defend the effectiveness of your legal hold process?
2. If personal archives are requested, do you have a process to enable production?
3. For every “Send”, there is a “Receive,” What might opposing counsel have that you are not aware of?
4. Are you capable of determining if you should settle before having invested too much time.
5. Does your current setup provide the tools for effective legal strategy planning?

Click here to download a copy of Personal Email Archives: Do They Amount To IT Malpractice?

Major IT projects are risky for any organization. It is the CIO’s responsibility to minimize the risk by ensuring that projects are managed effectively. This begins with a process framework encompassing these 10.5 essential steps.

1.  Make feasibility evaluations obligatory. Too often haste to get approval and begin a project causes management to pay minimal attention to this step, leading to unexpected problems. A required project-feasibility assessment should be performed for all IT projects. Although it may slow the approval process, it will help avert project failure. This analysis should include a list of preliminary architecture and design specifications and a project-management plan proposal, which enumerates assumptions, required resources, constraints and timelines.

2.  Designate a Project Sponsor who will declare clear project objectives. A clearly-identified project sponsor (PS) should be responsible for the success and overall project implementation. The PS should be charged with monitoring progress constantly and resolving issues that can impede rapid progress. The PS is supported by an executive group or committee that can serve as a forum for problem solving and escalated issues.

3.  Appoint a full-time Project Manager (PM). One individual with experience with similar projects should oversee the day-to-day management, execution, and delivery of the project.

Before going ahead with the IT project, the proposed timeline, cost and scope should be clearly defined and accepted by all potential participants. Failure to ensure that all stakeholders are in agreement can lead to confusion, wasted effort, needless duplication, and ultimately project failure.

4.  Give the Project Team real authority. The team should include interdisciplinary senior staff with sufficient analytical, technical, and project-related expertise to guide the project to a successful completion. The team should have access to enterprise resources needed to ensure the project conforms to enterprise standards and should have sufficient authority to control the activities and resources necessary to complete deliverables within the set time frame.

5.  Create a detailed Project Plan. A comprehensive Project Plan should be developed as a guide to all major activities such as project deliverables, timeline, roles of team members, key risks, and approval processes. The document should incorporate all formal written agreements with external and internal suppliers, resource owners, and end-users regarding their roles in the project.

6.  Secure committed staff resources. The PM should obtain formal written commitments from department managers to allocate time for their staff to work on the project; similarly, commitments need to be obtained from all assigned staff. Managers need to plan ahead to free up designated staff and resources, while continuing to meet daily operational requirements.

7.  Establish performance measures and report progress daily. To assess project performance, a specific set of performance indicators should be identified. Performance should be tracked at the task level by team leads and summaries presented to the PM, who in turn, will report progress to the PS. Discrepancies between expectations and actual performance should be discussed so contingency plans can be made as soon as possible.

8.  Take corrective action sooner rather than later. Resolve any performance variances quickly and decisively. If the problem cannot be eliminated, such as changes to budget, schedule, and deliverables, steps should be taken to mitigate negative effects by reassigning team members to provide additional support in areas where it is needed.

9.  Implement formal change-control mechanisms. All changes should be documented and incorporated into the Project Plan so that everyone knows when and why a change was made. Such documentation should include the date the change was made and its effect on the plan. Major changes that raise costs, substantially delay completion or redefine major deliverables should require written approval from the Steering Committee.

10.  Proactively manage risk. IT projects typically involve a number of significant risks and controversial issues that can prevent the team from moving ahead. Consistent and pro-active communication among project participants, stakeholders and end-users is required to mitigate against such internal risks. The PM should have a formal escalation process if serious roadblocks are encountered.

And last but certainly not least…

10.5.  Celebrate success. Each project milestone should be celebrated and communicated organization-wide to foster team coherence and promote values that are intrinsic to high performance.

Click here to download the full version of The 10.5 Essential Steps for Successful IT Projects.

Listen to the podcast

This case study describes Messaging Architects' recent delivery of an ePolicy Workshop in the offices of an enterprise client. The client is a large, privately-owned construction company. Its employees are spread widely across many locations. Knowing that the company needed a policy on email records management, the IT department discovered that Messaging Architects offers policy development services. The client had not previously done business with Messaging Architects.

The client engaged Messaging Architects to conduct an in-house workshop, with Texas attorney Benjamin Wright as workshop leader. A few days before the workshop started, Mr. Wright spoke with the client by telephone so he could customize the ePolicy Workshop to meet the client’s unique needs.  

Mr. Wright came to the workshop with a prepared agenda, but quickly found that the event took a life of its own, according to the interests and needs of the people in attendance. For the first two hours, the client’s employees in attendance were only from IT. They interacted with Mr. Wright and Messaging Architects representative Osman Baig to understand the issues as they uniquely apply to their enterprise. They also wanted to learn what other organizations are doing on email record retention.  

The group then expanded to include the client’s general counsel, chief financial officer and other officers. The group considered litigation issues and the costs of retaining email. After lively debate, consensus began to emerge around some principles.

A core group of workshop participants then undertook to start drafting language. On the morning of day two of the workshop, an agreed draft policy emerged. The client’s CIO had what he needed. With this policy in hand, a select team, including the CIO and Mr. Wright, presented a briefing to the client’s chief executive officer.

Last week, I published the first part of my recent chat with Scott Kunau of the Innovative Global Technology Group (IGTG) on what sets their company apart and makes them such a hit with their clients. In the second part, Scott talks about his methodology to email archiving and migrations, some of the real-life challenges such projects involve, and why he recommends M+Archive to overcome them.

RD: In your experience what’s the primary reason for migrations away from GroupWise?
SK: Half the time, the GroupWise migrations we’ve seen happen have to do with some non-technical, purely political reason. In the other half of the cases, there are serious technical reasons having to do with replacing a messaging platform that doesn’t support a key company application easily.

Another major problem is the lack of Novell talent in the younger generation of IT technicians. They have little or no foundation in Novell technology and are usually unwilling to learn. We have an extremely talented young computer engineer on our team that we are mentoring in Novell technology. However, he is the exception to the rule, as the majority of younger IT technicians and engineers don't see the value in learning about Novell technology and that gives us an edge. In a way, this is one of the things that sets our company apart: our strong technology foundations make learning complex technology much easier for our clients. Plus, we're not biased about technology solutions.

But we make sure our clients are informed about a migration project they undertake. It is our job to ask the tough questions about cost, complexity, and overhead. We bring up all the things they need to consider before embarking on such a project. And we always make sure they fully understand the planning stage, which is more important than the implementation stage.

RD: Does this imply that planning takes a long time?
SK: It really depends on the internal policies of the organization. Some companies want extensive preparation and are ready to invest heavily in having engineers in-house to plan, document, and test the project management plan for weeks on end.

We offer a more efficient and cost effective solution. We set up a small fully virtualized pilot environment, work through the issues we encounter, do small test groups making sure that everything coexists together. When everybody is satisfied, we go ahead and schedule a specific date or period of time when the conversion takes place. In some cases, I believe we've saved our customers thousands of dollars with this approach.

RD: What can you say about your relationship with Messaging Architects?
SK: I think that we share are a lot of common values that make this a mutually beneficial partnership. We are both smaller and flexible organizations that offer solutions to make our clients successful, while also equipping them with the tools and knowledge to better manage their IT infrastructures.

We have had a lot of success implementing M+Archive at client sites, whether to address email archiving and eDiscovery needs or in cases of an email migration. M+Archive allows us to handle email migrations in such a way that only the necessary amount of data is migrated to the new email system, while the bulk remains in an archive repository that is fully accessible to the end users. The technology allows us to handle email migrations in a way that doesn't make it the "project from hell" but allows us to perform 90% of the work without impacting the end users. When all the prep work is done, we can switch them over to the new system quite painlessly.

Clients also appreciate the fact their investment in M+Archive continues to bring them value after they switch to Exchange. Recently, we helped a client upgrade to the latest version of M+Archive from the previous version which they were using on GroupWise. After they migrated to Exchange, we converted their GroupWise XML archive to and Exchange XML archive and they continued to use M+Archive on the new Exchange system.

I think there a lot of opportunities for Messaging Architects' technology and IGTG's expertise.

In March, I wrote about the advantages being a small company when it comes to providing superior service to our customers. Recently, I had the opportunity to catch Scott Kunau of the Innovative Global Technology Group (IGTG) between projects for an informative chat about the company, their clients' most pressing IT needs, and the partnership with Messaging Architects. One of the things that makes the partnership work so well is the fact that IGTG is a small, hands-on company with comprehensive expertise in Novell, Microsoft and Linux environments that follows a very simple philosophy: total commitment to client satisfaction by outstanding performance and professionalism. Here's the first part of what Scott had to say...

Founded in 2006, Innovative Global Technology Group (IGTG) helps organizations of all sizes and industries find the right technology solutions in networking, messaging, virtualization, and storage. The two founders, Scott Kunau and Sam Lohrer, who between themselves bring over 30 years of technology experience, joined forces following a clear and simple philosophy: total commitment to client satisfaction by outstanding performance and professionalism.

What makes IGTG unique is their straightforward, tangible, measurable solutions without the fluff, spin, or unnecessary steps sometimes employed by other consulting firms. Their only concern is making sure the solution they offer a client is customized to their needs, exceeding only their expectations, not their budget or the time needed to complete the project. They also empower clients with knowledge transfer to help their IT staff troubleshoot various issues with ease.

What sets IGTG apart from other systems integrators and technology consultants is their extensive skills and hands-on expertise in Novell, Microsoft and Linux environments.

RD: What's your approach working with clients?
SK: One of the things that differentiates us is the fact that we work with clients in a comprehensive way: in addition to the software implementation, we help them with the planning stage, provide training following the deployment, and suggest best practices on managing the solution. We are also able to adapt depending on organizations' budgets, infrastructures, and deployment schedules.

RD: That’s a bit different from the typical approach of professional services, isn’t it?
SK: You’re absolutely right. Many IT consulting firms go into a company, do the project on a schedule they define and leave, perhaps providing documentation, perhaps not. When we work with a client, we insist on providing knowledge transfer and training during and after the deployment as part of the total solution we offer. We want our clients to be as self-reliant as possible while knowing that we are right behind them if they need us.

RD: I agree with you there - one of the strongest complaints we get from clients is the lack of knowledge transfer from consultants. In your case, it's actually part of your professional services engagement...
SK: Here’s an example with a recent email migration from GroupWise to Exchange that we did using M+Archive. The entire new email environment was set up by their IT department in-house. I didn’t physically run any of the installations, but I explained each stage of the project and discussed possible problems they could run into. The internal IT staff was implementing the steps. The result was, they came out of the migration knowing exactly what they had and how to manage it. This way, they are able to do future upgrades themselves and deal with potential troubleshooting. It's also a more cost effective way of using our services.

RD: You mentioned your clients highly value your flexibility. Can you elaborate on that?
SK: A big consulting company comes in, dictates the implementation schedule and then they walk away. Often, the client doesn’t know what was done, there’s little or no documentation, there’s no knowledge transfer and training. The end result is, now the client is married to the consulting company for any problem-solving, upgrades, fixes, additional deployments and so forth, which is their end game.

We work with clients in a way that best suits them. Our clients choose to work with us; they are not stuck with us because they have no other alternatives. For instance, some clients rely on their own expertise for many projects. However, when it comes to GroupWise-related matters, OES, or other Novell products, they turn to us because they know we have the Novell experience they don’t. Just recently, a new client selected us over another integrator because we were willing to approach the IT projects they needed assistance on their terms.

Or another example: a large company with thousands of users needed a GroupWise stabilization, virtualization, and clustering project. Now, I could have completed the entire project in about six to eight weeks, perhaps even less. But the client wasn’t interested in this blitz scenario. They wanted to go slowly, test things thoroughly in a virtual lab, implement changes only in off-hours when everyone was out of the system, schedule changes and upgrades well in advance, get full approval, etc. So the project ended up taking significantly longer, almost eight months. The point is, we are flexible enough to take as much time as necessary.

RD: It seems that while emotionally you have a strong allegiance to Novell products, which you regard highly, you are equally knowledgeable and at ease with Microsoft technologies.
SK: Ultimately, it’s all about the clients and what they are using. That’s why we make sure to stay on top of things, whether we are talking about Novell, Linux, or Microsoft. We have to be ready. And while this may seem likes a daunting task, it isn’t that difficult once you have a strong foundation and the ability to be a quick study. That's why we are able to execute complex and multi-stage projects, such as software upgrades, email migrations, archiving, clustering, data recovery, and compliance without being concerned about the particular operating system or messaging platform.

In part 2 of Scott's interview, he discusses why he recommends M+Archive to his numerous clients in healthcare, government, and education.

Every once in a while, a story starts making headlines that reminds me why I do what I do (and why email archiving is important). This week’s headline grabber is all the hoopla surrounding U.S. Supreme Court Nominee Elena Kagan. Controversial for a number of reasons, if Kagan is confirmed by the Senate, she will be the first Supreme Court Justice in nearly four decades without any prior experience as a federal or state judge, which means she has not created a paper trail of court opinions typically used to assess a nominee's ideology.

However, she did serve as a Clinton adviser in the 1990s, around the same time that the Clinton administration implemented an email archiving strategy to archive email from its Lotus-Notes-based email system. At the time, the Clinton administration implemented the email archiving solution in response to a 1993 court decision that stated that that the president has an obligation to ensure that the emails of senior officials are preserved.

(The Bush Administration later replaced the Lotus Notes-based email system used by Clinton with Outlook and Exchange which wasn’t compatible with the old archiving system, and resulted in the loss of millions of email records, which were later found... but perhaps that’s the subject of another post.)

Over the next few weeks, the Clinton library, run by the National Archives, is expected to release every piece of email that Kagan sent and received during her tenure as a Clinton adviser, approximately 79,000 pages of email in all, to help establish her credibility as a nominee.

If Kagan wins the nomination this summer, she probably has a lot of people to thank. If I were her, I’d add Bill Clinton and his IT team to that list.

Last week, I was talking to one of our healthcare clients about upcoming plans for their messaging system and GWAudit, our company's new offering, came up. The client had some very specific questions about the scope of service – all of which are detailed in a comprehensive white paper on the website. While I strongly invite you to check it out, I thought I'd offer you a "CliffsNotes" alternative, as well.

The reality is, an actual company reached out to us and requested our help in evaluating their email environment, identifying the risks, and recommending a plan of action towards better risk management. The engagement was not only successful, but received very positive feedback from exec management. We thought we'd extend the service to more clients.

Here's how it works. The auditing methodology identifies 3 types of GroupWise risks based on the level of severity, the urgency to address them, and the IT effort required for an effective implementation: (a) Critical, (b) Important, and (c) To Be Considered.

Using standard analytics tools, such as ConsoleOne and GroupWise Monitor, our GroupWise experts investigate the company's collaboration ecosystem and look at:

• System architecture, fault tolerance & redundancy
• Message routing & delivery
• System security, configuration settings & patch and revision levels
• Retention and data management
• System maintenance, health and manageability

Depending on the results, they make recommendations for improvement through system consolidation and adoption of best practices in email management and risk mitigation. The goal is to help you become more efficient managing your business-critical email system and reduce its vulnerabilities.

Let's face it, new communications and social networking tools or not, email still reigns king. An Osterman Research survey from March 2010 found that on a typical day the average user sends 44 emails and receives 123 emails. For an organization of 1,500 users this means 64.9 million emails in one year. And it's your job to keep them coming and going.

We want to help you get the job done. That's how GWAudit came about. The best part is, you don't have to do the heavy lifting and in about a week you've got a clear plan where you should start first.

Interested? Get the details from our website or just send me an email.

Recently, ITBusinessEdge.com associate editor and blogger Lora Bentley contacted me asking for some insights and perspectives on email archiving. She was working on a piece she published last week about how IT can justify email archiving as a necessary and worthwhile investment. She was looking for the top 5 "must dos"/"must haves" for successfully selling such solutions to management.

It was a good exercise that forced me to sift through the huge pile of technical documents and marketing collateral looking for the essence. I found it in two words: Reduce and Simplify.

• Reduce email system downtime and productivity losses;
• Reduce risks of lost or deleted email and penalties for non-compliance;
• Reduce the costs of storage and eDiscovery;

• Simplify email lifecycle management;
• Simplify email back-up and storage management;
• Simplify internal and external search and retrieval of email records.

Our customers confirm this. For example, the exchange with Lora coincided with a story I just published on how the University of Dundee is using our archiving solution to roll out a campus-wide email retention and risk management strategy for 28,000 email users. The main benefits they see M+Archive bringing to them are: contain the growing volume of email and storage requirements, address eDiscovery and open records requests quickly, simplify access to centrally archived email.

Jim Finlayson, IT Manager at the City of Grand Junction, also confirms how using our security and archiving solutions allows them to preserve the City’s resources and ensure uninterrupted email system activity while improving employees productivity and disseminating information across the community with minimum IT overhead.

For Mark Hayward of market-leading satellite communications company Comtech EF Data, M+Archive’s value is in its ability to handle eDiscovery requests for intellectual property, contracts, and email records in seconds. This enables him to service his organization's legal needs and maintain a competitive edge quickly and cost-effectively.

Email archiving is not just an IT issue, much more it is a business issue. Retained email records are not IT’s documents, they are records of the business. That’s why the decision-making process for adopting email archiving needs to involve all primary stakeholders, not just IT. When you get everyone one the same page, the “reduce and simplify” IT aspires to easily translates into Success for the whole organization. Then the job gets much easier: while not everyone may understand why reduce and simply is a big deal, they all get Success.