Awarded to Cognizant Worldwide Limited

Start date: Monday 8 June 2020
Value: £210,000
Company size: large
Health Research Authority (HRA)

Maintaining Pega applications in production and enhancement of user experience

6 Incomplete applications

3 SME, 3 large

11 Completed applications

8 SME, 3 large

Important dates

Saturday 28 March 2020
Deadline for asking questions
Friday 3 April 2020 at 11:59pm GMT
Closing date for applications
Saturday 11 April 2020 at 11:59pm GMT


Summary of the work
Maintaining and supporting live applications: CWoW IRAS portal, on-line booking of applications and non-CWoW amendment e-submission portal and associated interfaces and integration. Development, testing and deployment into the production environment of additional functionality which may be subject to change in the light of the COVID-19 outbreak.
Latest start date
Monday 8 June 2020
Expected contract length
Commence 8 June 2020 to be completed 31 December 2020
Organisation the work is for
Health Research Authority (HRA)
Budget range

About the work

Why the work is being done
In March 2020 the HRA went live with the Pega CWoW IRAS portal. Two further Pega applications go live in May 2020.

We are looking for a Pega systems alliance registered partner with experience in cloud-based Pega 8 development to both maintain and support existing Pega applications in the production environment and to develop functionality to enhance user experience, prepare for EU transition and provide transparency for CTIMPs.

Background can be found in Explanatory document. This can be accessed here:

Information relating to the Combined Ways of Working pilot (CWoW) can be found on The HRA website:
Problem to be solved
The HRA requires a Pega partner to assist in:
• Maintaining and supporting current Pega applications in production, including integration/ interfacing with external and internal systems
• Enhancing existing CWoW IRAS MVP application to improve user experience and prepare for UK EU transition.
• Developing new Pega application for CTIMP registration and associated applicant reporting requirements

Deployments will be coordinated with EU transition timescales, other agencies (e.g. MHRA) and 3rd party suppliers consequently resources may be differently profiled over time.

Work may require aligned development sprints with suppliers of interfacing systems. Exact requirement are subject to change in response to the Covid-19 outbreak
Who the users are and what they need to do
The users are researchers and sponsors (applicants) applying for approval to undertake health research in the UK.

As an applicant I want to:
• Prepare and submit applications and amendments using existing Pega applications.
• Access enhanced functionality for CTIMP applications that aligns to new UK processes.
• Register my CTIMP according to legislative requirements.
• Be prompted by the system to comply with reporting requirements.

So that I can comply with UK regulations in the light of EU transition.
Early market engagement
The HRA commissioned an independent review of their research systems in late 2017 to assess their ability to meet future requirements in the light of EU transition and further improvements needed to support the wider UK research governance systems. This resulted in approval to procure a technical platform (Pega Systems) and associated implementation and support services to deliver a technology platform to provide the basis for the HRA to comply with future regulation associated with clinical trials of investigational medicinal products, which have introduced a need for changes to the HRA systems.
Any work that’s already been done
• HRA procured Pega platform on Pega Cloud and services to support initial build.
• Discovery work and high-level sizing for range future modules April 2019.
• First module (CWoW IRAS portal MVP) and interfaces with 2 systems deployed to production 2 March 2020.
• Two additional modules in development to support Online Booking System (OBS) and e-submission of amendments, to be deployed to production early May 2020.
• CWoW MVP product currently Beta phase.
• Two Pega applications in development to support ODS for applications and e-submission of amendments.
• Working with partner, MHRA, confirming requirements for EU transition.
Existing team
• Programme Manager (coming into post)
• Resource Manager
• Scrum Master
• Product Owner supported by 2 Product Managers and SMEs
• 3 Systems Architects (seconded)
• 4 x BAs plus one development Business Analysts (mix of contract and permanent staff and mix of Pega and non-Pega skills).
• QA and Test Manager (contracted) + 6 x Test analysts (mix of contracted and permanent staff)
• 3rd party, near-shore supplier of current non-Pega systems
Current phase

Work setup

Address where the work will take place
The HRA team is based at Skipton House, 80 London Road, SE1 6LH and it is expected that key members of the supplier team is co-located here but this is subject to change in the light of the COVID-19 outbreak. Any proposed near/off-shore resources need to be managed by the supplier and be available during UK normal working hours.
Working arrangements
The programme is being led by the HRA and any supplier will need to work within an integrated delivery/management model. There will be a requirement to co-locate however there is flexibility to work remotely using appropriate technology but this is subject to change in the light of the Covid-19 outbreak. A key requirement of any supplier will be to ensure effective knowledge transfer during the period of engagement
Security clearance

Additional information

Additional terms and conditions
Additional GDPR clauses may be required depending on supply location and EU trade negotiations

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Essential skills and experience
  • Demonstrable evidence of successfully delivering and supporting large scale IT Programmes on Pega platform to time/budget systems architecture design; planning and project management; quality control and testing; deployment/release management
  • Access to Pega Cloud and Pega development skills (inc Expertise in Pega 8/Pega Infinity) includes ability to supply experienced and accredited staff (both System Architect and Business Architect roles)
  • Demonstrable evidence of successful agile development and delivery, maintenance and support, including integration with 3rd party systems.
  • Demonstrable evidence of working collaboratively with a partner’s in-house teams.
  • Demonstrable evidence of knowledge transfer and exit management.
  • Demonstrable evidence of interface development and implementation experience using Pega systems to both internal and external systems (systems may be Pega or non-Pega platforms)
  • Demonstrable evidence of successfully managing unit testing, UAT and Systems Integration Testing on the Pega 8 platform alongside automated testing expertise.
  • Demonstrable experience of scaling up and down teams to accommodate either new requirements or changes within the delivery pipeline and regulatory timescales.
  • Demonstrable evidence of successfully assuming the responsibility to support and maintain live systems on Pega 8 platform (inc Pega Cloud and AWS support)
  • Knowledge of and expertise in accessibility standards and guidelines
  • Knowledge of and expertise in GDPR compliance
  • Knowledge of and expertise in GDS Compliance
  • Demonstrable evidence of successful UI / UX design and delivery
  • Ability to start on 8 June 2020
Nice-to-have skills and experience
  • Experience of both supporting live systems and deploying new functionality into the production environment.
  • Working in a regulated environment
  • Working in the health and or public sector

How suppliers will be evaluated

All suppliers will be asked to provide a written proposal.

How many suppliers to evaluate
Proposal criteria
  • Proposed Technical solution for development plus support of applications in production environment
  • Proposed resources, team structure/location onshore/offshore test and BA resources, mix and scale can flex ensuring development work carried out ahead of deployment may need adhere to regulatory/EU transition timescales
  • Proposed delivery plan for new Pega developments
  • Proposed approach to meeting user needs
  • Value added services offered
  • Level of Pega skills and experience as relevant to the HRA
  • What risks and dependencies have been identified, how the have been identified and offered approaches to manage them
  • How the partner will warrant the developed functionality and for what period
Cultural fit criteria
  • Can work productively and collaboratively as a team within the HRA, including liaison with external stakeholders and other suppliers
  • Is comfortable in adapting its delivery model to those of a small host organisation with limited internal resources
  • Can be transparent and collaborative when making decisions
  • Proactively shares knowledge and experience with other team members
  • Can work with clients with low technical expertise
Payment approach
Capped time and materials
Additional assessment methods
  • Case study
  • Presentation
Evaluation weighting

Technical competence


Cultural fit




Questions asked by suppliers

1. Is there an incumbent supplier providing Pega Expertise as a service to HRA?
There will not be an incumbent supplier providing Pega expertise as a service at the start of this contract. Currently a supplier is working with the HRA to develop 2 Pega applications but their contract will finish prior to the start of the new contract.

Additionally, several systems architects, working directly for the HRA on secondment or as contractors, are providing support for the live Pega applications. After a short handover to the new supplier all but one secondment will end.
2. Will HRA consider on or offshore options or is there a preference?
The HRA would consider different models of provision, this could include onshore, offshore or a combination of both.
3. 1. Does HRA have any SLA requirement for level 2 and level 3 support broken down by incident Severity 1-4, for both response and fix? Or would you like us to suggest these?

2. What hours of supports are required for the applications for level 2 support? Will HRA require extended support for severity 1 issues i.e. system down out of hours
1. The HRA would welcome any SLA requirement suggestions from the respondents.

2. The majority of level 2 support can be carried out during working hours apart from live system unavailability where we would expect the supplier to be able to provide 24 / 7 support as triggered by Pega Cloud services (Pega Predictive Diagnostic Cloud and Pega technical support team).
4. Part one of question:
1. Do you have a backlog of user stories for the intended period, can they be shared?

2. Could you please share a list of User stories or high-level process flow diagrams for the CTIMP registration process?
Part One Answer:
1. Currently working on backlog of user stories for development work, not yet in state where can be shared. Some stories require high level decision making ahead of preparation. Intended decisions will been made before supplier starts.

2. CTIMPs not currently registered by HRA but uploaded to EudraCT website by another agency. UK losing access to EudraCT as transition from EU December 2020. Need system for abiity to generate data points need for WHO compliant Clinical Trials registry. Haven't agreed which registry would be. Don't have process flow. Key requirement to be able to export required information.
5. Part Two Question:
3. Will the requirement to edit end date need any review/approval in the process in the CTIMP application?

4. What is the definition of approved cases for migration?
Part Two Response:
3. Yes, if the case end date needs to be updated then this is likely to have to trigger an “amendment” workflow. However, we wish to keep this as simple as possible and most of the workflow will be undertaken in interconnected systems.

4. A case must have a status of “approved” in our legacy system in order to be migrated. There is an existing process in place. There is a finite number of studies eligible for migration which may or may not be reached by the time supplier joins us.
6. 1. What is approximate number of cases to be migrated?

Should the migration be considered based on status ( i.e. approved cases only) or be based on a cut-off date (i.e. 2 years from cut-off date etc.)

Is migration a one-time activity or should we cater for periodic/on-demand migration?

2. Are there any components already available in HRA for migration that can be leveraged or all of the components are expected to be built from scratch?
1. 50 cases been migrated. Additionally, 55 approved and 21 not approved cases to be migrated near future.
Migration of cases based on status in legacy system and not on cut-off date.
Migration activity not one-time activity planned on weekly basis, further phases of case migration required
Case must have status “approved” in legacy system so can be migrated
Existing process in place. Finite number studies eligible for migration may / may not be reached by time supplier joins.
2. Migration scripts been developed and should be reused. Activity will be handed over by existing team.
7. 1. The enhancements requested on roles (for Pega CWoW Module)- are these enhancement around roles and accesses (granularity around accessing modules and components within the application) or are the enhancements around user and application behaviour?

2. Is there an existing support team for already deployed applications which would need to transition to the new support team? Are there any existing team members from HRA who will continue to provide Level 2 and level 3 support?
1. The enhancements linked to roles concern additional user roles having access to case components and some changes to one of the existing user roles. They therefore encompass both access to components within the application and around user behaviour.

2. There is existing team supporting the Pega applications deployed to production. Some members of this team will be with HRA at the start of the contract and will overlap with the new supplier for approx. 2 weeks in order to hand over. One team member will stay with the programme and will need to be integrated into the new team.
8. Are CWoW, Online booking, and E-submission applications based on a pre-existing Industry solution, or were they developed from scratch on Pega platform? If on a pre-existing Industry solution, which one(s)?
The CWoW, E-Submission and online booking applications are not built on any Pega Industry framework. Additionally, there are no industry frameworks to support these workflows. The applications are built on HRA enterprise frameworks that are managed by the HRA
9. How often are new CWoW MVP versions deployed to Production environment, and how many have already been deployed?
After the initial go-live, one CWoW MVP incremental version has been deployed to production. Timings of future deployments must be scheduled in alongside deployments of interfacing systems and to be able to support any necessary business change. There is no hard and fast schedule. Deployments are not made at the end of each sprint
10. Could you share Acceptance Criteria that were used for the CWoW MVP?
Each user story may have several ACs. The product managers (who act on behalf of the product owner) are responsible for signing off the ACs following UAT.
11. How many external services and systems other than HRA/MHRA case management, IRAS and CTIMP will the CWoW MVP and the new modules have to be integrated with?
The Pega applications interface with a federated identity authorisation gateway. Apart from this, for this procurement, the systems listed in the question are the only systems that the CWoW MVP and new modules will need to interface with. This may expand should we move to future work which is over and above this procurement
12. How often do you usually need to integrate new data elements with external systems?

How many unique business cases have already been implemented in the CWoW MVP? Could you share them?

Are the existing applications using custom UI controls heavily, or are they based mostly on out of the box Pega features?
Potentially any new system interface could result in new data items. For this procurement there will be two main additional data sets and they will build on interfaces already in place.

Currently there are 4 unique case types in the CWoW MVP: account, project, RFI (request for information) and amendments.

CWoW MVP application: Custom UI controls are built-in already, these are not based fully on PEGA OOTB (out of the box).

E-Submission and Online Booking Pega Applications: No Custom UI controls are used in the applications and are completely PEGA OOTB
13. How complex is an average process workflow (phases, stages, steps); and how many forms are there in an average process?

Do the existing applications support Offline mode / is it expected in the future?

Could you describe the existing process for controlling application versions across different environments?
CWoW MVP, E-Submission and Online Booking Pega Applications: All of the Process that are currently supported are of medium complexity with 3-5 stages and 2-4 integrations. The current forms are of medium complexity containing about 5-15 fields (we anticipate that this will significantly increase in this development)

CWoW MVP, E-Submission and Online Booking Pega Applications: There is no support for mobile application hence, offline is not in the current scope.