T.R | Title | User | Personal Name | Date | Lines |
---|
2273.1 | Yes, work done in Britain on preparing this... | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Wed Feb 17 1993 09:06 | 15 |
| We investigated this in Britain. In fact we spent a week putting some
material together. Our conclusion was that we would offer a number of
packages, starting with a couple of fixed price services, one to run
the CART and analyse the report, and another to do a general
investigation into the health and customisation state of the system.
Based on these two surveys, we designed a number of other services,
mostly on a time and materials basis to actually do the upgrade,
including customisation migration and application programmer training.
Since money was spent on doing this work, I can't really give you the
full story. You might like to contact Julian Kempster @ UCG, who owned
the project and see what he felt about letting you have access to the
material.
Graham
|
2273.2 | two more questions... | CHGV04::JANES | DTN 474-5373 Packaged Services Development | Wed Feb 17 1993 16:15 | 30 |
| Graham,
> Since money was spent on doing this work, I can't really give you the
> full story.
I appreciate money spent and ensuring that an effort gets its due
return on investment. I hope the next couple of questions are generic
enough in nature that you can give a little more info without
compromising work already done.
1) What is the price and time effort for the CART and analysis services
that have been done in Britain? Since the US geography is fairly large
the chance that travel will be incurred in delivering these services
is very likely. As a result, my best guess for what we would have to
charge in the US for this service would be a minimum of $6,000-$7,000
for a weeks' effort. Is this in line with what you were charging?
2) You said that the CART service would then lead to T&M services for
doing the upgrade and customization migration. Is there any way
possbible to offer a "fixed-price" upgrade and customization that
meets the needs of all customers, and with T&M work being sold to
address upgrade and cusomization work beyond the basic "fixed-price"
service?
The reason I am asking for a "fixed-price" upgrade and customization
is because a request has been made to me to create a service offering
that is easy for Sales to quote and sell
Thanks for your help,
Lester
|
2273.3 | I can't see how this *can* be fixed price! | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Thu Feb 18 1993 08:52 | 28 |
| This is going to sound unhelpful...
I'm *just* an Engineer, and I don't get directly sold to customers (at
least not very often :-) ) so I don't understand pricing. I expect that
the UK prices wouldn't really tell you anything relative to the US
market anyway. I think the initial report and doing the CART run were
both one day services.
I would think that customer systems are so different that you couldn't
possibly fix a fixed price for migrating customisations, unless you
made it so high that you wouldn't ever catch a cold, in which case
you'd scare off half the business!
Our theory was that anyone delivering these services was used to doing
variable time span consultancy, and could use the initial report, which
might be done by a more junior person following a check list, to
accurately specify the final price.
We know of systems that have from zero to hundreds, possibly thousands
of files customised, and systems that are from vanilla to having dozens
of layered products installed. I can't see how you can possibly make a
single price for handling that sort of thing.
You should contact Julian, who I fingered in .1 for more info, maybe
he'll agree to some of our material, e.g. the service descriptions,
being posted. I don't have the rights to it.
Graham
|
2273.4 | depends on various parameters | BERN02::MUELLERS | Stefan A. M�ller DTN 761-4864 | Thu Feb 18 1993 14:20 | 17 |
| Hi,
> ...offer a "fixed-price" upgrade and customization that
> meets the needs of all customers, ...
The time needed to do the variuos things depends on different parameters
(cpu, disks, number of customizations etc). This makes it difficult to offer a
fixed price that meets all customers needs. Doing so some customers would pay
too much some too less. Clever customers only pay for this service if it's
cheaper than an individual offer.
After evaluating this possibility we offer a couple of days to the customer. If
not all the time will be needed for the upgrade, the customer may get other
services for the remaining time. For SUIS customers it's essential to show them
what will be covered by the contract and for what they have to pay.
Stefan
|
2273.5 | I know a little about the CART ;-) | SIOG::T_REDMOND | Thoughts of an Idle Mind | Sun Feb 21 1993 15:31 | 63 |
| I have recently spent some time with a customer helping them to analyze
their CART reports and fixing some of the problems. In a single day I
was able to:
-- Look over a customized system that had > 600 elements registered in
CM.
-- Delete over 100 of these elements, because they were either obsolete
or had been created by programmers "trying things out"
-- Review the site elements report and identify "rogue" elements listed
there. Get a programmer working on the process of importing those
elements into CM.
-- Review the CART report, concentrating on elements in status codes B
and C. These elements failed the sanity check, in other words, they
were registered in CM, but no trace could be found in the listed
location. Again, we started the process of fixing up the CM records
by either deleting them (if not required), or changing the record to
point to the right location.
-- Review the CART report for mandatory elements (mostly in status code
M), and see what changes had been made to these elements on the
customer's system. Try and decide whether these elements should be
retained under V3.0.
-- Review the CART report for elements that had been customized but not
marked as mandatory (mostly P). There are quite a few elements in
this category, some of which will come as a surprise to a customer.
For example, EMC, EMC1, FC1, WP, and so on.
-- Generally review the contents of the ALL-IN-1 directiory structure
to see if there's anything that could cause problems during the
upgrade, for instance, modified FDLs and/or data files.
Items that can affect the amount of time taken for this type of work:
1. Level of customization on the system. Clearly the more code that's
been changed, the more work there is to do.
2. Availability of customer resources who understand the system and
why changes were made. If you're on your own it will take more
time to reason out why a change was made.
3. Knowledge of what the CART can and cannot do. I have stated time and
time again that it is not a universal panacea, but only a tool that
needs to be supplemented by human wisdom and intelligence.
4. Knowledge of ALL-IN-1 V3.0 (plus its patches) and previous versions.
If you know what you're dealing with you can get a lot more done in
a set period of time than is otherwise possible.
After all of the work described above was accomplished, a second CART
run was executed in order to try and achieve "a clean CART report".
This is one that has:
-- No unknown elements listed in the site elements report.
-- No elements listed under status codes B and C
-- No errors reported
-- A well-defined list of elements in status codes M and P that the
customer is prepared to deal with just before (the Ms) and
immediately after (the Ps) the upgrade. Of course, there are other
important status codes that must be reviewed, but these are the
most important, in my experience.
Net result:
1 day will do a lot of good work, providing the Digital specialist is
well prepared and has the required knowledge. Two days should finish
the job, after a second CART run is carried out.
FWIW, Tony
|