Engaging with your System Integrator

In my previous post 'How to Learn to Love your System Integrator' we discussed some of the things that will help improve your general relationship with System Integrators which will importantly cascade into improvements in deliverables and working environments through communication.

In this follow on topic I'm going to set out some of engagement strategies that could be adopted in the early stages of your vendor management strategy. Of course, it goes without saying that its never to late to implement any action which will help steer an implementation back onto the road to success should a step have been missed previously. 

Engaging for Success

After you have selected your Systems Integrator the vital first step is setting up the engagement and programme governance. Your System Integrator may well recommend an approach which will work for them, but you should ensure that it works for you too. Ideally appointing someone on your side who has ideally been through this before will make the process smoother and ensure your interests are protected. This engagement strategy can follow a number of different approaches from a PID (Project Initiation Document), it may be contained in the SoW or as part of a Project Handbook. However it is done, it is important its documented in a usable format referring to the usual key suspects including:

• Project Objectives
• Key Roles and Responsibilities
• Key Scope Items
• Key Milestones
• Project Governance Strategy
• Programme Boards, frequency and objectives
• Company and specific IT and HR policies (H&S, Laptops, Phone use etc)
• SI resource expenses policy (if relevant)

Thats all the usual stuff you would do as governance on any programme, but importantly when working with an SI your environment is more changeable with additional resources/vendors rolling on/rolling off at regular intervals. This changeable nature makes it more important that familiarisation with the project rules are available, utilised and publicised. I've worked on projects where a lot of effort has gone into the project handbook, which has been completed and signed off and then consigned to sharepoint, never to be read again! 

Essentially the Project Handbook should become a living document throughout the life of the programme and referred to for various items:

• Onboarding new resources and/or vendors
• Checkpointing milestones
• Change Control procedures
• Contractual resolution procedures
• Resourcing process

The idea is to just keep one central go-to document to help everyone out on backgrounds - lots of precious project time can be consumed on boarding resources at regular intervals, not to mention time lost by new resources not following processes and procedures - getting people to hit the ground running as early as possible will maximise your productivity - this is true whether you are outsourcing, implementing or maintaining.

Specialists

From time to time you may find that a particular issue or a particular skill is required to resolve or complete various tasks. It is always a good idea to challenge the SI as to whether they are genuinely able to resource it and importantly what the impact to timelines may be - key resource skills can be in high demand and so early planning for specific skill sets is essential to keep things on track - you don't want your project stuck in a resource conflict because of a lack of a short term niche skill. As part of your standard governance process the plans need to be read weeks in advance as well as the immediate activities to keep momentum running - your burn rate on resources vs cost will keep running even if the progress isn't. Challenging your SI to keep on top of the advance planning as a separate task to your daily or weekly review processes will keep the project interests in the forefront of all involved. 

As an aside to this, its worth bearing in mind that sometimes the agreed cost model may need to be flexed to allow for specialists to be brought in - in a future article we will cover the topic of cost models.

Taking Stock

The phrase, 'its a marathon, not a sprint' is one you'll hear from your SI frequently, especially when things aren't going so well, e.g. milestones missed etc. To be fair, its actually a very accurate statement - its worth bearing in mind from the beginning. Milestones will be missed, items won't always be delivered on time, scope will change, etc. An individual delivery being missed in a multiple delivery, long implementation is fine, despite what you may be being told by your business counterparts - there is no need to panic as long as both sides have signed up to the replanning and resolution strategy. This needs to be communicated as early as possible in the cycle to ensure not just the project is agreed but the board, business sponsors also understand the feasibility and the reasons. Long term implementations are always fraught with speed bumps in the road - the sign of a good project team is how they react to that, and that is as important regardless of which side of the software implementation you are. 

It is easy in these scenarios to lay the blame at the SI for delays but its an honest approach to internally review how your side of the project has performed in these circumstances and take those lessons learned forward. For example, has a large amount of change control been thrown into the mix, have milestones been agreed with the business before scope signed off, have business decisions been outstanding and slowed down work? All of these an SI will help highlight for you, but an internal honest review will help ease any bottlenecks from your side in future releases. 

Taking a Break

Sometimes its worth just stopping for a few days to regroup - keeping smaller independent parallel tasks running if possible/feasible. Although you may burn a few project days, by regrouping, planning and refocusing you will inevitably save time in the long run - trying to carry on pushing a project through times of issues can negatively impact the long term reputation and success of your programme delivery - don't be ashamed to regroup! 

Nick Hopkins has over 20 years expertise implementing IT software solutions, with over 15 years spent in outsourcing and vendor environments. Nick has worked across the world including running a software delivery centre in India for nearly 5 years. He works as a freelance project engagement specialist and outsourcing consultant.