Client problem

[pspafford]

I just built my first database for a client. I password protected everything so that they can't do anything they aren't supposed to (in other words screw around, or hire somebody else). However, since they are a graphic design firm, they are unhappy with the way that I made their invoices look.

They have asked me how they can change the layout themselves. I'm trying to tactfully say, "I don't want you messing things up" and "I don't want to hand over my password". But I'm not sure how to handle it.

They are very adamant about wanting to do this themselves. I have two questions:

1. How can I say these things to them diplomatically?

2. Since the invoice is in only one of the ten related files, is it possible to make just the InvoiceDetails file layout mode accessible? ... or would the layouts of all of the files become accessible?

Help me quickly please.

Paul.

[Chuck]

quote:

---

Originally posted by pspafford:

1. How can I say these things to them diplomatically?

---

This is often a sticky issue with clients. My advise (and I would also welcome other's input) would be to explain to the person in charge, either your contact in the company or the individual who signs the checks, that giving access to the structure of the database will probably cost them more than having you do the changes for them.

Part of the wonder and power of FileMaker is the ease with which novices can create powerful solutions, but this also means that novices can break professional solutions. Tell you client that doing this is, in your opinion, not in their best interest, and make sure that they understand that it is very likely that a novice will change something that will require your intervention, and that it will probably mean more of your time fixing the problem than would have been necessary to have you do it in the first place. And more of your time means more of their money.

This has been exactly my experience with a current client who has access to the master password. They have, on occasion, altered the database to suit their new needs, and in the process wonder why records are disappearing. The problem was traced to their editing a script which would delete records without notification, and they didn't understand what was happening. In the end, I spent probably ten hours tracking down the problem, when if they had come to me in the first place to add the functionality to their system, it would have taken about two hours.

quote:

---

Originally posted by pspafford:

2. Since the invoice is in only one of the ten related files, is it possible to make just the InvoiceDetails file layout mode accessible? ... or would the layouts of all of the files become accessible?

---

You can give access to layouts in one file and not the rest. The same password can be used for the different access levels in the different files.

Chuck

[pspafford]

Thanks, Chuck.

[BobWeaver]

Some clients are much more blunt. Eg.:

"I paid you for this program. So, now it's mine. I have a right to do anything I want with it. Give me the password or I'll call the cops."

Answer:

"The solution that I developed for you makes extensive use of a large library of scripts, layouts, and other prebuilt modules which took 100's [add additional zeroes as necessary] of hours and 1000's [likewise] of dollars to develop. This library is my livelihood. If I give you the password allowing complete access, I will have to charge you the full cost of the development for this... blah... blah... blah..."

This is, in fact, generally true. Clients will understand this, but they need to have it explained to them.

[LiveOak]

I have a different perspective. FM is an end user tool. FM developers should expect to have a different relationship with their clients than a Oracle developer. FM development is often a much more cooperative endeavor with your clients. Many clients want to participate in part of the design or implementation of the database system. Given the place in the market that FM fills, this is not unreasonable. Taking a hard line with the client is a good way to get achieve that reputation that many developers in the software industry have regrettably achieved, that of talking down to and ignoring their customers. FM developers often take more of a mentor position. Fixing the occasional client error is a small price for a lasting client relationship.-bd

(In many states in the US it is illegal to withhold access to the work product password, even if there is a dispute over fee.)

[macavity]

As someone in the graphic design business who also does FileMaker programming I have a certain amount of sympathy with your client's request. Their invoice must reflect their corporate design, even to details you may not recognize. (On the other hand your graphic design clients will soon notice that FileMaker completely messes up fonts, ruining the letter spacing and destroying the kerning.)

My own experience, with programs running in several advertising agencies, entirely bears out what Live Oak says. I have always divulged the password at least to one person in the agency and actively encouraged their interest in FileMaker - while at the same time warning them of the dire consequences that would result from any inadvertent changes made even to the tiniest comma etc. etc. So far no client has developed enough interest, patience, or confidence to undertake major changes on their own. And none has "hired someone else".

[BobWeaver]

I have never withheld a password from a client either. However, I can see situations where one might develop a canned solution that can be resold to others with minimal changes. In that case, and if you have not charged the client the full cost of development, I think it is reasonable to keep the password to yourself. However, the client should be aware of this and agree to it from the beginning. In any event, make sure that someone has access to the password in case (heaven forbid) you get run over by a bus.

Generally, you won't have to worry about the client hiring someone else. If you do a good job, they have no reason to replace you. There are a few clients (luckily, very few, in my experience) who will always question the value of your work and continuously shop around for a better deal. If you get stuck with one of these, let them go. They aren't worth the stress.

[pspafford]

Hmm. Lots of food for thought. This is my first "official" client, so there are some administrative issues I hadn't thought out beforehand. I appreciate everyone's advice, and anything else y'all may have to offer.

Thanks.

Paul

[LiveOak]

There are two different philosophies that can be working here. A lot of the FM business divides along the same lines.

1) Shrinkwrap developers. These FM professionals develop turn-key solutions to which they retain the rights and master passwords. Their customers purchase a license to use the solution. These developers retain full creative control over the direction their solution will take. They are paid a fixed price for the license. Here customer make suggestion for features of the product, but the developer has the final call.

2) Consultants and contract developers who perform "work for hire" in the legal sense. In this case the ownership of the solution is assigned to the client. These developers most often work by the hour. Here the client has a lot more say about the product. The client after much advice not to, may modify or break the solution. The key here is the solution belongs to the client AND if the client breaks the solution, the developer is paid by the hour to fix the problem. Developers are wise to realize that the are paid by the hour, and not become too attached to the art of their solutions. Their task is to make suggestions of how to meet the clients needs, but the client has the final call.

This division by type is easily seen at the developers conferences. At the conferences add a third type, the corporate users. Each group has a uniquely different viewpoint and often is looking for different features from FMI in future versions. For examples, shrinkwrap developers want networking for runtime, contract developers want more documentation features, and comporate users want more ODBC and connectivity features.

(Hope this is useful and no too much of a ramble!) -bd

[Yeti]

I'm also going to make my 'first' database for a company outside of my own. And I thought of some things we have to discuss, but this brings on a whole new persepective. Prooves what this site is for once again...

I can sympathize with both points of view, although I do believe that people are in generally too lazy to invest a lot of time and effort in things they can let somebody else do more easily.

Instead of putting a new exhaust under our car ourselves we go to the garage.....or don't we?

;-)

------------------

Yeti

[Keith Silva]

The key words in LiveOak's response are "lasting client relationship." If your solution does not have proprietary features, its better to honor the client's request and keep a happy customer. If you decide to provide the password, ask the customer to sign a written "release" regarding any problems caused by the customer's changes. This will clearly communicate the risks, and perhaps chill the customer's enthusiasm for making the changes on their own.

[Ocean West]

Copyright

Most of what this thread is fringing on is puting in to perspective who is the rightfull owner of the copyright. The client/or the developer?

If you go in to a project with your "i's" dotted and your "t's" crossed and this point is explicitely spelled out and both parties agree to it then there should be no discussion.

But many times consultants find themself's working on a project and the client one day announces they want to market and exploit this and take it around the world. This again should be covered in the orignal agreement in the case this need arises.

Do not skimp on a store brought contract, Consult a Intellectual Property Rights Attorney to adequelty cover these points, and make sure that it superseeds any agreement your client may make you sign. Some clients require you to fork over "EVERYTHING" and you would be best advised to have your attorney review this document for the betterment of your interests.

The hard part for the consultant is do determine which business he/or she is in. The Professional Consultant, or Custom Developer. Something my mentor sugguested. Thanks BD! Not that you can't do both. But keep your focus about you at all times.

Either one it is customary that there are certain "Background Technologies" that you will retain. Because as was mentioned they are your livelyhood. The client most likely would allow you to these, but it would probably be pratical or ethical not to compete with your client. In other words, you wouldn't take a custom solution you spent hours for and were handsomly paid for; and turn around and charge their competitor by copying and making minor changes.

On the other hand, if you had other clients in different businesses that were not in the same target market you should be free to use these with out infringing on your existing or originating client.

In most cases it isn't a complete solution, but rather your methods of practice, your GUI, and Scripting, perhaps the calculations, and the techniques you've learned over the years

that you treasure most.

In any case it is best to keep the communication clearly open between you and your clients. Find out their intentions, and make your's known, as well.

Stephen

[This message has been edited by Ocean West (edited January 19, 2001).]

[john.daly]

Returning to the original question - I had a similar problem where multiple clients all have different letterheads and these may change with unnerving frequency. Although I offer the service to change it for them I have also put the letter head into a container field and this enables them to alter it simply by cutting and pasting. In fact the actual letterhead, signature and footer are stored in a separate Filemaker file that is related to the main file. This way it's easy enough to send them a new letterhead on a floppy disk. Of course I don't know whether it would work in your case but it would allow them to design and change at least part of the invoice without them having access to the layouts.

[esteshk]

I may be missing something as this discussion went far beyond the original question but here goes. I have many solutions where I define an administrative level password that gives access to everything but scripting. After all, that's where the most of the good stuff is. This also does not permit access to field definitions. The client can make layout changes that are easily reversed if found to be problematic. If your solutions meet the needs of your client, rarely do they get curious about deeper database structures.

[This message has been edited by esteshk (edited February 03, 2001).]

[Ocean West]

Moved to new forum.

[abkaplan]

hi,

You are writing about the master passwords to give it to the client or not.. if I understand true.

Yes now I am preparing student affair programs for a university in Turkey. They also ask me to give the master passwords. and I gave them all necessary passwords to be able to edit all program. What happens?. The program is so huge that no body other than me can understant the links. I mean technically any body who know file maker can understand and follow the links.

but here there is an important point. technical structure of the program is not so much important than the logical relationships of the different process of the program groups.

What I mean. more clearly administration or the secretaries none of them know the algoritmic design of their own work. While programming I solve their sistem and I decide what they should do. As an operator I have to think the future of may program and when I ask them to give answers to my question they get shocked because the don't know what to do and even more they dont have any idea what will happen next year or later. in such a situation as a program operator my situation is shifted from operator to the administrator of the company.

Now they ask me to give them the passwords. ok I'll give you all but what can you do?. Even if you know the file maker what can you do whithot any knowledgw about your own process.

I tell them be afraid "I work for you as an operator and I decide about your future" so you accept you have to accept because it is right. What happens one day if I say yes I dont want to work for you as an administrator and but as an operator, suplly a guy both as "andministrator" and "operator"?

Yes truly I say them that and I forced them to find suitable staff for their job now.

For the salary they gave me I dont work forever. I say that.

But still they dont do any think.

They are happy with their admin-passwords and enjoy their life.

What do you think about that situation? I am really interested in your view.

I am sorry if I bother you with that long message.

Abdulkadir Kaplan

[markpro]

Having your I's dotted and your T's crossed is the key. Set the clients expectations correctly and upfront. Let them make the decision based on what you are willing to do for the work in each of the fore mentioned examples. Attach a value to all aspects of what you do (libraries, trade secrects, etc.) relevant to the client you are dealing with. Will they be ambitious enough to take your secrets and run. Rememeber, Human nature breeds fear. Will you be doing anything that you are doing today... 3 or even 2 years from now. Reflect and decide...cover your bases,don't be afraid to trial close and most of all... add value and BILL!!!!