Rapid Application Development: A New Approach to Efficient Oracle Primavera Deployment As an old school project practitioner, I remember my early days of implementing Primavera P6. I used the tried-and-tested Primavera Implementation Methodology: it was very scripted, not very iterative, and didn’t respond to client changes (until it was sometimes too late). But it served its purpose, it was very simple to understand and easy to use. It was waterfall driven, though, which meant that each phase had to be completed fully before the next phase could begin and a major flaw in the waterfall model is that once the program is in the testing phase, it becomes difficult to change the core functions and features of the software. This essentially leaves you with software that may or may not fit your evolving requirement.

RPCuk has developed a new approach, which we call our Rapid Application Development process. It’s changing the face of Oracle Primavera implementations with dramatic benefits for the client and for us:

• Reduced development time• Increased reusability of components• Quick initial reviews• Encourages client feedback• Integration from very beginning solves a lot of integration issues

However RAD does depend on: • A strong team as well as individual performances for identifying business

requirements• Highly skilled developers/designers with an in-depth knowledge of the application• Focussed workshops, where all stakeholders can have an input at each phase

The model of bringing the end users into the system configuration phase is quite a departure from the past, but we are finding that, overall, this approach ensures optimal configuration, training, buy-in, and adoption – leading to increased client satisfaction and a faster ROI.

At RPCuk we deploy a combined Sprint and RAD approach to our implementations. Working with the client, we break down the overall implementation into small packages

(Sprints): each one layering on the previous completed Sprints. This combined approach of Sprints, workshops within each Sprint, overlaid with our RAD approach builds into what we call the “RPCuk Solution Set”. These solution sets are tailored to specific requirements and are based on real customer needs, providing that “real world” aspect to its capabilities.

The solutions are pre-built as templates in our application environment and then tailored to each new customer. During each Sprint, a series of workshops is executed to fully define, demonstrate and build out the requirements for each new implementation. RPCuk’s product and functional experts demonstrate the proposed functionality using these RPCuk

Solution Sets and then, together with the client, this enables them to agree the preferred solutions to satisfy each of the Sprint capabilities.

Once the necessary detail has been captured, the RPCuk team will begin to configure the solution, Sprint by Sprint, using a typical agile RAD approach whereby the configuration and design are executed in parallel to minimise the time from kick-off to deployment.

Collaboration is key to the success of this approach. Each Sprint is a collaborative activity between RPCuk and the client, with a series of design workshops at the core of this.

Workshops are hosted on the RPCuk environment, utilising the RPCuk secure cloud, which is pre-built with the RPCuk Solution Sets. This approach removes any need for disruption to the client’s current working practices during the development phase.

During the Sprint workshops, the client provides Business Operations knowledge, documentation, processes and procedures as well as SMEs responsible for the detailed requirements of each element of the build. This includes items such as reports, business tools used to manage projects, organisation and project structures. This detailed input from the client is critical to the success of the implementation, but also has ongoing benefits to the client, by developing Champion Users within the organisation, who can help to promote the new processes and offer a first line of support to new users.

Once the configuration and Unit testing is complete, a series of guided walk-through workshops allow RPCuk and the client’s Administrators to demonstrate the configuration and give the opportunity for a wider audience within the client’s personnel to review and challenge the functionalities demonstrated. Where necessary, alternative functionality options are then incorporated into the design and configuration and further walk-throughs are scheduled for review. This iterative process will be repeated until an agreed and accepted solution is defined.

This approach, supported by the guided walk throughs, allows the client to have sight of the functionality within each sprint at the earliest opportunity, promoting feedback and client interaction into the design, which results in a greater sense of ownership of the functionality in all sprints and a clearer picture of the complete solution. So, we design together (in the workshops), we build together (with the admins), we review together (via the walk throughs) and we repeat the cycle until the client is happy.

There are many benefits to utilising the client’s Administrators as leads during the testing and validation of each Sprint. They are seen as champions for the new capability and

gain a fuller understanding of the detailed configuration as it is being built. Building knowledge bit by bit in this way means that they do not need to expend a large volume of time to understand the detailed configuration after it has been deployed.

In addition, the handover of the configuration and design is streamlined and simplified as the Administrators have been involved from the outset in the configuration process; this

also means that the transition of support from RPCuk to the client’s Administrators is significantly reduced and de-risked.

Following the completion of the guided walk-through for each Sprint, access will be provided to the client to allow further testing and validation of the delivered capabilities under the guidance of the client’s Administrators, requiring only minimal support from the RPCuk team, promoting a level of self-sufficiency at the earliest opportunity.

The RAD roadmap The work elements for each of the phases up to deployment are detailed on the RAD roadmap. Introducing and explaining this approach is a key part of our pre-sales activity, so a client will already be prepared to begin the implementation with a wide-ranging scoping study to outline the goal of the project and detail the project scope: how will it look, how will it function, and what will be in and out of scope.

At this stage, we will also work with the customer to agree:

• Project Acceptance criteria • Project Deliverables • Project Exclusions • Project Assumptions • Project Timescales

When designing and implementing a complex Project Controls solution, RPCuk’s Rapid Prototyping approach offers an agile and efficient way of working to complete a successful implementation in the shortest possible time.

The aim is getting the client up and running in incremental stages from Discovery through to Closure, working towards full functionality built on the confidence that any operational issues have been identified and corrected in the early stages.

It’s an approach that not only minimises risk, but also expedites the ROI and allows us to offer user training in manageable, phased stages.

There are 6 distinct phases: • Discovery • Solution Design • Build • Pilot Trial • Deployment • Closure

Discovery In the discovery phase we analyse in more detail the user requirements, and gather these into something more cohesive that will enable us to map the overall objectives and scope of the project. From this initial scoping study, a high-level solution can be identified and the workshop preparation can begin.

Understanding the success criteria, the resources required – both client and consultant – and any constraints, are crucial at this stage as this will ultimately help the workshop preparation in terms of attendees required, availability of attendees and the topics to be covered. It’s also important that a “drumbeat” is quickly established. An example of a “drumbeat” using one of our large clients went something like this:

Let’s say a week has been allocated for a particularly complex workshop. The first two days were all about preparation.

This ensured that the business and the consultant were both fully prepared with a fully detailed agenda with inputs and outputs detailed.

That left day 3 for the actual workshop, and days 4 and 5 to prepare and run a playback to the client prior to sign off.

Of course, durations can be tailored accordingly but this “drumbeat” established just how the workshops would run and became familiar to the client.

As well as having the key ingredients to enable the workshop planning, a key deliverable from the discovery phase is the user storyboard.

This is an example of the storyboard we produce.

It shows in an easy-to-follow format without using any jargon, the business process flow, the interface to internal and external functions and typically the users who will be involved at each stage.

Replaying this storyboard back to the client shows that we have fully understood the high-level business requirement and also gives the client a chance to comment with any changes before the real work starts.

Solution design Moving from Discovery to Solution Design is where the serious work can begin, and this is done in a series of design workshops.

A clear workshop agenda is vital, and typically this should include:

- An overview of the workshop - A schedule of other workshops (so the delegates get a clear picture of what’s

coming up) - Duration - Purpose, objectives and outcomes of the workshop - Pre-attendance requirements (reminder of the business prep required) - Expected contribution from participants – listen, learn and get involved in the

discussions - The intended audience; Business/Function; Role/Subject Matter Expert; - A list of the workshop topics - The modus operandi of the workshop; for example system demo - Timed agenda; timekeeping is crucial - Validation of the requirements; cross reference to the Business Requirements

documentation - Summary and close; to include actions items, next steps, parked items

Minutes should be prepared, circulated and signed off for each workshop. After each workshop, the core functionality is captured and is fed into the core functionality build, which can be used as a playback to re-iterate the proposed design.

A typical design document is produced – these Unifier examples show a form design and data fields, example data structure and a workflow.

Other design documents, which RPCuk have templated, include:

- Design Assumptions - Shell / Data Structures - The User and Data Flow Diagram (refer to the Storyboard) - Data fields and Form Design - Workflow design - Responsibility Matrix similar to RACI - User Groups, Users and Permissions - Requirements Review –reference to the business use case - Change Log

We have similar design templates for P6 EPPM and Oracle Primavera Cloud, which include reporting and dashboards.

Build

To facilitate the build, RPC offers a ready built platform which can be transported to the client system prior to go-live. This platform already contains the solution sets, which will be tweaked to match the client requirements.

This provides a test bed for the client to use and ensures there is no impact on any production systems. It also helps where the client doesn’t yet have the software installed or is waiting for an upgrade or patches to be applied.

The initial core build is aligned to the previously agreed design specification using client data (anonymised if required) to playback as close as possible to how the system will operate.

Once the core functionality design is unit tested and signed off the detailed design is incorporated, built and ready for the pilot trial. This would also be the time to install or test any software on the client side if required.

Pilot The pilot trial will encompass the detailed design and is configured, along with a subset of production data for the client to begin the pilot trial. The design will be tested for robustness, adherence to the business requirements and workflows.

The results of the pilot trail will allow for any changes to be fed back into the detailed functionality build until approval. Remember, the whole purpose of the RAD process is to ensure that once the necessary detail has been captured, the RPCuk team will begin to configure the solution, Sprint by Sprint, executing these in parallel to minimise the time from kick-off to deployment.

In addition, the handover of the configuration and design is streamlined and simplified as the administrators, users and other key stakeholders have been involved from the outset in the configuration process.

Having the administrator as the champion also means that the transition of support from RPCuk to the client is significantly reduced and de-risked as they fully understand the configuration from the outset. The client can continue to further test and validate the configuration, requiring only minimal support from the RPCuk team, promoting a level of self-sufficiency at the earliest opportunity.

Deployment

Finally, the deployment phase extends the pilot trial to encompass all users.

Once the client software is installed and user logins tested, the user acceptance testing can begin in earnest.

Detailed test scripts are created showing which component or process is being tested, what the expected outcome should be.

A record of all the tests is captured and reviewed to ensure all the functions accept the correct inputs, give the correct outputs, and follow the logical business process flow.

This is the last chance for the client to test the functionality of the software and measure if it is fit for purpose.

The RAD Roadmap might suggest that training is only defined at the end of deployment in a waterfall approach. In truth, the training requirements have been identified at the end of each sprint, therefore the training needs analysis is actually incremental and works alongside the iterative phases.

A training needs analysis plan will include a detailed knowledge transfer program and development of the final end-user training material. Similarly, a detailed migration plan is created detailing all activities required up to the Go-Live date and subsequent early life support after Go-Live.

Closure As part of the close-out we always undertake an objective programme review with the client, where we will confirm with the client that all objectives have been achieved, that the success criteria have been met and that documentation is handed over.

On the journey, we are also conscious that any future requirements should be identified and we will revisit these with the client so we can continue to add value to their programme.

From a lessons-learnt point of view, as well as taking the positives we also want to learn from any negatives to ensure our RAD process is kept current.

RAD in Action: Case Study During the Covid-19 pandemic, Glan Agua – an industry leader in providing project solutions for the water and waste-water industry – was proactively looking to enhance its programme and commercial reporting on a portfolio and enterprise level as part of its growth strategy in the UK.

This type of implementation normally involves a series of on-site meetings, workshops and user training. Plainly, this would not be possible at the height of lockdown, but as time was of the essence, the client could not wait until working restrictions were eased. RPCuk successfully worked with the client to carry out the implementation and training using remote access technology.

Find out more about how we used our RAD approach to make this possible.