Offshore lessons learned – feedback from our Jaipur unit

November 28, 2008 in lessons learned with Leave a Comment
Tags: Jaipur, lessons learned, outsourcing, project management

Although the Dutch team has been having many issues to control the one of our clients, the problems have been most visible for our Indian colleagues from Jaipur. This article sums up the problems, background and the possible solutions:

• Not enough time to read and response accordingly on specifications, the technical documentation can often be improved
  • Background:
    • the fact that this client is slow in procedural matters caused a lot of idle time, idle time means loss for us all
    • so we decided not to wait until final approvals and to start the development team before formal commercial and analysis procedures were finalized and accepted
  • how to improve:
    • the front office (NL) team always has to push formal procedures to be finished in time
    • but when not possible and if the development teams are requested to start earlier, then the situation should be explained
    • avoiding idle time is always a high priority as any hour not worked is a lost hour, money we cannot get back
    • the operational manager and team leader role should pro-actively check with the front office if commercial procedures have been finished

• Not enough time between the final specifications and the the delivery dates, often more work is added and planning should be shifted
  • Background:
    • the front office team often works with indicative plannings, these are used to indicate customers what is possible
    • but no planning can be final until the final specifications have been approved, clients also know that Componence can only commit on a deadline if the specifications are accepted
    • the front office team and the development team did not have crucial discussions upon the point when the specifications are accepted
  • how to improve:
    • The operational manager and team leader role should pro-actively know when the 1.0 version of the specifications will be submitted to the client for approval.
    • Within 2 days after the 1.0 version has been released, a conference call should be planned to discuss about the planning.
    • The project manager should not commit to final plannings until the operational manager and the team leader have commented on the planning.

• Not consistent communication front office and development team about the status of the project and latest developments
  • Background:
    • When it´s becomes a decision not to wait on formal procedures to avoid idle times, the crucial communication points in a project become less clear
    • Crucial moments are:
      1. when the project is formally approved
      2. when the specifications reach version 1.0
      3. when the specifications are accepted by the client
      4. when the final planning is committed (can only be AFTER point 3)
    • The lack of communication between the front office and the development teams will lead to problems in plannings and deliveries
  • How to improve:
    • The project manager, operational manager and the team leader must be aware when the formal procedures are not followed
    • Joint communication right after the crucial points mentioned above must be planned
    • The project manager must be aware of the risks in planning and must not forget that these problems will also leads to frustration and demotivation amongst the development team

• Not all documentation is available on wiki, leading to loss of development time
  • Background:
    • There is NO EXCUSE for this!
    • It caused 3 days of development for many developers, because some information about configuration of FAST was not available
  • How to improve:
    • Front office employees should make sure that all information is uploaded to the wiki!!!
    • Team leaders must check continuously before the development phase officially starts if all information has been uploaded to the wiki
    • If a development team gets stuck for 4 hours on an issue, escalate it!!!
      • Create a Jira issue with a question, assign the question back to the technical analyst who works at the front office
      • Team leader should escalate by writing an e-mail to the project manager referring to this issue in Jira and have the operational manager in the cc of the e-mail

Although Yonathan and I have just been here for the first morning, we could feel yesterday that the team had these issues in their mind. Although the team clearly stated they didn’t mind the hard work, it is our responsibility to control our client well.

The goal is that we all help each other to fulfill our promises to our clients, but like the front office has a duty to control the client, the leaders of the development team have the same duty to manage the front office. We all have to learn how we can manage our clients.

I’m interested to see if a group blog c …

November 1, 2008 in Uncategorized with Leave a Comment
Tags: blog, Componence

I’m interested to see if a group blog can improve the presence of Componence on the internet. Hopefully this is a way that will work for the different bloggers within the Componence network, to jointly write about Componence