Managing Global Projects & What I’ve Learnt About Outsourcing
Thinking about what to write for this #PMFlashBlog I started recalling my first foray into the world of project management. I had been working for some years for a blue-chip organisation, designing and developing bespoke software systems for internal use. But as with many large organisations 10+ years ago they were considering outsourcing the IT functions to India and retaining a core of IT staff as project managers and technical specialists in the UK. I duly gained my PRINCE2 Practitioner qualification and became a project manager (or, at least, that’s what my title said).
But the whole process was far from a smooth ride; for a start most of the people re-assigned to a project manager role didn’t really want a PM role – they had been happy in their technical IT roles but since the whole organisation was moving towards outsourcing IT there was little option but to take a PM role or look elsewhere for another job.
So a new era started where I became “global project manager” managing projects and teams 5,000 miles away in India. People I had never met, who worked for a different company and had their own “local project manager”.
Of course, I knew the reason behind the changes was purely financial – I don’t know what the savings were but they must have been considerable for a multi-national organisation of over 300,000 employees at the time. Not that this was admitted as being the only reason to outsource – there was talk of efficiencies, economies of scale etc. etc.
Impact on Morale
As you can imagine there was some resentment to the whole process and it badly affected morale – for one because many of our colleagues were no longer in the company but also because we had lost that team spirit that had got us through many a late night and many a stressful software release. The very term management suggests that a manager knows or can get to know the people working for her/him; that a relationship can be built up so that trust can develop. A manager will learn to understand the team (in theory at least) and how to motivate the individuals.
But my role meant that all my dealings were with the “local project manager” – for quite a while I didn’t even know the names of my team members. It initially seemed that it was only me concerned about this but gradually other PMs started discussing various projects and forming the same opinion. We had to get to know the teams – to understand them and the cultural differences if we were to manage our projects successfully.
Perhaps, as with many project manager roles, I did not have enough support (let’s be honest, no support) from my superiors. It had been a money-saving decision to implement an outsourced arrangement and saving money was all they were concerned about.
But what happens when you only focus on one aspect of a project – in this case, the budget? Any experienced PM will tell you that something else will suffer. It could be the quality of the work or the timescales or both, as indeed it was in my case on that first project. I don’t know, maybe it wasn’t as bad as I thought at the time – in fact, the web-based system developed then is still in use today so it can’t have been all bad, but coming from a background where the users, the IT developers, the project managers and senior execs were all located in the same, albeit very large, building my focus then was on what was not right with the project rather than what was.
Successful project implementations
So how did the project get to the point where it was implemented “successfully”? It is a whole other topic, dear to my heart, of how you define project success; you can have documented success criteria that are met, a project that is on scope, on budget and on schedule but one that doesn’t actually meet the needs of the client at the point it is implemented – but that’s another discussion for another time.
Back to completing a project with a team on the other side of the world – one that I don’t know, and, therefore, don’t understand and don’t know how to motivate. The easy solution would be to get together – I could fly out to India (always wanted to go) and meet the team, that would not be too expensive (thinking about cost saving here) and surely lead to a better outcome. Well, I tried but it never happened – with hindsight the outsourcing company wanted to keep their clients, me included, at arm’s length and senior management in my organisation, thinking of the bottom line, could not be persuaded otherwise.
In the end I spent many an hour on the phone with the local PM building up a relationship with him, stressing the need for honest status updates (that came later, when I realised the cultural differences meant that any problems were not reported until they had become out of control). In fact, I like to think we both came to understand each other a lot better and came to trust each other. After all we both wanted that first project to be a success – after much in-house grumbling we had all realised that outsourcing was here to stay (at least for the foreseeable future) so that project and the others that followed had to be successful.
This groundwork ensured that when there were some real issues that were difficult to resolve and those difficulties were being exacerbated by my not being able to speak to the person doing the work, it was finally agreed that I could speak to someone at the coal-face – hurrah.
A learning experience
That first project was a learning experience for me, for the local project manager, for the project team and, in fact, the whole company. I wasn’t then, and still am not, a fan of outsourcing any work overseas because it creates too many barriers between those specifying and using the project deliverable and those doing the work to deliver the end result. Even if there were not language and cultural barriers, which there invariably are in global projects, just having disparate teams working in different time zones is enough to create barriers that foster a lack of understanding and trust from both sides.
Nevertheless, those early global projects certainly delivered on budget and as time went on they started to deliver on schedule, in part, due to estimation “techniques” being improved with experience (you know the sort of techniques where someone gives an estimate and you double it just in case). I’m still not convinced they ever delivered everything I would want regarding scope and quality but what project is ever perfect? Maybe good enough is all anyone can ever hope for?