Estimating workflow hours
Harmon Dan-rrfs20
Dan.Harmon at freescale.com
Tue Mar 29 12:52:52 EST 2005
I'm attempting to attach a document we use to estimate custom workflow development. The emphasis is on "attempting" as I don't know if the server will allow attachments. This attachment is an Excel workbook that we have used for about 4 years. I don't know how many data points have been included in our average estimates, but I can say that each time we have a custom workflow that I am involved in, the estimation model is updated with the average of the data points taken.
Regards,
Dan Harmon
> -----Original Message-----
> From: sap-wug-bounces at mit.edu
> [mailto:sap-wug-bounces at mit.edu]On Behalf
> Of Rick Sample
> Sent: Friday, March 25, 2005 6:29 AM
> To: sap-wug at mit.edu
> Subject: RE: Estimating workflow hours
>
>
> The responses just confirm that it is difficult to estimate
> in "hours".
>
>
> Thanks all.
>
> >>> jocelyn.dart at sap.com 3/23/2005 22:03:35 >>>
> 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
>
> _______________________________________________
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Workflow_Estimation_Tool_1.5.xls
Type: application/vnd.ms-excel
Size: 29696 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20050329/613ae5f6/attachment.xls
More information about the SAP-WUG
mailing list