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.