The company I work for is looking to create a new version of their main software package, and wants to outsource the development to a local company. So far, so good. The non-technical project manager asked me for assistance (three months in), largely to ensure that he doesn't get the wool pulled over his eyes when discussing the technical elements.

However(!) firstly, there is no structure on our end to deal with creating a proposal to give to potential partners. There is the project manager, assisted to some degree by his technically minded, but busy father (also employed at the company) and an enthusiastic final year university student, and now, me.

Secondly, the project manager has produced a "Funtional Spec", influenced by his father, which deals largely with how the project should work (Django, jQuery, MySQL), and very little with what the project should do.

Thirdly, we've only entered negotiations with one company.

I feel that we should have a structure in place at our end dealing with roles and responsibilities, that we should have a proper requirements document that deals with the "what", rather than the "how", and that we should be speaking to a good number of other potential contractors. I also think that a functional spec, dealing with how the project should work and which technologies will be used should be produced by the (outsourced) developer; I think that these decisions should be the responsibility of the person who is responsible for implementing them.

How, in the real world, ideally, should this process work? Who should be producing the functional spec? Am I right to worry about the way this project is going?

Thanks all for taking the time!

2 Answers 2


It sounds like the project manager made the right choice in bringing you into the process.

I think you are right-on-track and should bring up those exact concerns and solutions to the project manager. Of course, you will be the person tasked with writing up those specifications and helping find the other contractors to talk to.

But I would view this as an opportunity and use it as such by making sure that senior management in the company knows about what you've proposed and how you're doing it.

You could accomplish this, perhaps, by offering to do a presentation in front of the project manager (and his father's) boss in order to help win support for the plan.

  • Mark, thank you for the response; I've brought up these points, and been met by resistance from the project manager; I think I can find my way through, largely with the track that you've proposed (ie, me doing it!) but I wanted to be sure that what I thought was correct was, in fact, correct!
    – Rufus
    Mar 2, 2011 at 14:31
  • 2
    @Rufus, if you are meeting some resistance, it sounds like there might be a little bit of pride at stake. Remind the PM of why he asked for your tech input, and make your suggestions in the context of protecting the PM and the team. You might have to fluff your PM and say things like, "you're ideas are great...in addition, maybe we should also consider X."
    – CraigV
    Mar 2, 2011 at 15:31
  • 1
    A approach to have Mark's and Craig's suggestions in place is 'adding' the what into the how spec. You'll eventually rebuild most of how, but you won't be positioned against the management, but on his side (as Craig suggested).
    – Tiago Cardoso
    Dec 8, 2011 at 15:10

Firstly, I fully agree that you should focus on "what" in the first place and then eventually go to "how." Btw: "how" doesn't have to be owned by a vendor - often companies set technology guidelines as they want to keep their infrastructure coherent.

Either way "how" should be a consequence of "what" and not the other way around.

Coming back to decide your "what" - you can approach the problem using one of a couple strategies (or mix them).

1. Up-front specifications

With this approach you basically try to write specifications covering all you needs. Usually more detailed means better here as it forces you to rethink specific needs. Also it leaves less place for interpretation later for both you and the vendor.

Actually the situation where you look for a replacement for existing solution is definitely an argument for choosing this path. However note that we basically never are able to define what we want in such precise manner that our requirements won't change over the course of the project. And that's where another approach kicks in...

2. Agile approach

With agile you assume you don't fully know what you're going to end up with. You set general goals which should be achieved by the project but you arrange details, including detailed specifications, during the project. Usually development is split to short, few-week-long iterations and at the beginning of each you see what is already done and you make arrangements what will be done during the sprint and set all the details needed for that. It's a kind of iterative planning - you don't try to write everything down up front, allowing yourself to make decisions later.

Since it looks like you don't have much prepared already in terms of specifying your requirements it might be an argument to choose this path. Note: usually it's much harder to sign reasonable agile contract which covers interests of both client and vendor side (if you want to learn more on the subject here's good presentation).

  • thank you for the in depth response, it's very much appreciated - both for backing me up to a good degree (which is reassuring!) and for giving me a broader perspective with the "agile approach" input
    – Rufus
    Mar 2, 2011 at 16:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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