How to Purchase a Database

-Chris-

I'm not sure if this is better suited here or in one of the Business forums, but hopefully someone can help.

A friend of mine has asked for my opinion on how to purchase or develop a fleet management database.

The system would be Enterprise level, supporting 60+ users in an Irish company. It would handle vehicle quotations (purchase, leasing & maintenance), vehicle service history management, invoicing, disposal, etc. etc. It's a fairly large undertaking.

At the moment they're looking at the options regarding purchasing an off-the-shelf option versus having a bespoke system developed. They have set up meetings with the off-the-shelf suppliers and are getting demos and quotes.

Can anyone suggest where they'd go to find developers who would spec and quote for the bespoke system? Are there any really good design & development people/companies out there that could be recommended?

Any feedback with regard to the process they should be using, and the questions they should be asking, when assessing developers?

Cheers!

jimmycrackcorm

Don't get a totally bespoke system developed as it is risky and expensive unless you commit totally to an Agile approach. Instead ideally look for an existing product that is a partial fit but with customizability. The problem with getting design and development people to spec and quote is that it is fundamentally flawed as proven by the industry statistic that over 80% of IT projects fail.

ocallagh

jimmycrackcorm wrote: »

industry statistic that over 80% of IT projects fail.

Interesting stat, but could be mis-quoted easily. Is it the business that fails or the software? I find it hard t believe 80% of software written is junk

OREGATO

I think it would be a case that the system fails as opposed to the business, I would count that some of them projects in that category are ones that haven't even gone live or gotten off the ground.

I would think that getting an off the shelf and proven system would be the best. If the company was to embark on the task itself, it can get quite risky when, say there is only one developer working on it, if s/he leaves, then you're going to get someone else taking over the code etc, you can end up in a situation where you have little pools of software developed and it would be a management/development nightmare picking up the pieces. I've seen this happen far too often!

TheWaterboy

Hi Chris - I used to work in a company in that develops software for the Haulage industry - If you want an introduction and quote from them send me a PM and I can contact them

fergalr

jimmycrackcorm wrote: »

Don't get a totally bespoke system developed as it is risky and expensive unless you commit totally to an Agile approach.

?
I'm sure it'd still be risky and expensive!

dazberry

ocallagh wrote: »

Interesting stat, but could be mis-quoted easily. Is it the business that fails or the software? I find it hard t believe 80% of software written is junk

Fail is used in the context of being late, and/or over budget, and/or missing functionality, all the way up to being cancelled altogether. A lot of software projects are doomed to failure before the first line of code is ever written...

D.

fergalr

dazberry wrote: »

Fail is used in the context of being late, and/or over budget, and/or missing functionality, all the way up to being cancelled altogether. A lot of software projects are doomed to failure before the first line of code is ever written...

D.

If a project was 1% late (or even 5%), but otherwise worked, I think people would be surprised to find that counted as a 'fail'.

I understand that in a strict sense, it can be considered to fail, but I'm not sure thats a helpful definition for a discussion like this.


To expand on this idea, before a project is undertaken, there is going to be some uncertainty, about certain aspects of the scheduling.
Its just fundamental, that the people doing the project will be be missing some information. Or, maybe the lead architect gets hit by a bus.

As such, there's always a risk, to any schedule.
So, when estimating the project schedule, what do you quote? The completion time you are 99% likely to make? (I.e. the only thing that will stop you is very outside chances - such as the bus)
I think it's a bad idea to quote such an estimate - the vast majority of the time, it'll be way too conservative!

So you maybe give the 80% estimate - you are very likely to finish before this deadline, and, depending on the probability distribution of finishing times, its probably not too much 'padded' from the 50% case, say.

But, then, consequently, you expect that 1 in 5 projects overrun the deadline you give, and are late.


So, what I'm really saying here is that I don't see 'lateness' as a problem in commercial software, if its only a little bit late - its more a natural consequence of the a priori uncertainty.


(For simplicity, I'm assuming above that the probability distribution of finishing times is known exactly, and that the penalties for slipping schedules are not severe - with uncertainty in these axes, it gets complex to reason about.

We'd want a completely different way of going about things if, for example, we were writing software to intercept an incoming asteroid, and any slippage to the agreed schedule was catastrophic - but that's not usually the case, in commercial software - e.g. people generally wouldn't pay 100 times the amount to have a 99.9999% chance of completion by the agreed date, vs. a 99% chance )

dazberry

fergalr wrote: »

If a project was 1% late (or even 5%), but otherwise worked, I think people would be surprised to find that counted as a 'fail'.

http://www.ibm.com/developerworks/websphere/library/techarticles/0306_perks/perks2.html

Most software projects fail. In fact, the Standish group reports that over 80% of projects are unsuccessful either because they are over budget, late, missing function, or a combination. Moreover, 30% of software projects are so poorly executed that they are canceled before completion.

I suspect fail is used in absolute terms, so to fulfill a statistic. In reality 1% (late, budget or functionality) may be irrelevant or may be disastrous, it really depends on the project.

... and don't forget the 4th factor, politics. I've seen projects very late, very over budget and very much lacking in functionality being lauded as major successes because it was politically beneficial to do so...

D.

Triangle

I would expect it would include all software failures. Alot of off the shelf packages do not end up meeting the sales pitch and are therefore destined to fail.

There are bespoke developers out there that could put together an entry level system fairly quick. I'd personally try the IDA and see if they know of a start up dev company looking to get their teeth into a project partly to build up a base of support.

fergalr

dazberry wrote: »

http://www.ibm.com/developerworks/websphere/library/techarticles/0306_perks/perks2.html


I suspect fail is used in absolute terms, so to fulfill a statistic. In reality 1% (late, budget or functionality) may be irrelevant or may be disastrous, it really depends on the project.

... and don't forget the 4th factor, politics. I've seen projects very late, very over budget and very much lacking in functionality being lauded as major successes because it was politically beneficial to do so...

D.

Ok, that link you gave, links to a 'Standish Group' report.
I find a free copy of the report, by googling, here: http://wwwkrcmar.in.tum.de/lehre\lv_materialien.nsf/intern01/2A150800E9774333C1256E6D00453F26/$FILE/chaos1994.pdf

I note that there is a quote from a Tom Clancy novel at the top - but lets not hold that against them!


I think it was written in 1994, which is some time ago, in software engineering terms.
The sample size is 365 responses, covering 8,380 separate projects, which is pretty big.
Its hard to tell if there was a selection bias to the sample, there might have been.

They describe 16.2% as successful, which seems to mean perfectly successful - so totally on time, in budget, etc.


They say that for the other projects, they have the following breakdown of time overruns:

"
Time Overruns % of Responses
Under 20% 13.9%
21 - 50% 18.3%
51 - 100% 20.0%
101 - 200% 35.5%
201 - 400% 11.2%
Over 400% 1.1"

Thats the important data.

This would seem to imply that all unsuccessful projects had at least some overrun - it'd have been nice if they broke out the number of unsuccessful projects with no time overrun, but they didn't - ok.

13% of unsuccessful projects completed in less than 1.2 times the scheduled time.
Cumulatively, 52% of unsuccessful projects completed in less than twice the time scheduled.


So, in a nutshell, they do appear to be considering any overrun to be a failure - I guess they are writing 'the chaos report' - but at the same time, the overruns aren't trivial - they are pretty bad.


It remains hard to know how to interpret the results; you point out politics - we don't know the culture in which the initial schedule estimate was given, and how seriously it was taken.

dazberry wrote: »

In reality 1% (late, budget or functionality) may be irrelevant or may be disastrous, it really depends on the project.

Absolutely - cat pictures website, vs asteroid interceptor, very different outcome.


OP: I guess this just goes to show, once again, software engineering, and scheduling is subtle stuff - treat it with caution, and treat any promises given by a developer - especially an inexperienced one - to build you X for price Y, with a grain of salt.

-Chris-

Cheers all, that's some great info - looks like a bespoke, from the ground up, system is possibly a serious can of worms!