3 September 2010

Offshore project management: how to manage your projectsOffshore project management: hoe uw projecten te managenOffshore project management: how to manage your projectsOffshore project management: how to manage your projects

About Hugo Messer

Hugo Messer is a Dutch entrepreneur, distributed agile team specialist, and author. He is the founder and owner of Bridge Global, a software services provider, and ekipa.co., an agile coaching agency. He has been building and managing teams around the world for the past several years. His passion is to enable people that are spread across cultures, geography and time zones to cooperate. Whether it’s offshoring or nearshoring, he knows what it takes to make global cooperation work.

9 thoughts on “Offshore project management: how to manage your projectsOffshore project management: hoe uw projecten te managenOffshore project management: how to manage your projectsOffshore project management: how to manage your projects
  1. Totally agree with the part that “Project Manager must have technical understanding”, Also you should keep check points like if you are stuck with a issue more then 3 hours then raise your hand….that’s how you can manage the risk easily.

    It is also good to have some monetary compensation for doing good job for e.g. to have things like best programmer of the month, who ever wins get 100 Euro you might find it strange but I will tell you in India people take pride in saying you were awarded for doing something good!

  2. Hugo en medelezers,

    Zover ik het engels schrijven goed begrepen heb knip ik het schrijven van Hugo in een paar stukken en reageer daarop.

    For years I have been trying to find the crucial aspects in offshore project management.
    In de basis is er geen projectmanagement verschil. Populair kan je zeggen dat projectmanagement bestaat uit denken, doen en sluiten. Het resultaat of doel en omgeving kunnen verschillen. Maar overeind blijft dat de stuurmiddelen en beheersing ervan goed voorbereid en een enige mate van volwassenheid moet hebben.
    In navolging op het model van Crosby, introduceerde Deming in 1986 een model voor het continue proces van verbetering voor kwaliteitsmanagement in een organisatie. Deming integreerde de ideeën van Crosby met de kwaliteitscirkel van Total Quality Management (TQM). Een volwassenheidsmodel begint met het indelen van de organisatie op een bepaald niveau. Deze niveaus lopen van 1 tot en met 5 op de schaal van Likert. De Likert-schaal is een schriftelijke methode om moeilijk te kwantificeren gegevens toch te kunnen ondervragen en te voorzien van een meetniveau. Niveau 1 geldt hierbij als minst volwassen. De meeste bedrijven zitten op dit niveau met soms een kleine vorm van standaardisatie. Het succes zit hem dan ook om projectorganisaties volwassen te maken en ze te begeleiden naar een excellent niveau.

    Both in managing our own projects (during the period we also did fixed price projects for our customers) and in observing how our customers are handling it. My simple conclusion is: it’s not easy for people who are new to it and it takes time and patience. Maybe patience is the key characteristic of the project manager that eventually makes offshoring work smooth. Het is belangrijk dat de projectmanager goede projectcompetenties te hebben en niet of hij/zij rustig is. In de techniek wordt gekozen op technische inhoud. Daar redeneren ze nog dat je pas auto kan rijden als je automonteur bent geweest. Ik ben geen automonteur maar kan prima autorijden. Ik beheers de processen om auto te kunnen rijden.

    The first ‘how to’ revolves around People. To manage your team effectively, you have to get the right people in your team. This may sound obvious, but in most offshoring cooperations, the project manager on the customer-side has no influence on this. Ook hier geld competenties, vakmanschap maar ook de juiste karaktereigenschappen in je team als basisvoorwaarde voor success. Elk mens heeft een + en – kant. Daartegenover moet je in het team een tegenpool hebben die e.e.a aanvult. Dit heet balans. Goede trainers hebben het over het as van het team en de balans erom heen. Het andere probleem is dat er geen goede projectorganisatie wordt opgezet met taken, rollen, bevoegdheden en verantwoordelijkheden. Dit is bijna altijd de basis van problemen op organisatorisch vlak, het maken van afspraken en communicatie. E.e.a is simpel op te lossen!!

    He gets the contact details of an account manager and a project manager on the supplier side, but programmers are kept ‘secret’ and are often even rotated based on the requirements of other projects (who on earth would do that you ask?…well, it happens more often than you’d even dream). Make sure your programming team members match your requirements in terms of skills in communication, coding quality, team work, analysis and personal skills. Idem Organisatieprobleem. Now in the ideal world with loads of time to prepare for cooperation, I would say the second most important is to establish a clear, effective Process. But I know that you want to get going, because you have an urgent project and you have to make a deadline. So the second how to in my opinion is: don’t focus on deadline and promises in terms of time and delivery, but focus on the technical problems. Allereerst dienen er beheersingsmechanisme te zijn die voorkomen dat er problemen komen. Daarnaast kan gewerkt worden met marges om niet direct in de problemen te komen. Maar ga nooit je focussen op de techniek maar zorg ook voor procesbeheersing en risicomanagement.

    If a programmer creates a delay in your project, your natural inclination is to conclude that offshoring is too complex and the programmer is not good enough. You start asking the programmer and maybe also the project manager ‘when will you deliver?!’ > They will tell you ‘don’t worry, tomorrow it’s ready’ and of course tomorrow it’s not ready. = Competentie, beheersing en organisatie issue

    The secret is: I have not met many project managers who showed different behavior, they all get frustrated and start blaming the programmer. Perfectly normal behavior. In my experience, when a programmer creates delay, it means he got stuck somewhere. And programmers have a pride in their work: they always think that they can solve the issue in the next hour, even in reality it might take them a few days. . = Competentie, beheersing en organisatie issue

    As a project manager, you have to find out the exact (technical) details of where the programmer got stuck. Drill down just as long as you have a complete understanding of the problem and then involve someone to help him out. . = Competentie, beheersing en organisatie issue

    Don’t stress him out with pushing for the deadline, it will have a reverse impact (more bugs because of time pressure, leading to even more frustration on your side). Manage on helping the programmer solve his problems, don’t manage on time and deadline only (of course you want to make that deadline, so does the programmer… there are more roads leading to finishing your project). . = Competentie, beheersing en organisatie issue

    This second how to relates to another important question: should the project manager on customer side be a technically skilled person (maybe even a programmer) or a non-technical manager, who is apt at managing time and deadlines? My experience is that the best project manager understands technology. Ideally he can make code too, but at the minimum he should understand what the programmer is doing, he should know every detail of a functional and technical design and manage on the details of the project, not on the rough timelines. A non-technical project manager can’t help the programmers and won’t be able to solve serious problems. . = Competentie, beheersing en organisatie issue

    As third: Process. I have written about this in previous articles and will continue to do so, because I believe in general it’s the second most critical success factor in an offshoring context. And especially in the project management context. If you don’t have a step by step description of ‘how we work’, how will you and your team know what to do next? What to do if we face a problem, whom to consult, how to communicate about it? Write down any aspect of the cooperation and keep on adjusting your process descriptions until you have the perfect process for your situation. Dit heet procesmanagement. Integraal PM is hard nodig

  3. Hugo,

    Kan ik in het Nederlands reageren? Mijn Engels is niet zo goed om op goed niveau te reageren. Project/Programma management is wel mijn specialisme en zou graag inhoudelijk willen reageren.

    Persoonlijk

    • Academisch werk – en denkniveau
    • Meer dan 15 jaar ervaring als senior project/programmamanager en (QA) consultant
    • Certified PRINCE2 practioner
    • Certified IPMA projectassessor
    • IPMA B niveau
    • Master Projectmanagement
    • Brede affiniteit ICT en bedrijfsvoering (Business)
    • Grote passie voor project en programmamanagement
    • Leiderschap kwaliteit volgens MBTI ESTJ profiel. Zie http://estj.mbti.human-types.com
    • Goede kennis van actuele marktontwikkelingen op het gebied van informatie management
    • Competent voor de volgende vier typen projecten :conform specifications projecten, die zich vooral richten op interne projectefficiency, fitness for use projecten, waar de impact op de gebruiker centraal staat, fitness for purpose projecten, die zich richten op businesssucces. fitness for future projecten, die de organisatie voorbereiden op de toekomst.

    Naast de uitvoering ook in staat om een actieve bijdrage te leveren aan elke projectorganisatie voor project en programmamanagement verbetering. Denk bij een actieve bijdrage aan:

    • Project en programma performance
    • Het inrichten van project en programma organisaties CMMI 3 + niveau
    • Het inrichten van project en programma beheersingstechnieken.
    • Het inrichten van project/programma en subcontracting key performance indicatoren (KPI’s)
    • Het inrichten van goed issue/wijzigingsbeheer.
    • Een verlaging van de project en programma kosten (– 30%).
    • Het opzetten van adequate risicomanagement/workshops
    • Het opleiden en begeleiden van (ervaren) project en programmamanagers
    • Het opzetten en beoordelen van verschillende (EPC, Europese aanbesteding) projectcontracten
    • Het inzicht geven van de verschillende interfaces en benodigde specialisme (HRM)
    • Persoonlijk Opleiding Plan maken

    Technische ‘kennis’ door project/programma scope ervaringen
    CMMi,CRAMM, SAP MM/SD/Logistiek/Fico, ABAB, CRM Truston, ECM, Hummingbird, Div , DMS, RMS, Scanstraten,
    Workflowmanagement, SO, FO, AO, Oracle, Linux, Window, Wan/Lan, Unix, Microsoft NT, Wan/Lan, BAS, MS office, VMware,
    Printeraansturing, Backup, Swift, Life, Clearnet, Storage, ITIL service management ,Asset management, Rekencentra, QSM SLIM Estimate,Control,Data Manager en Metrics, Filenet P8 (workflowmanagement, contentmanagement en documentmanagement), Front, Middle en Backoffice.

    Vanuit Masteropleiding veranderingsmanagement, onderhandelen en conflicthantering, communicatie, ethiek, projectmanagement, organisatie en personeelsbeleid, projectleiderschap, projecten en financiën, projecten en kwaliteit (TQM/Deming, Lean Six sigma) , strategie, beleid en marketing.

    Nevenfuncties:
    Schrijft in vakbladen als Computable, ITSMF ITIL service management, Mailprofs, SOD, OD en Automatiseringsgids. Op dit moment schrijf ik met een journalist van Computable aan een boek.

    Groet,

    John

  4. Dag John,

    uiteraard mag dat. We hebben op ons blog ook Nederlandse reacties staan, dus daar kun je ook reageren. Ik kijk uit naar jouw visie!

    groet

    Hugo

  5. Great “How to” guide! People were, are and always (unless cyborgs be doing their job) will be crucial in viable outsourcing business relationships. To get to know your team is among the first steps customer side should take while engaging into outsourcing project. Not only project manager and team leader/system architect but other key stakeholders from providers side as on further steps effective communication and understanding of all participants will be the force that drives project to success.

    In Nearshoring this step might be easier as there are no long distances, different cultures and time-zone adjustments which inherent to traditional offshoring contracts. Further ability for customer’s project management to be present during project milestones is crucial as well.

    From the provider side it is a normal practice to send key team members to customer to delve into customer’s key activity, atmosphere and specifics on the initial steps. Such exchange can not only facilitate knowledge exchange needed for effective cooperation but interlink the teams to work as a one! Moreover such interconnection will eliminate the problem of staff secrecy and turnover.

  6. From 2002 untill 2007 I ran as PM for Progress Software offshoring IT projects. Many of them tended to be fixed price. Let put it this way, the first year we had a huge learning curve, after that it became a highly profitable business :) The crucial aspect is in slicing the project in such a way that it becomes digestable, plannable and contro-able.
    Meaning that we spend time on the project methodologie aswell as the software development methodologie. Regarding the project, more time was spend on the functional design (FD) and analysis then we did in non-offshore projects. The offshore team was asked to do on T&M a technical analysis based on this FD. This TA needed to be formally accepted by the analist/architect. Once completely correct, this would be the basis for a Fixed price offer. After the first two projects, where analist where confronted with their own pre-assumption, I thought I didnt need to write that down, it is so obivous (no it isnt!) the methode worked perfectly. Our offshore company we worked with was in Roemenia. It had two main positive aspect, culturally very close in it working mentality to the Dutch, just a little more obediant, so we had to be carefull always ask their opinion otherwise they would just start without having a real clue about what to achieve (and make something up or just leave it empty) and import to near in timezone, so getting a concall or even travelling was relatively easy experience.

  7. Landelijke discussie ‘mislukte ICT project 12 mijoen bij Justitie” Wijkt de ICT-sector af bij ‘mislukte projecten’ ten opzichte van andere sectoren?

    Als er gekeken wordt naar de verschillende soorten projecten en de vraag ‘in hoeverre de ICT-sector hierin afwijkt ’ dan rijst de vraag of projecten te classificeren zijn. Dat blijkt mogelijk. Er zijn namelijk twee variabelen die in ieder type of soort project te herkennen zijn. Enerzijds spreekt men van projecten waar het ‘doel’ of ‘product’ duidelijk, of juist onduidelijk, gedefinieerd is. Anderzijds zijn binnen projecten de ‘methoden van werken’ of ‘processen’ duidelijk, of juist onduidelijk.

    Om een onderscheid te kunnen maken tussen de verschillende typen projecten kan je een indeling maken op basis van methoden en duidelijk gedefinieerde doelen. Het principe achter deze indeling is dat je deze punten als onderdeel van vele ander essentiële meetpunten kan gebruiken om de kans te berekenen of een project het beoogde resultaat of gewenste effect kan halen. M.a.w. hoe beter de methoden en de doelen gedefinieerd en volwassen zijn des te groter is de kans op voorspelbaarsucces. De volgende meest voorkomende type projecten zijn dan als volgt beschreven of te classificeren:

    Research en Cultuurverandering (methoden goed gedefinieerd, doelen niet)
    Dit zijn projecten waarbij de eisen en wensen van de gebruiker niet of nauwelijks
    concreet vast te leggen zijn. Deze moeten gedurende het project ontstaan.De projecten zijn tactisch of operationeel van aard en bij de start functie gericht. Ook bij dit type project is de betrokkenheid van de gebruiker beperkt. De uitvoering is voornamelijk in handen van specialisten. Een technisch georiënteerde aanpak gaat altijd ten koste van proces denken. De techneuten doen het project zonder de gebruiker erbij te betrekken. Met een groot risico dat een resultaat wordt opgeleverd waar de gebruiker niet blij mee is en niet wil accepteren of gebruiken. Hiermee valt het project (buiten de tijd en geld overschrijdingen) in de categorie mislukt. Het gewenste effect zal niet gehaald worden.

    Product ontwikkelprojecten (doelen goed gedefinieerd, methoden niet)
    In dit type project is het doel goed gedefinieerd maar hoe dat doel te bereiken is vaak
    niet duidelijk. Hierbij kan gedacht worden aan product ontwikkelingsprojecten die veelal
    multidisciplinair worden uitgevoerd. De doorlooptijd is een prioriteit omdat de ‘time to
    market’ bepalend is wat het project onder druk zet. Omdat er veel onzekerheden zijn over de methode van aanpak hebben deze projecten meestal eerst een functie gerichte aanpak. Dit soort projecten zullen door tijdsdruk concessies doen aan kwaliteit. Het doen van concessies in combinatie de vele onzekerheden leiden vaak tot overschrijding van de afgesproken tijd en de daaraan gekoppelde kosten. Ook voldoet het eindresultaat niet aan de klant verwachtingen. Het wordt niet geaccepteerd. Het project is daarom niet geslaagd. Het gewenste effect zal niet gehaald worden.

    Systeem ontwikkeling (methoden en doelen niet goed gedefinieerd)
    Kenmerkend voor dit soort projecten is dat er veel onzekerheden zijn: de ervaring met
    de uit te voeren werkzaamheden ontbreekt en de consequenties van de risico’s zijn
    groot. Deze projecten laten zich slecht plannen en worden daarom vaak fase voor fase in detail uitgewerkt en gepland. De complexiteit is zeer hoog omdat soms nog vage ideeën concrete resultaten dienen op te leveren. Gezien de grote impact voor de gebruiker is zijn betrokkenheid het gehele project noodzakelijk. Dit is vooral herkenbaar in Research & Development projecten. De projectorganisatie en gebruikers moeten als het ware samen op pad om het gewenste resultaat te bereiken. Dit type project valt in een hoog categorie gehalte van mislukte projecten. De kans op slagen en om binnen de stuur kaders van scope, tijd, geld en kwaliteit te blijven is nihil.

    Bouw en Engineering (doelen en methoden goed gedefinieerd)
    Engineering en Bouwprojecten zijn voornamelijk operationele projecten en worden ook wel klassieke projecten genoemd. Het zijn projecten met bekende aspecten die gestructureerd en volgens een vast stramien worden uitgevoerd.De projecten zijn over het algemeen product georiënteerd en de projectmedewerkers zijn door herhaling gespecialiseerd in dit werk. Er zijn daardoor weinig onzekerheden en doordat de werkzaamheden al vaker zijn uitgevoerd is er een gedegen ervaring op basis waarvan de planning tot in de details van tevoren gemaakt kan worden. Ook zijn eventuele risico’s qua kans en consequentie goed in te schatten en in te plannen. Vanwege veel routinematig werk kan dan bij andere methoden geconcentreerd worden op efficiënt werken. Deze projecten hebben de grootste kans op succes.

    Conclusie of antwoordt op de vraag ‘in hoeverre de ICT-sector afwijkt’
    Dan rijst het antwoordt op die vraag met een ‘nee’. Het managen van projecten is in essentie gelijk ongeacht de sector waarin het project wordt uitgevoerd. In de praktijk blijkt wel dat het per sector dat projecten verschillend worden ingevuld. Zo verschilt de invulling van projectmanagement in de bouw met die van de IT sector of die van cultuur projecten. Ook verschilt de inrichting en aansturing van grote en kleine projecten of tussen mono disciplinaire en multidisciplinaire projecten. In alle gevallen is echter het basis proces schema gelijk.

    De oorzaak van project falen ligt (op basis van onderzoek) ook op: een niet realistische en maakbare business case, onvolwassen project organisaties, het ontbreken van veranderingsmanagement, niet methodisch werken en niet in staat zijn om e.e.a te beheersen en samen te vatten in een waterdicht contract.

    John Roos
    06 81430098

  8. Pingback: If offshoring doesn’t provide the desired results, what do you focus on? | Bridge-Blog

Leave a Reply

Your email address will not be published.