Criteria for successful nearshore Projects

Questions for the client:

Do we want to cooperate long term with an external partner, do we meet all prerequisites, will we communicate the decision openly to our employees, will all involved employees support the cooperation ?

Are we ready and capable, to inform our future partner about our vision, targets and plans, and are we able to involve our partner wherever it is useful ?

Are we sure about a long term strategy, or is this just an opportunistic shortcut for a problem ?

Which targets: cost savings, covering of peak loads, covering of missing competences or resources ...?

Do we want

  • contacts at management levels ?
  • contacts between the project managers ?
  • ongoing (online-) communications and periodic face-to-face meetings ?

Which business model :

  • singular, isolated projects ?
  • ongoing development partnership for certain areas ?
  • a mixture of both ?
  • partner¡¦s employees required onsite ?

Cost:

are we able to identify all costs in order to objectively calculate the cost savings potential ?

About our own core competences:

  • how will these be affected by the offshoring plans, which ones will be transferred to the partner ?
  • effect to our company, our competitiveness and our employees ?
  • Over all, are we nearshore capable /ready ?
  • Questions to the partner
    • Does the partner understand our business, our targets and does he act accordingly ?
    • Does the assigned project team consider themselves as part of the customer and the projects¡¦ success as the top target ?
    • Has our partner already worked on similar projects or customers ?
    • Does he have formally employed specialists, what is their training requirement ?
    • Does he have to search for new hires or freelancers ?
    • How does he react to moving targets and requirements ?
    • Cultural and geographic proximity, language skills ?
    • Do we feel that communications so far have been clear and un-ambiguous, spontaneous, or did we have to inquire ?
    • Is this project suitable for nearshoring, have we selected the right partner ?
    Important criteria for Partner and Client: Risk

    Needs to be discussed openly, with what-if scenarios and problem escalations, and written agreements about these.

    Onsite- /Offshore Management

    Both client and partner need to name 1 each Project Manager, parallel communications between several specialists will only lead to misunderstandings and errors.

    An escalation path needs to be defined to the next level manager on both sides.

    Agreements need to be in place to escalate early, before serious problems arised.

    Commitment:

    The project will only be successful, and only then, if all involved employees want the success of the project.

    Important technical criteria:

    Target definition: functionality, time plan, budget, deliveries ...

    Responsibilities:

    who / what / when ... ?

    Organization:
    • naming of all team members on both sides, tel. no., mobile no. email/messaging/skype
    • precise documentation of requirements
    • precise documentation of agreed upon deliveries
    • project plans with milestones
    • test- and acceptance criteria (at the start of the project !)
    • Warranty agreement
    • Communications when/who/about
    Functional specification

    describes all functions as required by the user and will usually be provided by the client.

    Technical specification

    describes the technical implementation of the functional requirements and usually is provided by the development partner or in cooperation of partner and client.

    • Complete ?
    • Free of discrepancies and contradictions ?
        Statement of Work, SOW

        provides a detailed plan for all work steps and defines the development and test environment.

        This requires utmost care of both partners, as every forgotten or underestimated step will ultimately create delays and cost increases.

        The most important steps, to name a few: kick-off meeting, know-how transfer, development environment (hardware, software), architecture, design, programming techniques, milestones, documentation, test, QA, deliverables, standards , acceptance test, rollout, maintenance, road map, ...

        Planning and execution effort need to be in realistic ratio: a to short planning phase likely will create manifold implementation time and cost, to little test efforts will create problems at the acceptance test and, even worse, many problems in operation.

        Customer standards, almost never mentioned in functional requirements, need to be completely documented.

        Additional requirements or change requests (CRs), as arising during the implementation phase, need to be identified, quantified, documented and mutually agreed upon, also and explicitly for their cost and timing consequences. The author has never seen a fixed price project without any later CRs.

        Communications:

        The kick-off meeting is key for getting to know the other players and responsibilities. It should, whenever possible, be a personal meeting, and include the next higher manager from both sides.

        The exchange of all CVs always helps for a quick introduction.

        After that, and at least at reaching the next milestone, and for important events, regular scheduled meetings must be agreed, as well as reporting frequency, contents, author, and timing.

        Translated documents ought to be checked not only for grammatical correctness, but, and even much more important, for conveying the right message.

        For the client, a password-protected access to all relevant repositories needs to be provided.

        Deliverables:

        must be specified precisely: functional and technical descriptions, design, UML diagrams, source- and object code, user manual, installation notes, test results, ...

        Acceptance Test:

        Contents and deadlines need to be defined in the SOW.

        The development partner, as a minimum, needs to successfully perform all tests internally before the acceptance test is started. The attendance of a developer will permit to fix any problems in real time, and minimize any later rework.

        Rollout:

        All requirements for the rollout should be defined at the beginning, the rollout itself usually is within the responsibility of the client.

        Warranty:

        All warranty requirements due from the partner are to be pre-defined.

        What works / what not ? Pro
        • long term cooperation
        • Fixed price projects with a precisely defined, stable specification
        • T&M projects if targets and requirements may change
        • Projects with changing resource requirements
        •  
        • Labour-intense projects
        • Technology Research
        • Design
        • Coding
        • Documentation
        • Test
        • QA
        • 2nd level Support
        Contra
        • Short-term, opportunistic projects with high overhead for communications and know-how transfer
        • Fixed-price projects with incomplete or frequently changing specs.
        • Definition of Business Processes
        • Development of Graphic Artwork and CI
        • 1st level Support
        Questions ?

        If you would like to find out more about NearShore Solutions, its skills and capabilities, please contact:
        walter.fertl@nearshoresolutions.de

         NearShore Solutions GmbH ▪ Bretonischer Ring 12 ▪ D-85630 Grasbrunn   ▪ Germany

        Tel.: +49 89 800 32 780 ▪ Fax: +49 89 800 32 789
        info@nearshoresolutions.de   ▪ www.nearshoresolutions.de