Estimating workflow hours
Dart, Jocelyn
jocelyn.dart at sap.com
Wed Mar 23 23:03:35 EST 2005
Hi Rick,
Yes agree with everything Mark and Kjetil have said along the
difficulties.
I find myself that a major difficulty is in getting the business
requirements - and until the business requirements are known in a
reasonable amount of detail its quite hard to give a call.
I find I allow 2-3 weeks for design/develop/unit test even for quite
simple workflows if the business requirements are hazy or of the postage
stamp variety. Most of that time will NOT be spent building the
workflow - most of it will be discussing business requirements with
users, spending a few hours setting up a workflow, going through it with
them, adjusting it based on their responses, etc.
If all the SAP functionality around the workflow is already in place,
and there is a standard template, it's usually the work of a couple of
hours to turn on a standard template. But that's a long way from going
live with it.
For estimating purposes the key things I look for are:
* Is this the first workflow at this company? Don't count any
no-brainer workflows like EDI error processing or asset master
processing. If yes, add more time as administration/environment, which
inbox, where email address will be held, email notifications etc. will
all have to be discussed and sorted out. I like to class this sort of
time separately to the workflows themselves.
* Is the functionality around the workflow already in use/new? E.g. if
it's a purchase order release workflow, are purchase orders, release
strategy and classifications already in use. If new, add more time -
you will undoubtedly waste time while people work out the configuration
settings/process and you have to adjust the workflow to suit.
* Is there a standard template/business object/rules etc. that I can use
as a starting point. If yes, that reduces the time needed.
* How clear are the business requirements - e.g. have they thought about
escalation, substitution, email notification, how agents will be
found/maintained or not? If the business requirements are sketchy -
add more time.
I'd also suggest estimating the time to set up agent determination rules
separately to the workflows themselves. As this encourages rule sharing
where possible and also lets you highlight time needed in cutover plan
to populate rule data.
Hope that helps.
Regards,
Jocelyn
-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Mark Pyc
Sent: Wednesday,23 March 2005 1:09 AM
To: SAP Workflow Users' Group
Subject: Re: Estimating workflow hours
How long is a piece of string?
This really is very difficult. Implementing a WF could mean anything
from turning on EBP shopping cart approval to designing your own
Material Master review and distribution WF. It could mean anything
from a day to 6 months.
What I find I need to stress when quoting is the clear distinction
between delivery of a built WF ready for integration testing versus
supporting a WF through to Production. One of the most time consuming
aspects of delivery can be the support of the testing process. If the
customer is not already live with Workflow and doesn't already have a
competent WF administrator, testing can involve much hand holding.
I also find that you need to allow a buffer for OSS type problems.
Almost every site I go to will require at least one problem
investigation that leads to an OSS note needing to be applied. It's
very difficult to allow for these accurately beforehand.
Anyone who reads this list also knows that sometimes OSS won't help
you. Sometimes what seems very simple during process design can have
you pulling your hair out because WF simply wasn't designed that way.
A recent example for me was the request to prevent forwarding of
workitems between company codes - sounds simple until you try to do
it.
The level of WF already in place will have a direct impact on the
development cycle. If the client is already WF savey, they are in a
position to know what they want. If it is the first real WF, then the
development cycle also includes a good deal of knowledge transfer. I
truly believe that a good consultant should not necessarily deliver
what the client asks for, but attempt to deliver what they need. This
process can involve the need to build prototypes, run workshops,
redesign etc which is much more time consuming than rocking onto a
site with a competent WF Admin who drops a well written spec in front
of you and says 'Build this'.
Finally any quote needs to take into account the quality of the
consultant.
I wish you all the best, but I don't hold out much hope for an
accurate methodology for estimating WF delivery.
Have fun,
Mark
On Tue, 22 Mar 2005 07:24:09 -0600, Rick Sample <Rick.Sample at gbe.com>
wrote:
> I am sure SAP has some sort of measuring stick when selling the
product
> line.
> So there must be some SAP guidelines on development hours. *hint*
>
> We estimate the best we can. I am just looking for some sort of
> supporting documentation
> as a back up.
>
> >>> kjetilk at statoil.com 3/22/2005 1:53:01 >>>
>
> The good old "how much time do you feel it should take" method is in
> use
> here. No formal methods.
>
> Not that we are making many new workflows, but estimating is one of
> the
> least mature areas of software development whether it is workflow or
> traditional coding. I used to work with software measurement and
> estimates
> for a previous employer, and even when using formal methods with
> experience
> data it is very difficult to make estimates. Unlike many other
> industries
> we "never" make the same product twice, and often it is not the same
> people
> working together except within a project. So all we have to help us
> when
> estimating is previous personal experience, unless you have been
> gathering
> experience data using some formal method.
> Assuming you have a near perfect specification you can probably make a
> very
> reliable estimate, at least if you have some previous experience data.
> So
> one trick is of course to say the estimate assumes there will be no
> changes
> in or additions to the specifications. That should give you a safe
> escape :
> -)
>
> Not much help I guess.... you are on your own. My best advice: always
> give
> the estimate as a range. When there is high uncertainty an estimate of
> 1000
> hours doesn't say as much as between 500 and 3000 hours. The second
> best
> option is to give an estimate and a quantified uncertainty. However,
in
> the
> latter case the project manager will most likely forget the
uncertainty
> and
> use the estimate.
>
> Ask the accountant for an estimate on specifying and verifying the
> controlling processes required to be compliant with the
> Sarbannes-Oxley
> act.
> Can't do it? Well...
> --
> Kjetil Kilhavn
>
> "Rick Sample"
>
> <Rick.Sample@ To: SAP-WUG at MITVMA.MIT.EDU
>
> GBE.COM> cc: (bcc: Kjetil Kilhavn)
>
> Sent by: Subject: Estimating
> workflow hours
>
> sap-wug-bounc
>
> es at mit.edu
>
> 21.03.2005
>
> 18:28
>
> Please
>
> respond to
>
> "SAP Workflow
>
> Users' Group"
>
> I am looking for some rough guidelines for estimating cost of WF
> development.
> Not an exact science I know but some general guidelines on what others
> are
> estimating on development would help.
>
> Would be nice to estimate by days, weeks, and months but project
> management and
> accountants don't like that method.
>
> Any help is appreciated.
> 4.6C
>
> Rick Sample
> SAP Workflow / Developer
> Graybar, Inc.
> 11885 Lackland Rd.
> 63146-4208
> 314.573.5822
> Rick.Sample at GBE.com
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> -------------------------------------------------------------------
> The information contained in this message may be CONFIDENTIAL and is
> intended for the addressee only. Any unauthorised use, dissemination
of
> the
> information or copying of this message is prohibited. If you are not
> the
> addressee, please notify the sender immediately by return e-mail and
> delete
> this message.
> Thank you.
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug
More information about the SAP-WUG
mailing list