Mark joined this project at the beginning of the first development phase of this greenfield project. He was primarily employed to provide technical expertise to a team of junior developers, to help identify the best solution to requirements, guide the team on the use of best practices in terms of the use, development and deployment of Siebel. But Mark was also responsible for leading some of the workstreams, including defining requirements and designing solutions, and soon was officially made Development Lead.

The goal of the project was to replace a number of legacy systems for the mobile telecommunications company, some of which were scheduled to be switched off due to high maintenance costs, and to integrate with a multitude of back end billing and provisioning systems. The project would be delivered in phases, meaning that throughout the lifecycle of the project some business processes would involve both new and old systems, with solutions incorporating a mix of old a new systems/processes. This of course increased the complexity of the solutions to be developed, and created particular challenges with data migration as data that would ultimately be managed in Siebel would temporarily need to be maintained in multiple systems until to final solution was deployed.

Mark lead a couple of the workstreams, working with and guiding colleagues in gathering requirements, defining solutions, writing functional design documents, developing the solutions and performing system tests.

Mark introduced a Siebel Best Practices guide, and throughout the project would ensure that developers adhered to these best practices. This involved constant monitoring of the Siebel Tools configuration and solutions developed by the team, and highlighting areas of concern to individuals when necessary. This was important to CS as not only did they want to ensure that this project adhered to supported guidelines, but that their consultants were fully aware of the correct way of implementing Siebel, and could take this knowledge into future projects long after Mark had left.

Mark also introduced a structured deployment process to manage the releases of Siebel into multiple environments. This involved the use of a number of documents to track all non-repository items needing to be migrated, including all reference data such as LOV’s, responsibilities, positions, workflows, etc. Mark also provided his COM Loader spreadsheet which was used as the primary tool for deploying all reference data. Other tools provided by Mark to assist with deployments include:

• Spreadsheets and macros to manage server component changes (including creating new ones) and to enable/disable the required server components and component groups in all environments.
• Spreadsheets and macros to allow for easy definition of associations (such as Views/Responsibilities, Responsibilities/Employees, etc) in a user friendly matrix format with macros to convert the data into a structure that can be easily uploaded to any environment. This also included tools to reverse engineer a View/Responsibility matrix from data in any Siebel environment.
• A spreadsheet for keeping track of all reference data that is to be deployed to all environments. This is used instead of extracting data from the development environment where data quality can often be very questionable.
• Spreadsheets and documents for managing the tasks required to be completed during deployments.