Newsletter [2]

Recently I was assigned as a PM (Project Manager) for an outsourced software development project for my organization, this project went through lots of issues and finished with a medium success but ironically you can learn more from less successful project than highly successful ones.

Everything started very “cool and shiny”. The contractor showed high enthusiasm to take the project and finish it on-time, on-budget (it was fixed cost fee, so it was in the contractor's best interest to finish in-budget) and with the expected quality.

The project started with a long list of identified risks:

• The new set of technologies were going to be used in our organization and also by the contractor.
• The new business model was going to be used by the contractor. Only business analysts and the PM from the contactor's side would be onsite and the rest of the team including the architect would be offshore. See the model below:
  
  
  
• The contractor wanted to reduce the cost so the team assigned didn't have proven experience in such used technologies.
• The project itself contained some highly complex business processes interacting in a way that was unclear from the already defined requirements document plus being rapidly changed.
• One of the main user representatives who owned high knowledge of the business left the team early.

Although of the above challenges we accepted continued to impact the completion of this project, the main risk was our outsourcing contract conditions which was almost like that "take these requirements document plus “X” amount of money and in return give me a piece of software".

We tried to work with such harsh conditions by creating a risk response plan for each identified risk and also trying different approaches to achieve our target such as:

• Involve a scope management technique aiming to negotiate with the contractor/user representatives to drop some less prioritized requirements and in return update others according to users needs involving different negotiations strategies.
• Re-prioritize requirements
• Give more clarification of some requirements using independent documents we called "light weight specifications"
• Get help from experts outside the team by involving them in reviews for code/design, peer reviews, and technical discussions.
• Always keep PMO (Project Management Office) aware about different risks and project state, asking their involvement in some cases.
• Lobby for co-location of some of the core team members (unfortunately this didn't work so well)
• Apply some team building techniques.
• Always refer back to contract documentation in case of any conflict.
• Create and update an issue log tracking every case and solution plus a separate record for lessons learned
• Try agilizing the construction process to get quicker feedback from end users and discover problems before growing bigger (unfortunately this wasn't accepted by the contractor as the contract didn't give us the right to change/audit their development engineering process).
• Create a weekly status report defining planned work packages, completed work packages, updated list of the risks and late actions by keeping close eye on the planned schedule and raise this report to PMO

The above described software project is a perfect example of problems which could arise from outsourcing without having good control of the contract conditions nor what is happening overall. If I had been the one to initiate this project (unfortunately I wasn’t), I would have replaced outsourcing with smart souring and my main tips to achieve smart sourcing are:

• Create an architecture group in your organization
  This architecture group should have the authority to check, approve/disapprove or change the system architecture. This group can meet whenever necessary to discuss new projects’ architectures or any changes to it and should be composed of skilled architects in your organization. Don't forget to mention that in your outsourcing contract.
  
  
• QA (Quality Assurance) before QC (Quality Check)
  Always keep a condition in your outsourcing contract that you have the right to audit the engineering process used by your contractor (whether you request to use a well-defined one by your organization or leave it to the contractor's to use his). Don’t wait until delivery to check the quality of the product.
  
  
• System Architect on-site
  By any means try to have the system architect on-site and mention that also in your contract as you will need frequently to engage him in several technical meetings/discussions with your in-house team.
  
  
• Business process improvement
  You have a wealth of data already in your organization from previous projects. Use this data and plan process improvement in your project.
  
  
• Interview every team member in the outsourcing company
  Conducting a15 minute interview with every team member before the start of the project would save you a lot later. Don't depend on fancy CVs. Additionally, it helps to build good relations with your team members.
  
  
• Use your system models for go/no go decisions
  Before each phase/iteration, check your models with your architectural group and make a conclusion for Go/No Go. This will help tremendously to not build something and destroy it later.
  
  
• Use the contract type which suits your case
  There are different contract types you can use in your project (fixed price, cost plus incentive, cost plus fee, etc.). Discuss them with your contractor officer (or manager if no contractor officer exists) and see what would be best suited for your project. Think out of the box. Your project could be partially outsourced, the system architect could come from your team, the contractor could provide just the development labor, etc.

© 2010 allPM.com

Amr Elshekh, PMP Has been leading projects for 6 years and solution architect for other 4 years mainly in large international organizations as World Health Organization and International Atomic Energy Agency, his project management experience covers numerous IT projects specializing in company-wide systems implementation, Amr holds a BSc in information technology and MSc in computer networks, He is also a member of PMI, Amr.elshekh@theglobalfund.org [3]