On Day 3 I attended the session led by Acromedia, from British Columbia, on meeting client expectations. This is an area that I intersect with every day at work and I thought it would be good to sit and listen to how others engage clients. Interestingly, the theme of this talk was "Meet them, don't try to exceed them." I've included what I heard in that presentation and inserted my own thoughts as they seem to apply.

SALES PROCESS
If you're a sales person you need to:

• Understand the client
• Qualify
• Identify needs
• Decide if this is the right opp for you
• Introduce client to Drupal

And a typical client:

• Has worked on few if any Web projects
• Doesn't understand the development process
• Has no idea of costs and efforts invoved
• Overlooks Web site evolution
• Is unaware of options or opportunities

When you qualify the client

• Project objectives comprise of...
  • What does the client want?
  • What is the desired outcome?
  • How will you measure success?
  • What does the client need from us?

There are two kinds of effort that a company might engage in Think vs Work

THINK
When you think with the client, you help client decide what they need based on:

• Market and industry
• The type of service the provide
• How much effort they want to put into the project

In other words, you are helping the client through the full planning process. You are engaged in helping the client define the business.

WORK
When you work with the client, the client:

• Provides direction to the project
• Has a Business Plan
• Has a Corporate Identidy
• Has planning materials

PRIORITIES
Acromedia calls making suggestions "Kicking the Stick".
When working with a client, you need to look at the client's priorities which should include:

• Looking at the budget
• • Before engaging in a contract you MUST establish budget. It is OK to ask "what is the budget?" DON'T GO ANYWHERE WITHOUT FINDING OUT
  • Where are you getting the budget from? Are there other budgets they can "steal from" suggest a budget.
  • Kick the stick means giving the client a suggested budget--guage the reactions
• Establishing a schedule
  • A specific date--Is it for a conference, direct mail campaign
  • a target season
  • kick the stick-suggest a date
• Whether the site will include innovations
  • world class deisgn
  • flash or video?
  • creative tools like calculaor or games
  • kick the stick--suggest a direction
• What functionality is needed
  • purpose of the site
  • level of client's tech savvy
  • who will maintain the site
  • how often will it be updated
  • kick the stick--suggest what is possible

RED FLAGS

Whenever you qualify a customer, you need to look for red flags. Some things to watch for include:

• Are they a start up or an established business (established business are better)? Remember, you want a long term relationship--Often the 1st project isn't particularly profitable, but 2nd and 3rd projects tend to be.
• Do they have a realistic budget?
• Are they a copycat? Are they copying another established business model?
• Do they have a business plan or RFP. Clients who have thought about a project will be more engaged. They will provide better feedback. They will be partners.
• Does their business ride the line of ethics? Gambling or porn for example.
• Do the requirements fall into our core offering? The fastest easiest projects are the best for you. Don't stretch your shop too much.
• Are they easy to communicate with?

When you are ready to proceed, remember successful projects start successfully. So look at the project and decide, do...

• They have the right budget?
• They have a realistic time frame?
• They need a product or service you offer?
• they pass all red flags and come out looking like a strong prospect?

At this point, you can Introduce the Client to Drupal, if they don't already know about Drupal--start with the basics

• Explain what a CMS is
• Make fun of the name--explain the name
• community dupport
• convey Drupal's successes
• Embrace Open Source

WHY DRUPAL?
Regardless of whether a client knows Drupal or not, it is very helpful to educate the prospect on what "comes with the meal". This will start to set realistic expectations. Explain to the prospect the strengths of Drupal. You could start with:

• ease of uses
• flexibility
• expandability
• accessibility -- hosting

TEST DRIVE
Acromedia has the terrific idea of setting up a demo site that resets every evening. Let the client play in the test site admin and explore the public facing aspects of the site. NEVER EVER use an existing client's site. If you do, the client will immediately think, "If they are doing it to this other site, when will I be next?" You will immediately set the expectation for a distrustful relationship.
The demo site should include:

• Custom design
• Realistic content
• Limited funtionality

DEMO Site
There are many benefits of a demo site, they:

• Set expectations
• Educate
• Describe deliverables
• Provides a frame of reference

Set the demo site up to allow you to increase functionality as the prospect is ready to see more. Interestingly, Acromedia references the demo site in a contract to avoid protracted language in the contract. They aslo suggest that the Drupal instance that will ultimately become the site should be initially set up as the planning system.

SCOPING CUSTOMIZATIONS
Drupal has a lot of modules which vary in quality. So, when looking at customizations, it is important to identify which modules make sense. Choosing the right contributed module can save many hours of work. To this end:

• Maintain a list of known and trusted contributed modules
• try before you buy--load modules up and see how they work
• put together a needs analysis for the client
  • keep it client friendly
  • use screen shots (to communicate to the cient) (to reduce risk)

make use of sales tools or build your own

• CRMs
• templates
• spreadsheets

SETTING EXPECTATIONS
Project Management--avoid selling a set number and then try to work towards it.
When getting started, a few things need to happen.

• A sales handoff
  • Although the sales person may well stay involved with the depending on the structure of your company
• A team orientation
  • Set up your team, establish a lead
  • Engage in a knowledge transfer
• A project kickoff
  • Discuss how project are managed
  • Establish project communications
  • Let the client talk--at this point the client is likely to want to engage in a knowledge transfer themselves

STAYING ON TOP OF THINGS
Managment tactics should include

• Keeping the client informed
• Setting up project milestones and schedule--in waterfall this should be very detailed, in agile it can be a framing of when different iterations will occur
• Set up a collaboration environment
  • Basecamp (I am personally not a fan of Basecamp, although it does integrate nicely with Blinksale.
  • Unfuddle
  • Drupal--Acromedia suggested that creating a collaboration environment that becomes the final Web site may be a good strategy
• Make good on project communications
  • If you say you will call at a certain time on a certain day, follow through
  • If you say you email, follow through

MANGAGING SCOPE
Mangaging scope can be one of the toughest things a team can engage, particularly with the small client who is using pretty much all contributed modules. It is very common for a client to not really like how a module works even though it has most of the functionality they need. It needs to be clear that you are licensing software that you, the developer, have not coded. You are providing a service of configuring and theming this software with *some* custom code. You can not warrantee software that you did not create.

• what is out of scope?
  • Simply put, anything you didn't expect.
  • Anything that was not documented.
• what do you do with an out of scope request?
  • contingency budget (You could use a contingency fund if you work on a fixed bid basis)
  • change request (You could charge the client if you work on an hourly basis)
  • knowing when to say no (sometimes no is the right answer)

QUALITY ASSURANCE
The number one rule is "find it before the client does". If the developer or designer hasn't tested SEND IT BACK to them before QA even starts. If you don't there are two serious issues that will affect trust and seriously destroy the client's experience.

• When a client finds a bug, and it is unexpected this takes you away from other projects--they take longer because you have to appease the client and your boss--this costs you money
• The client then goes on an Easter Egg Hunt looking for all sorts of other "bugs" and suddenly little things that wouldn't have been a problem are being brought up as "bugs".

This also emphasizes that you should review the process, not just the deliverables. If the process is flawed so will be the deliverables.

HOW CAN WE HELP?

• Be there for your team and clients
• Build your standard list of support modules
• Always create a list of which contributed modules will be on a standard site
• Create a list of contributed that won't be found on a standard site, might be used if needed
• Client training documentation--standardize it.