Can ITSM, Waterfall and Agile practices coexist in the same organization?

For decades, many (IT) organizations have invested heavily in implementing ITIL/ITSM (IT Service Management) processes and find it difficult (if not impossible) to adapt to Agile practices. The same may be said when you introduce Project Management / PRINCE2. Considered by some as exclusive of each other, here is our example of peaceful coexistence between these different practices.

The project concerned a multinational pharma company, operating in over 90 countries, with a complex business structure; the IT organization, equally as complex, relying on multiple vendors, with priorities not always aligned.

A yearly IT survey targeting the business community gages the business satisfaction with the global IT services (e.g. Service Desk, infrastructure, etc.). Following the last survey, the end-user facing self-service portal received an overall score below the average, with comments such as: “difficult to use or locate information, we have to contact the Service Desk or the on-site support teams”, “not easy to understand the categories used by IT and locate the requests we are searching for”, “not user friendly”.

The Project

The project consisted in re-engineering the existing portal, built on the same platform as the ITSM tool used enterprise-wide. The focus was on:

Empowering the business end-users/shift-left, by reducing or eliminating reliance on other resources.
Accessibility and searchability, by moving from a browse focused approach and a global search (results often not relevant to the respective business user), to focused searches, targeting the portal sections.
Usability and communication strategy, by reorganizing and renaming the portal elements/sections, using business relevant non-IT names/terms and removing unnecessary ones.

Typically, within such a portal, you would find: knowledge / Information / FAQ / Articles, means to raise various IT or non-IT requests, service descriptions and contact options (phone, walk-in, chat, etc.) and support availability.

Geography and Languages

This organization has a very large footprint, with presence in over 90 countries; the top 5 countries are: France (28% of the user base), US (14%), Germany (8%), China (8%), Brazil (4%); other countries of interest for this project, Russia would represent 2%, and Poland 1% of the user base.

Our scope covered 70k of the 90k total users (internal and external), with 93% of them non-IT/business, and only 7% IT.

Due to the extensive perimeter, the initial portal was covering 10 languages (EN, FR, DE, CZ, HU, IT, SP, PT, CN, JP); 2 additional languages (Russian and Polish) have been added in a second phase.

Approach

The project budget was already approved and could not be extended. Due to other projects/programs, internal reorganization and resource constraints, the project deadline had a very narrow margin; from a PRINCE2 Agile perspective, this has rendered the cost and time fixed.

When the project mandate had been established and approved, only high-level requirements were visible. Once the detailed project scoping was initiated, priorities were defined and agreed, and the individual requirements strictly monitored against these priorities and business value (not IT perceived value). This rendered the scope flexible, and the benefits/risks somewhat flexible.

As the project started gaining traction and delivering visible results, additional budget was secured from another program, and a second phase was added, with a separate scope.

Project / Team Structure

In green internal resources, blue external/supplier(s).

From a PRINCE2 perspective:

From a Scrum/Agile perspective:

From an ITIL4 perspective:

Business users from most relevant geographies were involved from the early phases of the project; this was done either directly (early testing and feedback) or through senior users (the Voice of the Customer team), in permanent, close contact with the business users.

The project benefited from the existence of structured environments: Development (DEV) / Pre-Production (Pre-Prod/UAT) / Production (PROD).

Delivery

Operationally, the project and its deliverables have been structured in sprints. For each sprint, a variable number of stories had been described, clarified, prioritized, validated, developed and tested. 10% of the total stories identified were either deferred (returned to the Demand Management register) or cancelled (insufficient business value), 90% were implemented.

Phase 1 – Initial Requirements

The initial requirements were covered over 10 sprints of 1 week each, with an initial deployment to PROD following sprint 10, but with restricted usage to the IT public. This allowed for extended testing in live conditions, with a much larger population than the initial testing in Pre-Prod/UAT.

This was followed by 2 additional sprints (of 1 week each), with deployment to PROD after each sprint and emergency changes when required for fixing major bugs/defects. The release to the business users was completed at the end of Sprint 12.

During the entire project, the previous portal was maintained as backup and benchmark.

Phase 2 – Additional Requirements

The additional requirements were covered in 2 sprints of 2 weeks each, with deployment to PROD for each sprint. This was doubled by a Hypercare period for the entire project, with emergency changes when required, with the old Portal being retired at the end of Phase 2.

Change Control and Agile DEV

A set of very strict regulations is applicable in this specific industry (GxP); this translates into heavy Change Control regarding the ITSM environment and instances. At the time of this project, the company had no formalized Agile Development practices in place (e.g. Scrum).

When combining these constraints with Agile Development, the following story statuses were identified, defined, grouped and used throughout the project:

Although this appears a lot heavier than what can be typically found in Agile environments, this allowed us to have a permanent clear picture of: what has been achieved, how much/what can be achieved and what remained to be done.

Adopt and Adapt

Regarding several aspects of the project, the initial approach was adjusted to better overcome various challenges and constraints faced.

The previous portal was not well perceived by the business user (non-IT); we have preferred involving these stakeholders from the very early development stages, as soon as the first mock-up/prototype was available (sprint 2-3). Their feedback was a driver for the next stages and integrated throughout the entire development. This allowed us to benefit from the buzz effect and the business becoming one of our most important promoters.

For translations, we initially envisaged using an external company, providing professional translations. As the project progressed, and the translation initiated, we found out that the translated content required adaptation to the company and regional culture. Also, we have integrated all feedbacks/corrective requests received since the initial portal was launched. The translations were provided by internal employees, (IT in conjuncture with the business). The new portal spoke to the business, it was adapted to their needs, not just translated.

We had forecasted using an UX designer, but we ended up blending UX elements with a much more consistent input from IT Communication, thus ensuring the new Portal was aligned with the visual chart, recently updated by the IT organization. Also, working in conjuncture with the project team and the translation resources, IT Communication ensured the end-user facing communication was consistent and aligned with all other initiatives.

SWOT

Strengths

For all its faults, the existing portal was already in place and working, the ideal backup to insure no disruption the business. The Voice of the Customer (VOC) team members, very close to the business users, were part of the extended project team, speaking on behalf of the business users from the most representative geographies. Business acumen: between the VOC team and the business users involved from the early stages, the project benefited from a comprehensive view of the business requirements (not only the technical ones). Many of the ITIL Processes / Practices are in place and well established, with different levels of maturity. This allowed the project to benefit from a solid foundation.

Weaknesses

Various levels of knowledge across the different stakeholders and contributors involved. The initial lack of clarity on the requirements was turned into an opportunity as the project progressed. The very aggressive timeline was one of the main drivers for project delivery scheduling. The very large perimeter (languages, countries) required extensive coordination across multiple stakeholders.

Opportunities

Introduce one of the first projects using Agile elements, both for development (Scrum) and PRINCE2 Agile. In turn, this allowed us to “choose our battles”, continuously challenging the perceived IT value vs achievable business value and deliver the aspects most relevant to the target audience. Fix existing elements on the previous portal and improve the business perception of a very visible area of IT services.

Threats

With high end-user visibility, the project was not just about the technical work, the communication component was crucial for its success. The existence of the above-mentioned processes/practices generated a considerable amount of paperwork. Conflicting IT priorities and other projects, either by partial overlaps or resource allocations.

Lessons learned

If the same project were to start today, we would: increase the Hypercare period from 20% to 30% of the initial budget. Also, a Go-Live after sprint 8 (rather than sprint 10), would have allowed us to identify and fix sooner some bugs.

OMEC

info@omec.pl

801 55 66 32

POBIERZ ARTYKUŁ W PDF

WRÓĆ