2

To place in context, I made a document that went to tender where I stated the objectives and timeframe of the product, but because of an NDA I couldn't be explicit with a lot of it in case the potential tenderers saw a benefit of making it on their own.

That being said the product tender was awarded, I gave the tenderer with the details and they assured me they could do it. They are offshore.

I provide to the outsourcer the testing, validation and certification documents of each component before they started.

During the build, when I'd planned every component delivery of the turnkey product and I wanted to know what where they doing, they told me that they were doing great and that I should wait until the end of the week to see the demo and the results.

When I saw the first component and compared it to the expected, I knew I had to change the way they were working because we had lost possibly half of the week making the developers work on something different from what I expected on that delivery.

I wanted to be closer to the construction and offered my daily involvement, but they told me "that would be micromanagement".

I only wanted short interruptions and reports, however it's not my company, it's the outsourcer's, and I have no authority there to determine how should they work.

The other thing that is at stake here is that I don't want the project to fail because of poor management of the outsource. Nor do I want to take out the document where it states the terms and conditions of the service, thus eroding the relationship when 5 or 6 components are still to be completed.

The "we'll do it later" approach has not worked for me in the past, because "later" they will need extra budget to complete what was originally requested.

So, what how can I work effectively with this kind of outsource relationship?

  • 1
    Are they working on a fixed-price arrangement or Time & Materials (day-rate)? – Marv Mills Nov 13 '14 at 14:49
  • It's fixed price. Sorry for not explaining this. That's why the "we'll do it later" approach has not worked for me in the past. On a time & materials, time is just one of the occupational hazards. But when you go for fixed price... even then "take out the document" I don't see it as a solution – apacay Nov 13 '14 at 15:19
3

As it is a fixed-price arrangement I would expect that you have a payment plan or structure in place that means you pay most or all of the fees on acceptance of the finished product. Therefore you are somewhat covered here- if the third party does not produce acceptable work then you simply don't accept it and don't pay their fees.

The key to making this work, for both sides, is a clear and agreed specification for the work that they will do- you don't ask a builder to build a house without providing the plans and you shouldn't engage a software provider to create some software without providing the full and clear specification. It worries me that you have not actually used the word "specification" in your question - Did you provide one?

If you did not provide a specification then how can you explain to the third party what they have not delivered to expectation? You will get into a long and potentially damaging argument about what was expected versus what was delivered. You will say it is not what you expected, they will say it is what you told them - A specification would remove the grounds of this argument.

My advice would be to ensure you provide them with a specification of exactly what it required as quickly as possible, though you must be prepared for a revision to the cost as it will almost certainly be different in some respects to what they quoted for (else they would be delivering what you expected even without the spec).

If you did provide a specification then you need to test the output against that specification and then ensure you raise with the third party where their deliverable deviates from the agreed specification. They will then need to fix the product until it complies with the specification, at their cost, until you both agree the product delivers what the spec demands.

There should not be any issue with this, it is a basic principle of a fixed-price agreement. You may find, however, that if they have not been good at working to the spec then the product may deviate substantially from the spec and therefore require a lot of re-work, and therefore time, to put right. Depending on the product and your downstream business dependencies on the work your placed with them, this delay may cause you a serious issue. If this is going to the be the case you had better hope you have a time-related penalty clause in the contract that means they recompense you for the impact of significant delays. However, on the basis of what you have said so far, I am not hopeful this will be the case :) In software delivery, from both the client and the supplier side, every day is a school day!

Good luck!

  • thanks for your answer, the specification was not the only thing I've passed, but I also passed the "how we'll be testing and verificating if the work covers our demand" and also a document and code with the proposed architecture, which the outsource discarded without asking, since they thought It was easier to start over than ask. The outsource senior developer thought it would be better to deliver the core of every component instead of aligning with the component delivery expected. I know I can go on the not acceptable task but that's what I think will erode the relation. – apacay Nov 13 '14 at 18:52
  • I would also state that the details had to be provided after the tender was set and NDA from the outsource signed. And there's one issue, since the price had to be fixed before they saw the specifications... however they had to start after the specifications were given and I'm almost certain that in hopes of reducing time deliveries they've started before the kick off. – apacay Nov 13 '14 at 18:58
  • All common enough unfortunately, but you have a spec which they have agreed to deliver and if they are not doing that then, yes, the relationship might sour but that would be their fault not yours. In the end, just don't pay! – Marv Mills Nov 13 '14 at 19:02
2

Analysis

When I saw the first component and compared it to the expected, I knew I had to change the way they were working because we had lost possibly half of the week making the developers work on something different from what I expected on that delivery.

When you work with a third-party vendor, you can generally specify what will be provided and when it will be paid for, but cannot generally determine how they will perform the work internally.

While it sounds like you have provided acceptance criteria, no one but you and the vendor can determine the quality of the project documents or their fitness for purpose. It may be worth having a conversation about that; it is always conceivable that the specifications and acceptance criteria are not as useful to others as they are to the original author.

You also may have some unrealistic expectations of your engagement. If they are an agile shop, and you are paying on fixed price, then a few iterations to level-set the project are not out of line unless you've created a project timeline that has unrealistic deadlines or insufficient slack.

Recommendations

[H]ow can I work effectively with this kind of outsource relationship?

  1. Review the project plan with the vendor. You need to understand how they have structured the work on the project.
  2. Review your project documents with the vendor. Ensure that they have the same understanding of the requirements, specifications, or user stories that you do.
  3. If they are an agile shop, be prepared to engage with them during defined inflection points such as Sprint Planning or Sprint Review rather than doing daily status pulls. Educating yourself on their project management framework may help you work with them more successfully during these inflection points.
  4. Make sure both you and the vendor have a shared understanding of the project delivery schedule. Be prepared to make changes in scope or quality if the price and schedule are fixed.
  5. Actively manage the priority of the features you are asking them to deliver. In this way, you may be able to achieve a Minimum Viable Product even if your entire feature set is never completed.
  6. Make yourself available (as you have) to answer questions about specifications or scope, but ensure you allow them room to determine implementation details. Your focus should generally be on the usefulness of what is delivered, rather than on how it works internally.
  7. Give the vendor a reasonable period of time to demonstrate competence, or lack thereof. Three days into a long engagement is not sufficient time to determine success or failure for most real-world projects.
  8. If the project is failing to deliver sufficient value after a reasonable period of time (e.g. three to five iterations), pull the plug. Since 68% of IT projects fail, the key is to fail early enough to conserve capital.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.