Top Contributors

Microsoft Access 2013 Best Practices Between Client and Developer

I would like to get input from other developers especially Microsoft Access developers, what do you get from your clients before you start a database. Do you get the project details in a word document a layout of the project or what. One project I had was a six week project and they had everything they wanted on a spreadsheet. I resented it at first but I finished the project in 6 weeks. Everything was detailed. I thought they could do it themselves but they just knew what they needed in the database but didn't know how to accomplish the task. My current client is paying me by the hour but they keep on adding to the project and they don't understand why it is taking me so long. I have just been asked to add a feature that tracks employees pay from over 400 departments. I told the client this was major but she doesn't think so. Granted she is paying me but we had to agree to disagree that this was major. I am all alone in doing my project and just get frustrated when client keeps adding things to it. Also how do you tell people how much time something takes. I've never been able to do that. Maybe someone could suggest reading material I should check out for this question. Thanks for any input.
Rank: Prodigy

Expert Comment

Jim Horn2015-02-23 06:10 AMID: 146096
> I am all alone in doing my project and just get frustrated when client keeps adding things to it.
Good luck with that.  Scope creep is never fun, especially when they try to milk it into an existing timeline or fixed cost proposal.   Neither are your situation right now, but the whining isn't healthy.   Based on my experience popular reasons for this whining are you're dealing with a  junior person trying to look good to their bosses, someone trying to pull a fast one on you by discussing something hard and then saying 'but you agreed to it!', a naive client, or a mom and pop operation that can't afford a running tab at $whatever you are charging them.

Might want to take a health check with these guys, as some vendors have undocumented payment terms of 'we'll pay you whenever we feel like it / have the money / you do all my scope creep / any other handy excuse.'

You need to stick to your guns with a 'I agreed to deliver x on date y, and this is x + 1 which I'll work after I deliver x on y, and deliver on y + 1'.    If they balk at this, then any additional scope means changes to the schedule and billing, including having the conversation about it.
0

Expert Comment

Jay Williams2015-02-23 06:41 AMID: 146102
What I get from the clients first is probably less important that what I give them.  Maybe the hardest and most important things about any development project is managing expectations--your own and everybody else's--because expectations are human issues, not necessarily technical ones.

That's why, at our very first meeting, I try to explain how most projects, as they develop, reveal the things that we do not, even cannot, know at the beginning.  It is only when we forensically analyze processes that we fully understand them.  I confront this issue openly, and with good humor, making the point that at this early stage I certainly don't yet fully understand what they're after, and in my experience, most clients don't know either. ;-)

Then I explain that developing databases is incremental, and that each component is built on what came before; if we decide that we need something a little different once we get started (and we usually do), then it means we have to undo and redo what has been done after where the change is needed.  It's kind of like deciding we need different plumbing and electrical--after the drywall is already up.  They can understand that concept and recognize up front that change-orders take more time and money, just like any building project.  This also raises awareness about why it's important to do as much of the analysis and planning up front as is possible.

This exercise also grooms the client to trust you and your expertise and heads-off a lot of their second-guessing about how extensive and expensive the project is, because you've demonstrated your honesty about what is not known, as well as your competence and experience.  Most often, I don't even try to give them a cost or time estimate until after seeing most of what they think they want and a good overview of what tools they're currently using.
0