5

We are going to outsource a project to an outsourcing website. I am going to be talking to a few of them today.

I have done this once before but that was a miserable failure and the project never got done, we only got excuses.

I know to ask them about the project specifically, go into detail about it. What questions do I need to make sure I cover before I hire someone?

I know I need to ask or state the following so far, what am I missing:

  • Require source code when project is release
  • Clearly documented/noted in source code = JavaScript, ASP.NET, and c# are the only languages to be used, any others are to be okayed by me
  • 1 week requirement
  • .NET 4.0+
  • Unit testing required

I already created the scope of the project, I'm covering my bases with the follow up questions when I talk to them. They should already have an idea what I'm looking for.

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
ErocM
  • 153
  • 3
  • 1
    Hi ErocM, welcome to PMSE! Your question, as it stands now, even after J's edit seems to me still too broad. J focused on the questions to be done while picking up someone to work on the project, but I'd say your question goes beyond the hiring process. Besides, you mention your previous experience failed, and I'd say would be good to pinpoint the reasons it failed. It could give you important clues to avoid this time, no? – Tiago Cardoso May 26 '13 at 17:50

4 Answers4

7

Focus on Project Control

Your entire question is based on a faulty premise, e.g. that specifications and contractual requirements are equivalent to process or quality control. They are not.

What you need to define for any project, whether it's in-sourced or out-sourced, is a set of project controls that allow you to continuously inspect your project and appropriately manage deviations from the project plan.

Setting Expectations

You are setting yourself up for failure with this statement:

They should already have an idea what I'm looking for.

Mind-reading is, I suppose, a desirable project control, but I've rarely seen telepathy work well as a communications channel. If you have expectations, set them explicitly and document them.

Not only should you be explicit about what the expectations are, but you should also be explicit about how you plan to measure how well your expectations are being met along the way. If you can't articulate those things clearly at the outset, then the project is very likely to slip off the rails before it even starts.

Defining "A Good Fit"

A good fit is a team that can achieve your technical specifications, has the appropriate skill set and knowledge to complete the project at an acceptable level of quality, and (most importantly) is both willing and able to work within the constraints of your project management controls. If they are a poor fit for the last item, the first two don't really matter.

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
1

Documentation of requirements should ideally be collaborative between business users and developers. In my experience if they know what they are doing they will ask you for good quality requirements, and will ask questions proactively when they don't have the info they need.

So find out what format/template they provide to their developers and review that for types of content, level of detail, clarity, etc. Use this as guidance for developing your requirements when obtaining costs etc and for inclusion in the contract as part of the SOW.

If they don't have a template or can't provide guidance they likely aren't very well organized. If you'd still like to give them a chance go back to your files and find a set of requirements from a project that succeeded and go with that rather than try to reinvent the wheel.

If you want to be ruthless you could include a logical inconsistency, or something they obviouly could not do, in your initial scope and see if they spot it. That would go towards demonstrating their attention to detail and real understanding of what you want done.

Doug B
  • 8,899
  • 17
  • 40
0

Ask them about their past projects. Find out how they accomplished their tasks for previous clients. Were there any obstacles or challenges while they were doing the projects? What were they and how did they go about solving these issues? Pay close attention to past projects that are similar to the tasks that you are planning to outsource so you’ll have a good idea of the outsourcing company’s capacity to handle the tasks that you need to get done.

Aziz Shaikh
  • 3,217
  • 24
  • 40
Begonia Ione
  • 1
  • 1
0

Apart from what has been mentioned above, below are my 2 cents

In the SOW you can mention SLAs. SLAs could be like

  • Number of defects delivered in every stage (i.e UAT, Production)
  • Number FPs (function points) delivered per day/month/release
  • Defect density

This will make the engagement more objective.

Also mandate that the vendor has to maintain logs of code reviews, unit testing and use a standard version control.

ViSu
  • 321
  • 1
  • 9
  • This all assumes that OP is in a position to produce realistic estimates of any of the metrics. In which case they'd have a sufficiently mature software capability that outsource would be insensical. It also assumes that contractors won't just flat out lie about their ability, or about the current metrics. Finally, it throws the cost of QA back onto OP. – Jacques Chester Aug 20 '13 at 01:20