ProfServProjects

This page aims to give a detailed overview of customer-projects accompanied by the Open-Xchange professional services team: The different phases and decisions as well as the documents necessary to accompany this process are listed here.

The following diagram gives a birds-eye view of the whole process:

Initialization

During this phase the product gets demoed and the feasibility of the project is evaluated as well as potentially necessary customization to fit into every environment.

At the end of this this phase a detailed offer is made and the final "Go" / "No-Go" decision is made.

• Technical Demo (webcast or on-site)
  • presentation of the product including all features relevant to the customer
• Architecure Overview
  • Integration with customer systems instead of out-of-the-box
  • Explain the many ways to OX and its data
  • Used Standards and programming languages
  • Scaling / server density
  • Available APIs
  • Options for branding / whitelabeling
• Proof Of Concept (POC)
  • Machine in the customer-environment
• Technology Transfer
  • Evaluate customer-environment (mailsystem, loadbalancer, storage, provisioning)
• initial Workshop(s)
  • Using the agenda given below
  • resulting in the Customer Implementation Concept
• RequestForInformation / RequestForQuotation
  • answered by the filled out SOW

Tools and Results in the Phase

• Project Charter

The Project Charter is the one central document, outlining the whole project. It is used to document the common understanding of the whole project to ensure, having the same understanding in all projects parties. It starts with the motivation to run the project and contains all goals and the scope of the whole project. Stakeholders on both sides are defined as well as detailed responsibilities and milestones to measure progress. Also further organization of the project is specified including details about documentation, reporting and communication. All efforts, which are already known are listed in this document.

• Workshop Agenda This contains topics for the initial workshop
• Customer Implementation Concept This is a "living document" as well in that it is updated during the project to reflect the current state of affairs
• Basic SOW The basic SOW describes in detail all Open-Xchange implementation-efforts already known and agreed upon at this point in time.

Concept

During this phase it is decided what exactly there is to do, by whom and when. The resulting Customer Implementation Concept formalizes this information, accompanied by (several) SOWs which detail Open-Xchange efforts.

• Detail-Workshops
• Adaption
• Resources
• Time
• Budget
• Milestones
• Quality Management
• Risk Management

• Detail Workshop(s)
• Detailed architecture-description (which parts are delivered by operating system / customer / Open-Xchange)
• Installation of test-system
• Authentication
  • explain separation of contexts. 2 separate roles: oxadminmaster (creates contexts) and oxadmin (creates users, but only in his context)
  • explain resolving of usernames into contexts
  • Auth-Bundle: SSO, Auth-Plugin (DB, LDAP, IMAP, custom)
  • Passwordchange (DB, LDAP, IMAP, custom)
• Integration into customer´s provisioning (choose API best suited. RMI preferred)
• Loadbalancing (existing / Apache / buy new one?)
  • explain session-stickyness (1 session always resolved to the same host)
• Storage for Infostore (NFS / GlusterFS, existing / buy new?)
• Monitoring (munin, nagios -> script that polls Open-Xchanges JMX-interface)
• Scaling (How to setup a cluster, high availability)
• MySQL-Sizing (dedicated servers / on the ox-machine(s)? master-slave / master-master?)
• Branding (own heme, icons, login-page, wizard, about-dialog etc.)
• compatibility of the IMAP-backend (supported features vary between different MTAs)
• User-Migration
  • import exiting users / contexts via CSV-Batch-Import
• Data-Migration
  • from existing webmailers (Horde, @mail, squirrelmail)
  • contacts, appointments, mailsettings (aliases, primary email-addresses, mailfilters) via import-interfaces (HTTP-API, supported: iCal, vCard)
• Upsell
• SPAM
• SMS/MMS

Tools

• WorkBreakdownStructure mindmeister.com-format pdf rtf
• several SOWs (preferrably one per topic)

Implementation

During this phase everything that was planned before will be realized.

• Installation / Configuration
• Integration
• Customization
• Documentation
• Quality Management
• Change Management
• Training

• Documentation of all installed systems & components
• Training workshops for admins / 1st level support
• Open-Xchange-internal time tracking
• Open-Xchange-internal change management
• Open-Xchange-internal approval (review of the complete system)
  • Loadbalancing
  • MySQL-Cluster
  • automated tests
  • jmeter tests

Tools

• Requirements Checklist ... In this list all issues and todos, together with dates and the person responsible on either side, are tracked. It is expanded during meetings or calls as necessary. When the phase is over all items in the list should be checked, making the project ready for launch.
• OX Test protocols

Approval

During this phase everything that was realized will be checked (again) to make sure it is ready and exactly to the customers wishes. As soon as that is the case it is our recommendation to do a "soft-launch", a launch of the production system but with only a limited number of users (ca. 5%). When that is done successfully and any last-minute issues are uncovered and fixed the product is launched.

• Tests
• Review
• Soft-Launch
• Migration
• Handover to Support

• detailed technical documentation including test-accounts, credentials, people in charge etc.
• Customer tests
• Lessons learned
• Open-Xchange-internal project retrospective
• Handover to Open-Xchange support
  • test OTRS process

Tools

• Meeting Minutes These minutes cover attendees to a meeting, topics discussed, decisions made and action items.
• Requirements Checklist ... This list produced during the previous phase contains agreed upon and done items. These should be checked again in this phase by the customer´s quality assurance team for the live system.
• Customer test protocols