This article is for you if you are about to start working on your first Oracle project as a contractor

I’ve been running technology change programmes as a contractor for nearly 20 years. In doing so, I will typically hire 20 contractors onto any given project. Some have been with me on other engagements and some are people who I wish I had known when I first started out.

The people I enjoy working with most of all are those that are contracting for the first time. This can either be students that I’ve taught or people who have worked in a client role who have decided to make the leap to becoming a contractor on an Oracle project.

Tomorrow I’m due to have a call with just such a person- Karen. This isn’t their real name but everything else is. So, if you are about to start on your first project then read on.

I’ve worked alongside Karen on one of my previous clients and she was instrumental on an HCM implementation. Karen was the client lead at the Director level for specifying the Oracle HCM system covering recruitment, Oracle Time and Labour (OTL), Absence and HR admin. During the implementation Karen supported the client Subject Matter Experts and had a key engagement role with the System Integrator. Ultimately, Karen signed-off the User Acceptance Testing and took the project live and through hyper care. Kare over saw the transition to “Business as Usual” and would mange 23 quarterly upgrades. She also managed the transition of the Payroll & Pension team into her command and was responsible, by my count, for 40 monthly payrolls in Oracle cloud. She also managed the implementation of Oracle Help Desk as well as Oracle Learn and ran the Oracle hub of Subject Matter Experts. For four years Karen managed the relationship with the Oracle Managed Service Provider.

At the same time that Karen decided to go contracting,  a “Karen shaped hole” opened up on my project and I jumped at the chance to get Karen onboard.

What to do and not do

This is what I going to tell Karen tomorrow ahead of her starting on Monday. It would be the same advice I would give anybody starting on their first Oracle project.

1. Be clear on what your objective is. The difference between a corporate role and a contractor role is that you won’t get bogged down in the corporate day to day affairs such as appraisals, line management and a whole load of other tasks that you never realised got in the way of doing your job. As a contractor you can be laser focused on your objective. However, you need to be crystal clear as to what your ‘mission’ actually is. I often find that the client is not clear themselves as to what the problem is that you are expected to solve. Write the problem down and reflect back on it often- I’d suggest weekly. Also, in writing down the problem make sure you know what “done” actually looks like. Each week identify the 3 things that will move you closer to your objective. It often helps to create a weekly highlight report that explains what you achieved last week; what the 3 things are you are planning to achieve in the week ahead and any issues that management need to be aware of. Even if there isn’t the stated need for such a highlight report it is worth creating one even just to be accountable to yourself.
2. Keep an eye on your watch and not your calendar. As a contractor, the client will be either directly or indirectly aware of what you cost. In the corporate world, completing a task might have taken two weeks; in contracting this comes down to two days. What was two days is now two hours. Remember, you don’t have all the corporate ‘noise’ to worry about any more. If the task is sizeable then always break it down into bit sized chunks. The delivery of each chunk should be a measurable achievement that totally aligns with your mission. Everything should align with your mission -otherwise you are not working on solving the problem you were hired to fix
3. Get the administrivia out of the way on day 1. No client wants to spend top dollar for somebody at the end of the first week who doesn’t have a security pass or a laptop. You’ll have one day grace to get yourself up and running. No excuses. 
4. Build trust fast. You’ve been brought in to solve a problem; talk about the problem you’ve been brought in to solve- not the job title you’ve been given. Talk about your achievements from elsewhere and not the job titles you’ve had. 
5. Build in time to manage your communications. You are there to do a difficult job and there will be challenges along the way. You will encounter issues as well as your ‘worry beads’ of why you might not be able to complete your mission. These ‘worry beads’ should be seen as risks. Make sure you are logging the risks and issues associated with your objective. If the client has a risk and issue process then use it. If not, create one. I’d recommend at least 20% of your time to be focused on outward communication of how your are progressing; what your risks are and what you are doing to manage them.
6. ‘Imposter syndrome’ is real. High up on your list of worries will be the nervousness you have and possibly the feeling of being a fraud. Firstly, no need to log this worry with the client as a risk(!), however, all the contractors you are surrounded by will have this worry too. My advice is to be reflective. Look back at the experiences that made you successful elsewhere. Find yourself a mentor and dial in with them at least monthly
7. “Talk less, smile more”. The words from Aaron Burr in Hamilton will serve you well. For sure, never go to a meeting and say nothing but do be concise; ask questions to see clarity and dont seek to come away from a meeting with the most actions. In the corporate world you might feel the need to justify your role by having lots of actions to do. However, if it doesn’t help you achieve your mission then it is purely a distraction.
8. Be yourself. Probably, more importantly, don’t try and be somebody you are not. Keep focused on your mission and don’t try and solve the problems that other people are responsible for solving. 

Are you part of an Oracle project to move HR, finance, payroll, procurement or customer experience to the cloud? If so, then this article is for you. The move to the cloud is a big undertaking but what happens after the project is complete? This article will help you understand the role of a Managed Service Provider (“MSP”), what they do and what options you have.

Terminology

I will use the term Enterprise Resource Planning (“EPR”) as a catch-up for all or any of the modules that are moving to the cloud. ERP is a very broad term that usually describes a platform of inter-operable applications and modules to manage (often) some of your organisational resources or (rarely) all of them.

A hot fix is a patch that is applied outside of the quarterly upgrade cycle that is required to resolve a defect in the system

Platform-as-a-Service (“PaaS”) is the place where we build custom configuration extension to deliver a workflow that is not supported in the core ‘out-of-the-box’ product. “PaaS extensions” is the term we use forone or more custom scripts that are considered as a customisation.

Context

The following chart shows the hype curve for ERP from Gartner:

The hype curve shows that there are two areas of extreme maturity for ERP: firstly, the actual managed service itself (The Oracle cloud) and secondly the third party support that is available.

Third party support comes in two flavours: firstly, the system integrator that actually helps you migrate to the cloud and second is the MSP for what happens once you are in the cloud. The differences between a system integrator and a MSP far outweighs the similarities.

Moving on from a System Integrator 

The system integrator helps a client through the software development lifecycle from planning through to deployment. This journey goes through analysis, design, configuration & implementation and testing prior to cutover and go-live. During this journey a series of configuration work books (“CWBs”) will be created which will document every part of the system. The CWBs would allow a third party with the appropriate skills to recreate the entire system from scratch. To this end, the CWBs are both large in number and extremely detailed. The system integrator will handover the CWBs at the end of the project. The CWBs will be the one (and sometimes only) deliverable handed at the end. You may well have spent years and millions of pounds with a system integrator and suddenly all you have to show for it is dozens of CWBs which often are simply Excel workbooks- that and the cloud based system itself. At this point you have an option:

1. Support the system yourself 
2. Handover the support to an MSP

Support the system yourself- “Going it alone”

The first option cannot be ruled out but is highly unlikely. The system integrator will have utilised a large number of functional consultants who are experts in their application (HR, Payroll, tax, finance, procurement, recruitment etc). It’s possible that a consultant supported more than one area (e.g. Time & labour & Payroll) but the likelihood is that there were many consultants. The cloud based applications are so diverse that you won’t simply have one functional consultant who understands the whole system. These consultants did the analysis, design and configuration for their part of the system and, more importantly, understood the impact of their module on other parts of the system. Behind the scenes, the consultants would have been collaborating with each other to ensure that workflows, modules and applications all joined up so that data flowed seamlessly through the ERP system. It would have been a full time job for a lot of these consultants for 12-18 months. Some of the smaller modules (e.g. Taxation) might have required somebody with deep expertise who may have only been part-time. 

Once the project is finished then the system integrator will depart (usually after a short warranty period). From this point forward, your organisation will not start still. There maybe changes to your operating model, changes to prices, tax legislation, you might be new products to market. Changes in your organisaition that will almost always result in changes to the system. In fact, any change to any drop down in the system or the business logic in terms of how the system works. Also the Oracle cloud system is upgraded every three months and this itself might bring new features you want to utilise or create a conflict with how your system was set-up in the first place. It is possible that a quarterly upgrade ‘breaks’ one of your existing key workflows. From experience, I’d recommend planning for a breakage once every five or six quarterly upgrades.

To make any of the changes to the system you are going to need deep functional expertise. This expertise will need to be as deep as those skills that first created the system. Every change needs to be analysed, designed, configured and tested with a full understand of how the system is configured and how the change will impact all of the other parts of the system. To do this safely will require a team of functional consultants as large as the team that originally built it. This might not seem like too much of a problem but the issue is that the volume of change after go-live is likely to be considerably lower than the amount of work required to create the system in the first place. Put simply, you will have a large number of expensive functional consultants sat around for a large amount of time doing nothing. Once in a while you will require one of the functional consultants to spring into life to make a key change. 

It is not to say that “going it alone” is the wrong answer, however, you’ll have to do the maths to determine if the volume of change warrants it. “Highly unlikely” will be the answer.

Handover the support to an MSP

From the above description, a model of ‘fractional functional consultants’ would be a good solution. This is exactly what you get from a MSP. You will have an over-arching support contract with access to consultants with deep functional skills. The MSP will usually front this with a service desk. The MSP business model is that they will be supporting a number of clients at any one time that makes it economical to employ functional consultants for each area. The MSP functional consultants will be available for small, medium and large sized changes and their work is scheduled in on a priority basis. Most MSPs will have more than one functional consultant for each area. This helps with not only from the perspective of resilience but it also allows the MSP to allocate named individuals to specific clients so that they get to know the configuration for that client as well as the client side team.

Services provided by an MSP 

Your MSP will provide two core services often referred to as “Break-fix” or “Service requests”. 

Break-fix incidents

A break-fix is where there is an incident because something is not working properly. Ultimately, these are rare. For example, a customer invoice that is not being picked up by advanced collections but this is probably a ‘bad data’ in the system as a result of a training or process issue somewhere else in the organisation. It is also possible that there has been a technical issue on the Oracle cloud based platform that is resulting in processing issues in your organisation (however this is rare). Another, more common reason, is that a quarterly update has not been tested fully and that a ‘hot fix’ is required. PaaS extensions are particularly prone to issues associated with quarterly updates as Oracle will not have done in-house testing against your PaaS extension. It is often the case that the MSP will raise an Service request with Oracle themselves if the incident is related to the product or the underlying cloud based platform. Your in-house support team will have visibility of the Oracle Service Request and usually the MSP will manage the ticket with Oracle directly on your behalf.

Service Requests
This is by far the high volume of contacts made to the MSP. These can be thought of as “How do I?” questions. It’s often the case that MSPs will provide knowledge base articles that will help you find the answers and this can often be on self-service support platforms such as ServiceNow or Salesforce. Common Service Requests will be responded to by the MSP service desk while less frequent, deeper questions may get referred to the functional consultant. Unlike incidents, it is rare for a client service request to require an Oracle service request to be raised. This is because the MSP is there to support your configuration and Oracle is there to support the core product. “How do I?” Questions mostly occur as a result of a need to understand how the product behaves with the configuration itself. You won’t go far wrong if you remember that “MSP is there to support the configuration; Oracle support the product”.