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
For years I have been trying to find the crucial aspects in offshore project management. 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.
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.
Jarenlang probeer ik al de cruciale aspecten in offshore project management te vinden. Zowel in onze eigen projecten (in de periode dat we ook vaste prijs projecten deden voor onze klanten) en in het observeren van onze klanten die ermee te maken hebben. Mijn simpele conclusie is: het is niet makkelijk voor mensen die er niet bekend mee zijn en het vergt tijd en geduld. Misschien is geduld wel de belangrijkste karaktereigenschap die een project manager moet hebben zodat offshoring vlot verloopt.
For years I have been trying to find the crucial aspects in offshore project management. 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.
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.
For years I have been trying to find the crucial aspects in offshore project management. 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.
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.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.
De eerste ‘hoe’ gaat om Mensen. Om uw team effectief te managen moet u de juiste mensen in uw team hebben. Dit lijkt misschien vanzelfsprekend, maar in offshore samenwerking heeft de projectmanager aan de kant van de klant hier geen invloed op. Hij krijgt de details van een account manager en een projectmanager aan de kant van de aanbieder maar programmeurs worden ‘geheim gehouden’ en roteren vaak op basis van de vereisten van andere projecten. Zorg ervoor dat uw programmerende teamleden uw vereisten kunnen verwezenlijken met betrekking tot vaardigheden in communicatie, codering kwaliteit, teamwork, analyse en persoonlijke vaardigheden.
In een ideale wereld waar er veel tijd is om voor te bereiden zou ik zeggen dat het tweede belangrijke punt is het realiseren van een duidelijk en effectief Proces. Maar ik weet dat u wil beginnen omdat u een urgent project heeft en een deadline die u moet halen. Dus de tweede ‘hoe’ is mijns inziens: focus niet op een deadline en beloften van tijd en bezorgen, maar op technische problemen. Als een programmeur zorgt voor vertraging in uw project is uw natuurlijke reactie te concluderen dat offshoring te complex is en dat de programmeur niet goed genoeg is. U vraagt de programmeur en misschien ook de projectmanager ‘wanneer is het klaar?!’ Ze zullen u zeggen dat u zich geen zorgen moet maken en dat het ‘morgen klaar is’, maar natuurlijk is dat niet zo. Het geheim is: Ik heb niet veel projectmanager ontmoet die ander gedrag vertoonden, ze worden allemaal gefrustreerd en geven de programmeur de schuld. Heel normaal gedrag. Mijn ervaring leert dat als een programmeur voor vertraging zorgt betekent het dat hij ergens anders vast zit. Programmeurs zijn trots op hun werk: ze denken altijd dat ze het probleem binnen een uur op kunnen lossen terwijl het ze eigenlijk meer dan een dag kost. Als projectmanager moet u de exacte (technische) details uitvinden van waar de programmeur vast kwam te zitten. Blijf net zo lang zoeken tot u een compleet beeld van het probleem heeft en haal er dan iemand bij die hem kan helpen. Zorg niet voor meer stress bij hem door hem te pushen voor de deadline, dit heeft het tegenovergestelde effect (meer bugs door tijdsdruk, en dus nog meer frustratie voor u). Manage de programmeur door hem te helpen zijn problemen op te lossen, manage niet alleen tijd en deadlines (natuurlijk wilt u de deadline halen, maar dat wil de programmeur ook … er leiden meer wegen naar Rome).
Deze tweede ‘hoe’ heeft te maken met een andere belangrijke vraag: moet de projectmanager aan de kant van de klant een technisch vaardige persoon zijn (misschien zelfs een programmeur) of niet, en moet hij goed zijn in het managen van tijd en deadlines? Mijn ervaring leert dat de beste projectmanager technologie begrijpt. Als hij ook codes kan schrijven is dat helemaal ideaal, maar hij moet wel enig idee hebben van wat de programmeur doet. Hij moet elk detail van een functioneel en technisch ontwerp weten en de details van het project managen, niet de ruwe tijdsspan. Een niet-technische projectmanager kan de programmeurs niet helpen en kan dus serieuze problemen niet oplossen.
Als derde: Proces. Ik heb hierover geschreven in voorgaande artikelen en zal dit ook blijven doen omdat ik denk dat het over het algemeen de meest belangrijke succesfactor in offshoring is. En vooral in het geval van een projectmanager. Als u geen gedocumenteerd stappenplan van de manier van werken heeft, hoe weet u en uw team dan wat er gedaan moet worden? Als er een probleem is, naar wie gaan we dan toe en hoe communiceren we erover? Schrijf alle aspecten van de samenwerking op en blijf dit document aanpassen totdat u het perfecte proces voor uw situatie heeft.
Bridge heeft veel ervaring met het succesvol maken van een offshore samenwerking. We proberen onze kennis te gebruiken om onze klanten te helpen meer groei en winst te realiseren. Als u meer wilt weten over hoe uw offshore project te managen, neem dan contact op met één van onze kantoren bij u in de buurt.
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.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.
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. 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. 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. 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. 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).
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.
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.
Bridge has extensive experience in making offshore cooperations successful. We try to use our knowledge to help our customers achieve more growth and more profit. If you want to know more about how to manage your offshore project, feel free to contact one of our offices near to you.
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. 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. 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. 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. 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).
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.
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.
Bridge has extensive experience in making offshore cooperations successful. We try to use our knowledge to help our customers achieve more growth and more profit. If you want to know more about how to manage your offshore project, feel free to contact one of our offices near to you.
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. 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. 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. 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. 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).
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.
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.
Bridge has extensive experience in making offshore cooperations successful. We try to use our knowledge to help our customers achieve more growth and more profit. If you want to know more about how to manage your offshore project, feel free to contact one of our offices near to you.
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.
View all posts by Hugo Messer →
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!
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
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
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
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.
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.
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
Pingback: If offshoring doesn’t provide the desired results, what do you focus on? | Bridge-Blog
Within the top ten of my favorite posts, thankyou!