IBM TRIRIGA: A Deployment and Cutover Story

As our higher education client was approaching the finish line of the Systems Development Lifecycle enabling eight (8) university business areas within IBM TRIRIGA, there was no time to rest.  Instead, with newly business-approved TRIRIGA configuration in hand, they set out to proactively plan deployment and cutover processes that would deliver them to a successful Go-Live of all TRIRIGA modules…wait for it…at the same time. To do this, two (2) tracks were created that would ready the technology as well as the organizations and end-users.

Deployment and Cutover: Systems Readiness 

Systems Readiness answers: what environment, data, integration, security groups, and user account related activity must be done to ensure that the TRIRIGA Production environment is ready to activate end users on all business process?  Our answer to this question took 6 months (180 days) to execute but gave us the quality assurances we needed to answer the last and final “Go / No Go” question. 

1. ENVIRONMENT (Day 1 – 15)
Once we had UAT configuration approved by the business, we were ready to stand up the TRIRIGA Application Server and Processing Server.  Next, we applied the Master Object Migration Package (OMP) resulting from UAT.  Then, we began updating Lists of Values and Classifications as necessary based on the approved business requirements.  After a quick (non–transactional) perusing of the environment, we were ready to proceed! 

2. DATA (Day 16 – 180)
Here’s the thing: getting data into TRIRIGA can be quite complex, especially when you are loading data across several modules and many business objects that must be linked together in Production (i.e. ‘Lease 13’ is linked to (associated with) ‘Space A’).  For this client, we developed a detailed data migration plan for 81 data templates (you read that correctly) across Space, Lease, Maintenance Tasks, Capital Projects, and others.  We separated these templates based on whether they belonged in TRIRIGA Portfolio or not (Non-Portfolio).  The general thought being that Portfolio data is the most highly ‘associated’ data across the platform, so it should go first.  Then, we can load Non-Portfolio data based on data dependencies. 

Even given the 81-template data migration schedule, there was still data that had to be manually entered. So, we had to include that in our data schedule based on dependency as well.  Some data had to be manually entered before other data could be migrated while some data had to wait for other data to migrated before it could be manually entered.  We’re having fun, aren’t we?

What was doubly important is that a process was stood up that would accommodate: 1) prepping the data template and populating data; 2) reviewing the template with basic scripting (i.e. locating leading blank spaces); 3) loading of the data; and 4) validating the data had been loaded and was now appearing in the application as expected.  To understand duration of each of those steps for each template (4 x 81 = 324), we developed detailed levels of effort for steps 1 – data prep and 3 – data load.  Then we utilized general rules based on data type, dependency, and association to understand duration on steps 2 – template validation and 4 – data validation.  Durations associated with steps 2 and 4 accommodated a likely change-rate and in some cases: provided contingency when no updates were needed; and in other cases: proved very important. 

3. INTEGRATIONS (Day 50 – 180)
This client was going live with 30+ incoming and outgoing integrations for TRIRIGA. At some point, these integrations must be turned on and ‘green lighted’ from Production.  For us, the exact dates and times of turning these on were based on: 1) data dependency, 2) user dependency, and 3) process dependency.  This schedule was married to the overall deployment and cutover schedule and executed on queue. 

4. SECURITY (Day 177 – 180)
To properly provision access for all user types, we developed a detailed Create, Read, Edit, Delete (CRUD) matrix by TRIRIGA module, object, and form.  This had been tested and subsequently approved during UAT.  However, during deployment and cutover, we needed to make sure that the correct profiles were applied to each end user.  This was done via a data template and therefore followed the steps outlined in the #2 Data.   

Then, the final step of security is Activating the user within the User Profile.  This is how we GO LIVE in TRIRIGA.  If you notice, we deployed our Master OMP back at the beginning of this epic story.  So anyone who had access at that time was able to DO whatever they had access to do immediately following.  Therefore, most users were provisioned via Data Template load JUST before Go-Live.  In one fell swoop, this client provisioned and activated 2,500 users.  And, the next morning, just like Christmas, everyone woke up to a Brave New World. 

Deployment and Cutover: People Readiness 

Just as important as systems readiness is people readiness which we defined as: communication, training development, and training delivery necessary to prepare the organization and end users for the launch of TRIRIGA.   

5. COMMUNICATIONS (All the way thru)
Although, this client distributed various forms of communication to user groups, Leadership, and stakeholders throughout the entire SDLC, communication became doubly important as Go-Live day grew nearer.  Communications typically fell into one of the following categories: 1) Leadership – Support the change; 2) stakeholders – Here it comes and what to do; and 3) User Groups – Here it comes, what to do, and next steps. 

6. TRAINING DEVELOPMENT (Day 1 – 140)
For a program this vast, training development took on many different forms to product training units that suited the subject matter and the recipient.  Many training units were enabled via online module learning.  Some were developed for in-class delivery.  Others took the form of referential material. 

Online learning was most useful for the large user groups as well as user groups with training that could be digested in small snippets.  In class learning was used for training where hands on experience and viewing was important.  And reference material was developed for processes that would be handled only by a small user group (5-10).  This is because individuals in those groups was likely already involved in the testing phases of the SDLC and/or some elements of deployment and cutover. 

7. TRAINING DELIVERY (Just–In–Time)
Training was delivered via the mechanisms described above in a just-in-time fashion.  The idea was that we wanted training content to be fresh in the minds of the end users at Go-Live.  Therefore, training delivery was delivered to fit within a 20 business day window prior to Go-Live.  This proved very challenging with 2,500 users set to receive training on one or multiple modules and processes.  

Ultimately, these seven (7) elements were able to be melded together within a single schedule to develop a common critical path wherein each element included critical path tasking at different times.  This meant, that at first, Environment provisioning and Portfolio data were the critical path, then it became a back-and-forth between data and training.  This made it important to track status for each element independently so that issues could be resolved proactively before having any critical path impact. 

Well, there you go.  Easy-peasy, right?  Lastly, I would encourage organizations looking to deploy IBM TRIRIGA to give us a call.  As you can tell, DL has been there, done that, learned the lessons, and bought the t-shirt.