http://www.markcloyd.com Client-driven, standards-based application development Thu, 04 Oct 2007 03:47:41 GMT en-us just me and my fingers mark@markcloyd.com 10 http://searchenginewatch.com/showPage.html?page=2165061 http://searchenginewatch.com/showPage.html?page=2165061 Danny Sullivan Tue, 19 Dec 2006 8:45:00 GMT Now supported by only one major crawler-based search engine -- Inktomi -- the value of adding meta keywords tags to pages seems little worth the time. In my opinion, the meta keywords tag is dead, dead, dead. And like Andrew, good riddance, I say!]]> http://www.markcloyd.com/index.php?refkey=full_articles/articles/41 http://www.markcloyd.com/index.php?refkey=full_articles/articles/41 Mark Cloyd Fri, 03 Nov 2006 13:02:00 GMT
Provided with only a general understanding of what a site should be and how it should function, often referred to as an "Outline", you have given the client all the room they need to claim mis-interpretation.  You will cost yourself a lot of time and money trying to please your clients because what they, 'Understood' and what you thought you agreed to will be two different things.

In my nearly 14 years of developing web-based applications, I have had the pleasure of working with people who at one time or another have created a static web page or two using .html.  In doing so, they seem to think themselves experts in the area of managing web development.  Any developer worth their salt will tell you that they simply don't know everything and that staying abreast of emerging technologies and how they should or shouldn't be applied to application development is an everyday endeavor.

That being said; let me present you with a few things to consider:

The interview

When approached by, or approaching a new client, at least 2 hours should be immediately considered irrecoverable in terms of monetary compensation.  The purpose of an interview is to gather information and during this process a common mistake is underselling talents.  Let's for a moment consider doctors or lawyers.  They spend about ten to twenty years acquiring and developing their skills before "selling" them to the general populous.  Knowing that, how many doctors or lawyers offer discounts to their clientele because they are worried that someone with less experience will do the job cheaper, well?  If you still haven't figured out the answer, it is this, NONE.

The interview process should be guided by a seasoned developer, one who knows the industry and the extent of their talents and the capability they have of quickly learning new technology that may help achieve a process that the client may want to incorporate into their internet application.

Clients often times are not very well versed in their own industry, let alone ours, so the job of a developer is to harvest information, a page count (views, not actual pages), requested features, i.e. e-commerce, forums, dynamic administration, etc.

A common list of items to consider during the information harvest is as follows:

• Purpose of the site
• Demographics
• Languages (for localization, if applicable)
• Colors (palate)Font choices
• Features (some mentioned above)
• Pages (views, not actual pages, because effective application development works best without redundant coding)
• Form options (if they would like forms, if so, what fields should be required)
• Contact information
• Email needs
• Hosting requirements
• Domain registration
• If they currently have a registered domain, be sure to acquire the login credentials for the current registrar.
• If they need a domain, get a list of domains for them to choose from.
• REGISTER THE CLIENT AS THE OWNER OF THE ACCOUNT
• If registering the domain for the client, make sure the client understands if you are to be listed as the technical contact, if so, don't take that responsibility lightly.
• Hosting requirements
• If they currently have a home for their site, or they are going to have their site hosted on the registrars' server, check the server to see if it will meet your development needs.
• Obtain FTP login credentials.
• Get accurate contact information, not only for the site, but for reliable communication with the client.
• Explain that site content will need to be provided by the client.
• If the client needs help, try to obtain the assistance of a reliable, qualified content writer.
  

This list is not absolutely complete and some projects will require more consideration, but these are some pretty common items.

Before the interview is over, make sure to explain to the client how the site will be developed.  Be careful not to talk over their heads, but inform them of languages and techniques that will be used, a general statement will be enough; lengthy explanations will confuse the client and make them uncomfortable.  Explanations are afforded to assist later efforts if needed in explaining hosting requirements.

The Scope of Work

Herein lays the heart and sole of success.  A Scope of Work (Scope) will contain information for every detail of a given project.  Ideally a Scope should by accompanied by a wire-frame that will allow the client to visually understand what is happening.  A wire-frame can be as simple as a graphic site map, or as detailed as a working skeleton of the site that the client can actually click through (highly recommended).

The Scope will be a well thought-out document that explains in detail the development process from beginning to end, including graphic design, site development, feature development and implementation, content development (if required), content integration, beta testing, finalization of development, launching and follow-up work.

Did I mention detail, if not, let me mention it.  Make sure your Scope is written in FULL DETAIL.

The Scope should also include Development Benchmarks (Benchmarks).  These Benchmarks are the developers' assurance that the client will not change their mind, and the clients' assurance that development is progressing as promised.  Each benchmark should have a date assigned and a place for client sign-off.

Timelines are important to include in the Scope as the client will inevitably want to know when the application will be complete.  Care should be taken to allow time enough for unforeseen instances of delay, and should overlap start and end dates of other projects as they apply to a development schedule.  Meeting your timelines is paramount to your credibility.

I could go on for a few more pages regarding the importance of a proper Scope, but I will leave it there for now, if you have questions, please use my contact form and ask away!

The Proposal

This is where lawyers and doctors have it made.  If someone hit you in the head with a baseball bat, you are at the mercy of their pricing structure if you expect to get adequate care, and they are not afraid to bill you accordingly.  Neither should you be afraid to present your pricing to your client.

If a client thinks the bottom line is too much, be prepared to offer options.  Present to the client the possibility of developing the application in phases, (properly planned, a secondary proposal and Scope should be available for presentation) this way the client may not immediately have the full application they want, but they can have the beginning of something that can be added on to later.  After all, any well designed application should be scalable and modularized for easy expansion.

Explanation of services and solid development practices may be required, but presented properly and with confidence, you will win a new client and the prospect for referral work later.

Make sure to include overhead in proposals, time has been spent to interview the client and to develop the Scope and the proposal.  Additionally the client may require a little hand-holding and may call several times to ask questions.  Effective communication will require phone calls and reviews and Benchmarks will take time; all of these things should be accounted for in your pricing.

Deposits and payment schedules are the responsibility of each developer and I will not recommend pricing.  Charge what you are worth.

Development

As for Graphics, the only thing I can offer is this.  Based on your initial interview, the Scope and the Proposal, if a client wants a pink giraffe with green spots then later decides that they want a purple giraffe with orange spots, give it to them.  If however the client wants a pink giraffe with green spots then later decides they want a brown elephant with beige stripes, bill them.

Site development, you know what it takes to develop a site and with enough information from the initial interview, the Scope and proposal, difficult elements should have been taken into consideration and should be accomplished within proposed timelines.  It is not the clients' fault that the provided information was not analyzed and compiled correctly.

Cross-browser and cross-platform compatibility should be taken very seriously.  Many people still use the inferior browser Internet Explorer, evolution still hasn't caught up to some folks, so through testing should be performed.

Content

Content is the responsibility of the client, unless a content developer is used.  Even with a content writer however, the client still needs to approve the content prior to it being applied to the application.  Make sure that one of your Benchmarks includes receiving completed content from the client.

Additionally, you should allow thirty to sixty minutes per page (actual, not viewable) for content integration.  Pages often need additional formatting and tweaking can be time consuming.

Project Beta

A test platform should be available to the client to preview the site.  It can be as simple as a directory on their server called "preview" that they can "bang" on the site looking for potential problems.  We all know however that applications usually launch with no unforeseen issues and Beta's aren't really necessary (HA, HA, HA, HEE, HEE, LOL).  Sorry.

Once the client has had the opportunity to test the site and any bugs worked out, (without mention, the developer has gone through the application fourteen different ways) the application can then be moved into the live directory.  Thorough testing should once again be completed by the developer and client as path changes may affect the performance of the site.

Follow-Up work

Let's be adult about what we have created.  Those of us who have kids all know that just because we made kids doesn't mean they don't need to be watched for, oh, the first thirty-five years of their life.  While thirty-five years is a little excessive for a guarantee, I suggest at least a three month guarantee to ensure that the application is a success.  During this time, if something happens that is obviously not supposed to happen, fix it.

If you need to offer a longer guarantee, maybe you should be selling cars instead.

Maintenance contracts can be offered to support the site for additional work and content changes if the client does not want to make the changes.  Surprisingly, no matter how much time a developer takes in making a comprehensive administrative section, many clients still would rather pay the developer to maintain the site.  If this is the case, I suggest a monthly or quarterly or even annual contract for a specific number or hours.  Otherwise, the maintenance will kill production of additional projects.

Conclusion

I hope this information is helpful to someone, and although it is really only scratching the surface of project management, I wrote this as a rant because of management practices in the industry.  It just makes me absolutely sick to death that people who don't have a clue are in charge of talented developers.  So developers please take this information and run with it, take the time to learn to manage yourselves and your development practices well and be successful.

DO NOT be afraid to charge for your services and DO NOT promise insanely short timelines to gain business.  You are in charge, do not let your talents and abilities be dictated by those who need your services.

Comments on this article are welcome.  Please use the contact form on this site and let me know what you think.

TTFN

]]> http://www.faqts.com/knowledge_base/view.phtml/aid/1990 http://www.faqts.com/knowledge_base/view.phtml/aid/1990 Mark Cloyd Fri, 13 Oct 2006 11:19:43 GMT filename you can restore the info to the database again using: mysql -h hostname -u user --password=password databasename < filename]]> http://askyan.com/archives/phpbeginner/p/4/read/217_single_page_frame_sets http://askyan.com/archives/phpbeginner/p/4/read/217_single_page_frame_sets Mark Cloyd Fri, 13 Oct 2006 11:17:27 GMT http://askyan.com/archives/phpbeginner/p/1/read/185_serverside_vs_clientside http://askyan.com/archives/phpbeginner/p/1/read/185_serverside_vs_clientside Mark Cloyd Fri, 13 Oct 2006 11:15:25 GMT