First as an intro, I am not technical! meaning I do not program :-) although I can and have provided a detailed requirement documant it "seems" to me that the programmers are taking too long to produce the desired s/w
First, I would like suggestions how is it best to know if they are on track.
Secondly, how long does it take for example to program (in PHP) a QA module like this one?
Thanks for the help.
It takes a lot of time and you can't just make a estimate out of nothing like that. You can make in 1 day something that resembles this template, but all the features you see on this site can take months or years.
My first question is why do you think you are more qualified than they to estimate how long something will take. You proudly profess your inexperience in the area but then somehow you know better. Please don't take offence. It's bad enough that developers get that from managers who should know better. Far worse from someone who freely admits their inexperience.
That said, there are ways to mitigate the chances that a job will run too far over time or budget. There should be numerous deliverables on the way and the job as a whole should be broken down into units small enough that you can track progress easily.
Sometimes that means no single task in the job should take more than, say, 5 days.
That way, if one task takes 15 days, you see a problem immediately and have the option of changing requirements, invoking penalty clauses, adding staff, firing the idiots who quoted and so on. All this in a timely fashion.
No job should be of the type "we'll deliver the finished product in four months" simply because you're likely to get to the four-month deadline and discover it's only half-done.
The other advantage that this confers is that it gives you more accurate TTC (time to completion) and CAC (cost at completion) figures. If you find that your developer is taking 20% longer on average with all the tasks, you can remain optimistic and still assume the remainder will be okay (in which case your TTC will be the work left and CAC will be the cost to date (20% over) plus TTC cost).
You can also assume they will be 20% over for the rest of the work as well, so TTC is 20% higher than estimate and CAC overall is 20% higher.
How you decide to estimate is not relevant. But it's the fact that you have hard data at hand which allows you to intelligently estimate work. And, if you've spent 50% of your budget and only 3% of the work is done, you have the nuclear option of cancelling the whole thing before it drains all your resources.
That's basic project management and has nothing to do specifically with IT. It applies everywhere where there's a lengthy effort to build some "product". Other things you can do are to tie progress payments to the deliverables themselves (and ensure the contract states that the deliverables have to meet the specs).
But this is all the stuff that should have happened before the work started. It may well do you no good in your current situation, although you could start insisting that some form of progress be shown or payments will be withheld (or the whole project cancelled). Provided you have that power, this will often convince the developers to play ball.
From Code: It's Trivial
Seems really pricey for a relatively simple software like this. Someone write an open source alternative? it looks like something that can be thrown together in a weekend.
This is no trivial task, and typically everything takes 1.5 to 2 times longer than you originally expect.
See also Let's Play Planning Poker!
One of the most challenging aspects of any software project is estimation-- determining how long the work will take. It's so difficult, some call it a black art.
if you want to build a complete rocksolid scalable architecture to support your QA-module, it will take more time than when you have already an architecture or when you are happy with some quick and dirty stuff
As for the time part: programming always takes more time than expected: http://stackoverflow.com/questions/58640/great-programming-quotes/58692#58692
It will take from 1 hour to 2 years depending on the features you'll need.
When you say that is seems that it is taking too long - one of the following is (hopefully) true.
a) You mean "the estimate seems to large"
OR
b) They have not delivered what they estimated
From your question, I think that there may be a c)...
c) No estimate was supplied in the first place
If no estimate was supplied in the first place, you could remedy the situation somewhat by getting them to estimate what work is remaining. It helps if the estimate is broken down into a number of tasks so you can measure progress and get an early indicator that things might take longer than estimated.
Estimates are not guarantees that work will take a certain amount of time, but simply an indication (some would say "guess"). The more estimates a developer provides, the better they'll get at it.
You will also have to think about whether you have added any new requirements after your document, which may have had a bearing on how long the development is taking.
Failing all of these... feel free to publish a copy of your document and I'll happily give you an indicative estimate.
The core of the problem is of a psychological nature. Since laymen mostly know nothing or less about the complexities of the technology involved, they are doomed to underestimate the needed time for a task. Let's say the time estimates correlate with the amount of thought space the task requires in your brain.
If all you can think is Q&A = Q + A = 2 things, you will arguably estimate much less time than if your brain immediately starts seeing all the little parts and bits and choices, server side and client side and styling and design and admin backend and protocol and compatibility and platform independence and i18n and storage and performance and dilemmas and you name it and what's more ...
If you doubt your programmers, ask them to be more transparent about their development process. They likely have something like burndown charts or story cards or use continuous integration servers to document their progress somehow.
Apart from this, be assured that there will always be some guys who can do the work of others in less time, with less cost, but also in less quality. There is four variables in project management: scope, time, cost and quality. You can fix two of the first three.
Hire a good Business Analyst and an Architect and then trust them. If you want to know how "good" is good; you can read this article from Joel Spolsky.
Have you read this: How projects fail?