[H-GEN] IT Funding Models

[Raymond Smith]

Hey Gaz!

On 24 October 2015 at 10:52, Gary Curtis <gazilla at gmail.com> wrote:

> I'm trying to get some ideas of the different IT funding models out there.
>

I have seen pretty much all of these. I am not quite sure what you mean by
"Did they work?" but I will have a stab.


> The Employment ones...
> 1. Annual Salary (fixed amount per year, no overtime)
> 2. Wage (fixed hourly rate, full hours + overtime)
> 3. Casual Wage (fixed rate, partial hours, no overtime)
>

I have only ever seen #1 and #2 (it was a salary + an on-call allowance).
I've only ever been employed under #1. I suspect #1 is the way most people
are employed. These work pretty well for all concerned. With the amount of
overtime most of the people in IT do, we would be better off working under
#2 or #3 but I think most of us work under #1. Probably because annual
salaries with no overtime are better for the employer.


> The Contract ones...
> 4. Hourly Rate (no project but with some guarantee of hours)
> 5. Day Rate (no project, length of day usually defined)
> 6. Like the above but with some other time period
>

I have never seen #6, I have seen plenty of #4 and #5. The "Day Rate" was a
very common option when I was contracting and is quite popular with people
who are interested in hiring Sarah. I found day-rates to be a nice
introduction to contracting for someone like me who had never been anything
but an employee before that, but they are somewhat limiting because you are
effectively an employee.


> The Project ones...
> 7. Fixed Quote (to implement a spec which already exists)
> 8. Fixed Quote + some payment to write/assist with spec
> 9. Estimate on rough spec, thence hourly/daily rate to implement
>

I have done a few projects along the lines of #7 and would never do it
again without a much more tightly controlled specification and a clear
statement of how warranty/maintenance is going to be handled. Basically
these two lessons come from two different projects:
- on one I had a technical customer, they had a high level spec, but they
also had some constraints that sounded reasonable but made it infeasible
for me to complete the work profitably. This problem was really not
apparent until I had commenced the project.
- on another project for a non-technical customer we discovered that
non-technical people really make no distinction between defects,
maintenance (eg recompiling for new OS), and enhancements. The initial
project was delivered just fine but the customer kept coming back for more
and more.

The alternative lesson you could take is that if you are going to take on
project based work then you need good project management skills.

I think in practice something like #8 is the only workable version of #7 -
#9. I think the best outcome for all would be when the customer turns up
with some starting specification and then you agree to work on that spec in
more detail either for a small fee or for free depending on your
competition.


> 10. Retainer + hourly/daily rate for new work
> 11. Maintenance contract
>

I have seen #11. There is an application in C that is used to control ATMs
and EFTPOS terminals around the country. It was written long ago, is
heavily customised for individual institutions, and is owned by A Company.
The only guy who really understands it has been semi-retired for years now
but has an arrangement with Company A that allows him to continue to
maintain the software for all the financial institutions. The weird thing
is that I don't know if Company A actually makes any money out of the
maintenance stream.

I could imagine this working well for legacy programs with low bus numbers
and a retiring workforce.


> 12. ????????
>

So three more models for you:

A. Piece-work using an 'odesk'/'freelancer' type model where people put out
requests and freelancers make bids.

At some level these are project based I suppose, but a lot of the work is
much lower level and not even really project based. I have seen work like
'I have an app written in Language X and I will pay USD$100.00 for each bug
that is fixed from my ticketing system' and I have seen 'I have a
cross-platform up that I need recompiled and tested on Windows'. Both of
these projects worked well from my outside perspective but they were very
tactical and probably not the way a lot of Australian developers would want
to work.

If I had to characterise it I would say piece work at a below-project
level. From what I have seen it works well if you can really define the
task down to the last degree -- but it quickly fails as ambiguity and value
go up. So "go through my mobile app and scale all the artwork to work with
the new hi-res displays" works well, but "write me a mobile app to do X"
tends to fail.

B. Bounties. I doubt may people live off bounties, but a lot of places have
some way to reward people who report security vulnerabilities or bugs.

C. Competitions / hakckathons. I haven't participated but there have been a
few of these where the customer has started with a problem and maybe some
technology and then had a hackathons where different people and teams try
to come up with ideas and prototypes to address the problem. Generally the
wining teams get some work out of it using one of your other models. This
is effectively getting someone to audition for the work.

I don't really know how successful these things are. The people involved
seem to enjoy them!

These may not be the way you are, or have been employed, but things you
> have seen. Did they work?
>

I think they all have their place. There is alway a tension between
customers wanting fixed-price and fixed-time and suppliers wanting to be
compensated for their time. I think whether any of these models works in
practice really depends on how well the model addresses the competing wants
of customers and suppliers.

Cheers,

Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.humbug.org.au/pipermail/general/attachments/20151024/5ae45fbd/attachment-0001.html>