Project description

The customer - a Germany-based telco company - wanted to significantly improve its time-to-market and its implementation efficiency for product launches. For this purpose, a central product catalog should be implemented, which should replace the inadequate and redundant mapping of landline/DLS broadband and mobile communications products in the legacy systems for processing customer orders and maintaining customer contracts (CRM).

The project pursued the vision to enable the telco-business to introduce a new product portfolio without any system changes across all order channels and across all brands. Instead, adjusting the configuration in the newly developed product catalog should be sufficient. Product management should be enabled to carry out such changes in the product catalog itself one day. At the same time, the provisioning of orders should come as close as possible to “zero-touch” processing .

The diagram below illustrates the target architecture associated with that vision:

Explanation of the target architecture:

• The product catalog as a central database with the products, including their properties as well as the entire declarative logic for the products

• The product designer as a UI based application through which the product manager defines the products according to market needs

• The product configurator which contains all executing product logic; which executes the product logic depending on the situation:

  • whether it is an existing customer or a new customer

  • which business case it is (new product, product change or product change (contract adjustment))

  • which channel the order comes through

  • whether any promotions currently apply

  • in the case of broadband products: which technologies with which bandwidth (line attenuation) are available at the address

• Each sales channel was supported by independent systems (portals). The product configurator should be integrated everywhere and replace the product order logic there. Because the system was too outdated for shops and sales partners to continue to use it sensibly and efficiently in the new architecture, it was decided to replace it with a completely new development and to implement it as part of this project.

• In the billing area, a new system was also implemented parallel to our project. This pursued a new concept, also with the aim of significantly reducing the time-to-market. It was based on the fact that product price information should no longer be maintained here. The new product catalog should take care of this and provide the price information together with the contract information to billing when contracts are concluded.

  During the course of the project we faced another task:

• A parallel project was currently in the process of introducing a new document management system, which would also be integrated with the front-end systems (portals) for the various sales channels. In this context, it was decided to additionally implement a document catalog in our project and integrate it with the document management system and the front-end systems (portals). In a similar way to new products via the product catalog, the document catalog made it possible to define which documents are sent with which product order, from which customer group and via which channel. This affected general terms and conditions, cancellation instructions, product brochures, etc.

My role and tasks

• As part of a program designed to restructure and consolidate the company's system landscape, I planned the project and managed it using agile/hybrid methodology.

• When the project architect left the company after almost a year, I took on a large number of conceptual tasks.

• I performed a huge amount of hands-on business analysis; Of the approximately 200 user stories created in 2014, created half of it.

• With the support of the head of the above program, I put a lot of effort and energy into convincing all areas of the company of our vision and approach. This affected the management, product management, sales, order management, customer service, the technical area and, last but not least, the IT department itself.

• Finally, my task also included planning, organizing and implementing training for the entire sales organization with around 1,000 internal and external employees.

Circumstances and conditions

The project broke new ground in many ways; the concept of catalog-based product ordering, agile development, project-based work were all new approaches for the organization. Our project was therefore faced with several challenges, which I will discuss in more detail in the following sections.

New concept, new ubiquitous language

For the customer in general, this project meant the adoption of a completely new concept; that of catalog-based order processing. Over the years, the entire company had gotten used to the technical conditions, which were characterized by the limitations of the existing systems. Thus, an “IT technical reality” and, above all, language developed that was largely far removed from the technical reality. The department had also become accustomed to this language over the years. As a result, discussions about technical requirements and the acceptance of the new concept became significantly more difficult. A lot of effort therefore had to be invested in “picking up” the entire organization and, above all, product management.

Two speed IT

Our project aimed to create a new system world in large steps. It was clear to all of us that the challenges were enormous. There would also be problems that we had to be willing to accept. We firmly believed that high speed of implementation and willingness to take risks were essential to achieving our goals. This also fit well with the culture of the sales departments, our primary stakeholders.

However, this approach collided - understandably - with the culture in the IT department that was more focussed on problem-avoidance and process conformity.

Architecture

At the start of the project there was an monolithic system covering

• Customer management

• Contract management

• Order management

• Product management

• Technical provisioning (setting up configuration in the technical systems, for new customers or customers who made a product-change

A large-scale program aimed to break this system down into several components covering the various business areas. In this regard, our project primarily covered the areas of product and order management. The company's architecture group tried to model the future system architecture using the SID model from the TM Forum.

Approach

The development was completely based on Scrum. The project was embedded in a program that was classically structured; with project managers for various projects who created time and budget planning and reported on them weekly. Agreements on important milestones had also been made with the primary stakeholders. The entire procedure can therefore be characterized as a hybrid.

Business Analysis

Initially, our business analyst created detailed EPK diagrams during the technical design, accompanied by descriptions based on the eTOM framework from TMForum. However these didn't provide enough support for developers; the diagrams were very difficult to read and despite (or perhaps because of) their enormous size, many key questions remained unanswered from the developer's perspective.

As a result, we brought the technical concept to two new pillars.

1. Following the principles of Domain Driven Design (Eric Evans), we created technical models. The team designed the technical data models for all areas together and - this is the crucial thing - discussed them intensively with the departments. These models were created using UML without claiming to be 100% methodologically correct. The aim was simply that the essential questions could be answered in discussions within the team and with the departments. This resulted in a so-called TK domain model, which represented a uniform definition for terms and entities across system boundaries. This should then later apply to the entire company.

2. For all masks we created UI mockups using the Balsamic plugin for Confluence. We then described all the essential business logic for the masks in Confluence.

We created user stories that were essentially based on the masks. There were several user stories for each mask, which were linked to the respective mask on the Confluence page.

We discussed the above-mentioned technical models, the mask designs and the user stories with the manager responsible for sales in a product owner group, which proved to be extremely effective. Backlog prioritization was also discussed here.

Below is an example of a technical model that I created to design user management and the administration of sales points (own shops and sales partners).

We had an interesting discussion in the project as to whether such a “technical” model could be discussed with the business or not. We just did it and it worked wonderfully.

It took us a few rounds to finally agree on a final version. The subsequent implementation was quick and smooth.

Development

Development was based on Scrum; Pair programming was used, there were peer / code reviews with the help of FishEye. There were groomings, planning including planning poker, 2 or 3 week sprints and sprint reviews. There was continuous integration and a maximum level of test automation was carried out through development (unit tests). This was monitored with Sonar reports, that were continuously displayed on a large screen in one of the developer offices. Furthermore, CVS, GIT and Jenkins were used in development.

The models that were created for all functional domains (see above under Business Analysis) enabled clean development which led to a software stack that was very adaptable. A effective set of development guidelines was established and rigorously followed. Because of this and because it was easy to recognize business logic when reading the code, it was also relatively easy to integrate new developers into the team.

The mask designs, which were consistently created and discussed with the product owners in advance, allowed for rapid and efficient development because the departments had already “seen” the application before it was completed. Big “aha” experiences followed by extensive re-factorings were herewith avoided.

Test

The test team used HP Quality Center for test and defect management. For development defects were transferred to Jira via an interface. Within the Jira tickets one could drill down to relevant code fragments. In addition, HP Service Virtualization was used for automated tests at the integration level. These tests were also extremely helpful in getting to the bottom of performance problems, because for individual transactions or calls from the front end one could track which service and which system in the middleware or backend took up which amount of the total response time.

Hybrid Projectmanagement

As described, development was based on Scrum. This however created a challenge of making binding commitments to stakeholders on key milestones. These stakeholders included the program manager, management board of the company, the sales department and customer service. They needed our commitments for planning sales targets as well as for personnel planning. And on their turn those stakeholders needed to give commitments to the management board of the mother-company.

In this regard, I proceeded as follows:

• I occasionally exported the backlog planning from Jira to Excel.

• Because only the user stories for the coming sprint were groomed and pokered, I initially had no reliable indication of when the user stories would all be ready. that were needed to complete a specific increment/milestone

• I then added columns for different implementation areas (Front-end, Backend) in Excel. SML complexity assessments were then made for these areas for each user story by the architects and developers.

• The effort per developer discipline was then calculated using an algorithm.

• The efforts that were determined in this way were calculated against the planned capacities, taking into account vacation times, etc., and then made it possible to determine the dates for the milestones.