[thelist] job estimates with unknowns

[Matt Warden]

On 5/23/07, Bob Meetin <ontheroad at frii.com> wrote:
> * I am still fairly new to this business and accept the fact that there
> will be some learning curves as i develop my processes in addition to
> tech knowledge/skills - i've thought about creating a site plan
> collection form, but would any client actually use it??? A more
> established business (than me) would have better processes from
> experience in place to account for the meeting, interaction, develop a
> plan for 'them' time.  I spend many, many hours in developing the
> pitch.  How much of this prep time is chargeable and how do you mark
> this in the estimate (8 hours of account management at $$$/hr).

Pitches you will have a harder time charging for (not that you
couldn't). Approaches and designs are easily billable. This means you
will stop doing pitches and start developing approaches and designs.

If you hand them something that results from your approach (even if
it's just a printed out powerpoint), it will make things go more
smoothly. You know, "deliverables."

> * finite list of pages - I have a general idea of the 'regular' pages
> they want, however they have some areas of the business which are
> somewhat undefined as to whether they will need pages, and in
> particular, galleries.  It is feeling like I will make up a list of
> known pages, then a-la-carte for the unknowns and maintenance.

You have the right idea. Control the scope and anything that is
undefined now is out of scope; it can be handled by a separate
billable activity once they (and you) figure out what they want.

> * frustration interaction  - Barney said something that seems to ring
> true that clients don't know the in's and out's, details.  I'm aspiring
> to 'bold', but need to balance bold with the fact that as a young
> business I need to work extra hard to develop that list of clients that
> will help with further referrals.  I did 'allude' to the what is your
> budget question, but didn't force an answer and didn't get one...

It is true that your reputation will bring more business. A part of
this is client referrals and repeat business. In my experience,
though, clients love to dangle this as the carrot leading you to doing
more work for less. Your pile of good will can always increase, so
many end up doing more for less indefinitely. In my opinion, it
doesn't really pay. Value your work; do a good job; don't let the
client step all over you; etc. and there will be enough good will to
keep the work flowing.

To be honest, my two primary sources of work were from connections
within the web developer community (including here at evolt) and
repeat business. I can point to only a couple instances where one
client sent another potential client my way.

> * business analysis - Undoubtedly that's where I fall short.  I'm doing
> some contract work for another firm which owns this piece - it is far
> less stressful, time-consuming when the requirements are pre-defined.
> Ciphering out how or what to bill for business analysis / account
> management is the "key".  I'm learning though - I let/made a couple
> potential maintenance nightmares 'I want a simple (simple=cheap) site'
> scenarios go away.  "Why should I pay for documentation/training???
> Where is your kind heart? My nephew does this work..." Your nephew
> sounds like your best choice.

This is a tougher one. Smaller clients will want to chop this portion
of the SDLC to bits to lower their bill. I think it might be a mistake
to structure your communications as if business analysis is a separate
thing. At my day job, they just changed our titles from "Systems
Analyst" to "Business Technology Analyst", and this is largely a
reflection of the fact that a large % of what we do is business
analysis. If you structure your communications to the client as if
business analysis is not separate, you may be able to minimize
questions like the ones you list.

I would suggest structuring your communications to include phases of
development that map to the SDLC. Planning/approach (pre-requirement
analysis), requirements analysis, general design, detailed design,
development, testing, end-user acceptance testing, deployment. If the
client is expecting these phases (note that this is the front to the
client, and does not lock you into a waterfall-style development
process) rather than simply "stuff the BA does" and "stuff the app
team does", then things should go more smoothly. Also, if you do need
to talk about the differences in the two roles, now you have a
structure against which you can describe responsibilities (both roles
participate to some extent at all phases).

hth,

-- 
Matt Warden
Cleveland, OH, USA
http://mattwarden.com


This email proudly and graciously contributes to entropy.