drupal commerce group-buy a case study disaster. in brief what could have saved us: client...

DRUPAL COMMERCEGROUP-BUY

A Case Study Disaster

IN BRIEFWHAT COULD HAVE SAVED US:

Client expectation management

More careful evaluation of dev

modules

Project size estimation

Intro

INTRO / DISCLAIMER

Please laugh, its all we could do in

the end

Let me know if you hated it / loved

it : [email protected]

Some project details are obscured

Intro

ON A DARK AND STORMY NIGHT

When entities were at the bleeding edge of

object oriented Drupal development

Drupal 7 had just gone gold

A tail of development woe begins

There were no winners

But I can tell you somewhat accurately how badly

we lost

Intro

OUR DUES

80 hours of project management

160 hours of development time

3 external developers managed

4 months of heart ache

2 heads banging repeatedly against a wall

Intro

TODAY’S MODE

I hate hubris

I will try not to ‘teach’

The way we learnt from this was to implement

systems

So that is how I will explain our lessons

But I will try to keep to the story

If you kill 3 projects … Win.

Intro

CLIENT EXPECTATION MANAGEMENT

DIRECT CLIENT COMMUNICATION

I will start with out biggest mistake

We never were in direct contact with our real

client

I now understand what it is like to be an Indian

developer

Out client was “The Sales Guy”

Client Expectation Management

THE SALES GUY

Well branded seemingly experienced design shop

owner

Sharp, well dressed, well versed in tech speak

Found us on a php mailing list

Presented us with “an opportunity”


OUR MISCONCEPTIONS

The sales guy was our technical communication

buffer

The sales guy would be our ongoing development

project faucet

The sales guy would care about our branding or

reputation


THE HARSH REALITY

Two sets of client priorities, one delivered second

hand

Duplication of our value proposition

Responsibility with no representation

Our brand took the blame

One massive ego with his client expectation

management on backwards


THE EARLY MOCKUP DISASTER

and other problems with transparency

THE 4T H PARTY

We contracted an Indian developer to do the PSD

to theme development

We opened up our development process to The

Sales Guy

In the first week they gave us a flat html template

mockup which sat nicely on top of Drupal

Pixel perfect front page, but no blocks or regions

THE 4T H PARTY

This is a great way to start INTERNALLY

The Sales Guy showed this to the client…

The client was Ecstatic

SITE DONE

Only a couple of pages to go!!!

“NO GOOD DEED GOES UNPUNISHED”

mid-project quotes

THE HOSTING SITUATION

The “Production Server” was:• A shared host• Had old versions of LAMP• Was in the US• Was slow

No Varnish

No Memcache

No APC


E-commerce Group Buy

Credit Card processing (PCI compliance)

4000 projected sales in the first day

We recommended a new server


The Sales Guy insisted on using a particular VPS

solution

We offered our installation services “at our normal

development rate”

The sales guy accepted via email


We installed a complex LAMP setup on a RHEL 5

server

We set up bespoke access and security

We optimized for Drupal

We forgot about it.

THE HOSTING SOLUTION

When we included it on an invoice he was

outraged.

“You suggested it” “I thought you only meant a

longer schedule” “It should be included in the

project price”

Expectation management fail?

THE HOSTING SOLUTION

At this point we were self doubting…

Does he live in a reality distortion field or did we

not engage in adequate client expectation

management?

We took this on the chin with these lessons:• Formal quotes for side projects• Invoice side projects early• Insist on production server specifications early

NOT THE DEV CODE!?

Near the middle of the project The Sales Guy chose to get

a third party developer to pronounce our code un-fit for

production

He had the developer login to our test server to look at

the code

We could have told him it was un-fit!

In this case he was being vexatious and hinting at

litigious to put us under pressure

NOT THE DEV CODE!?

At the time we laughed it off and set him straight

We know the developer and he didn’t get paid

It was at this point we should have switched from

expectation management to a hospital pass

EXPECTATION MANAGEMENT WORKS!

Except with The Sales Guy

BETTER PRACTICE

Bad news delivery intensity should look like a

nuclear decay curve

EARLY BAD NEWS

Give them bad news early

We want money for that job

Its going to cost you more than you thought and

here’s why

PS: Before we start we need that deposit in our

account

EARLY BAD NEWS

The bad news is that it is going to cost more than

you expected and a bunch of unexpected setbacks

will occur because of scope

mis-interpretation and expectation mis-matches,

which will blow out the schedule.

The good news is that we have created something

we can both be proud of, which includes all the

brilliant features.

OUR BAD NEWS CURVE

EARLY BAD NEWS

In the beginning the client usually is relaxed

It always seems a shame to spoil that, but:• They rarely have realistic expectations• They need to be tamed for trickier issues, which will

come later• This is the time to sort the low hanging fruit from

The Sales Guy

EARLY BAD NEWS

If there is no bad news, Great! But check these:• Did they pay the deposit quickly?• Are they treating your technical suggestions with

respect?• Are they quick to answer your questions?• Are any specification details given after the quote

unrealistic? We will get back to this…• Can you think of other universal bad client

indicators: [email protected]

MID PROJECT BAD NEWS

If mid project you are not hitting your own

development targets … tell your client

You will have a better idea of the real development time

If this is because of scope creep you will probably have

enough evidence to re-quote

If you re-quote and they want to terminate, see our

early termination clauses

END PROJECT BAD NEWS

This is the WORST!

The client remembers it bitterly

It makes you look the most unprofessional

It makes it tempting for the client to try to wriggle

out of the final payment … goodbye profit margin

THE EXCEPTIONS … MAYBE

A project changes course/goal

A major change request

A project scope change

REQUOTE!

THE CREDIT CARD SOLUTION

We thought we had learned our lesson

We were determined to handle any more change

requests by the book

Re-quote / Re-schedule / Under-promise


Original spec called for a completely integrated SOAP solution

We had suggested a payment processor

They had decided on a different processor

There was no existing Drupal Commerce integration

Asking for testing access from a processor is tricky when the

client doesn’t know your name.

Eventually we obtained a developer account from the

processor


The integration was working brilliantly when their

bank decided that they would only allow them a

merchant account if they used a hosted solution…

This change request came in two weeks before

delivery

The Sales Guy told us to put everything on hold to

get this working


We re-quoted

We re-scheduled, blowing out our launch date

We clarified that they wanted a hosted solution based on a

POST redirect

We clarified what “hosted”, “POST” and “redirect” meant

The Sales Guy agreed to the quote and assured us that

this was what they needed


We completed the solution and proudly showed The

Sales Guy within the beta site

He was pleased and took the solution to the

invisible client

They were not pleased.

Once again reverse client expectation management

was working against us.


The invisible client had never been told that there

would be redirection

They wanted all the magic to happen within the

bounds of their site and their branding…

At first The Sales Guy was apologetic

Then he insisted we should have implemented the

hosted solution as a frame!?


At this point knew he lived in a reality distortion

field

We are generally against frames, but it was late in

the project and we wanted to get paid

So we implemented.

And invoiced

And waited

LIVING ON THE DEV

DRUPAL COMMERCE IS AWESOME!

Disclaimer:• This is not a dig a Drupal Commerce• I love those guys• We have implemented DC successfully since

This is a criticism of our evaluation of using

particular dev modules

When Drupal Commerce got to 1.0 it still relied on

dev versions of modules

WHY DRUPAL COMMERCE?

DC seemed like the shortest way to OO Cart bliss

We had met the DC guys at Drupal Con and

thought they were awesome

We were planning many ecommerce projects and

wanted our developers and admin staff using the

latest and greatest

THE PLAN

The cart was very interface heavy

Planned out our data model then handed over to

the themers

We scheduled the business logic development later

in the project to co-inside with the planned stable

releases of DC

A PROBLEM

DC relied on the dev version of views and lacked

good reporting defaults.

Our more specific problem was tracking sales

Every group-buy site needs to show how many

sales have been made for a particular deal on the

front of the site

A PROBLEM

The Views 3 interface changed three times during

the project

Dev Views came with its own set of unreported bugs

The Rock: No obvious way to aggregate number of

completed Orders for a particular Product

The Hard Place: Creating a custom reporting

module might blow our budget

THE SOLUTION

We found a post on drupal.org describing exactly the same

problem

Ryan had posted acknowledging the problem, but was not ready

with an answer

We posted a possible solution

It turned out three other Drupal shops were having exactly the

same problem who promptly contacted us

Our compromise was to create a very simple custom field which

could be attached to the product entity

THE SOLUTION

We have published the module

This is not the definitive solution

The process which was most valuable was

communicating with the other Drupal shops about

requirements that should be considered and

approaches that could be tried

THE LESSON

We thought we could rely on a newly released

stable version 1 module with dev dependencies to

help speed up our cart development

We needed to more fully research the current

weakness of DC

DECISION FRAMEWORK

We now use these questions to help make the

decision to re-invent the wheel or to use an existing

module:• Are we building for reproducibility?• Is the module a more general form of the

functionality we need?• Do we need to build a sub-module?• Is it fully exposed to views with good defaults? • Is it entity driven?

DECISION FRAMEWORK

We now use these questions to help make the

decision to re-invent the wheel or to use an existing

module:• Who is developing it?• Have we tried it out?• How frequent are the releases?• How is the documentation inside and outside the

code?

DECISION FRAMEWORK

The group-buy project did require reproducibility

because we wanted to build other group-buy sites

Drupal Commerce is a general purpose ecommerce

framework, which is a super set of group-buy

We did end up needing a sub-module, but we didn’t

know we needed this until our scheduled was

pushed.

DECISION FRAMEWORK

Views was not well integrated at the time, which we did not

investigate properly

DC is entity driven which was important for our

customization plans

We knew the guys developing it

We had only tried it out on very basic use cases

The releases were frequent

The documentation was not thorough

WOULD I DO IT AGAIN?

Absolutely

If we had answered those questions first.

DEV MODULE PRO’S

Gripping an active development path

More active and relevant training for your staff

Active communication from the community

Developers are often reachable

You can contribute!

DEV MODULE CON’S

Views integration is rarely completed

Bugs are often unreported

You can not control design decisions or

development team losses

PROJECT SIZE EXPECTATIONS

THE FINAL STRAW

And other straws

THE ADMIN SOLUTION

Back in “Early Bad News” I asked:• Are any specification details given after the quote unrealistic?

The answer to this questions was be the project’s final

undoing

When we quoted we had been given a target price

When we wrote our requirements specification for the

quote we made assumptions

Ass meet you and me.

THE ADMIN SOLUTION

Late specifications are given all the time and are

usually negotiable

At the time of the quote The Sales Guy said that he

would have PSDs for us to guide development

When we first saw them we knew that they were

beyond the specifications he had given us.

But we knew we would be pretty close

THE ADMIN SOLUTION

When he demanded the front page be pixel perfect

we put it down to our early mockup mistake

But when he demanded style matching the

backend Drupal Commerce admin interface to the

front page we had serious reservations

We explained that Drupal’s strengths are layout

flexibility and active content

THE ADMIN SOLUTION

We had functionally completed the project.

This would require an additional 10 pages of

theming

At this point our attitude changed

We said that we would need our invoices paid before

this went ahead

This is where our journey ended.

THE ADMIN SOLUTION

I can not tell you much what happened beyond this

for legal reasons, but you already know the punch

line.

APPROPRIATE EXPECTATIONS

Our approximations in a table


Project Size Minimum number of payments

Under $10k 3

$10k - $50k 4

$50k - $200k 6

Over $200k Monthly


Project Size SLA (max phone or email reply time)

Under $10k 1 working day

$10k - $50k 12 working hours

$50k - $200k 6 working hours

Over $200k 2 working hours


Project Size Review Opportunities

Under $10k 2

$10k - $50k 3

$50k - $200k 5

Over $200k Monthly

QUOTE BASED ON EXPECTATIONS

People often come to us with a budget already set

in their head

Sometimes this must be turned around

Adjusting quotes for people with high expectations

is reasonable as an expert

Demanding clients end up asking for all the

optional extras at some point the in project

QUOTE BASED ON EXPECTATIONS

Does the client use phrases such as:• “I’m sure you will do that the right way”

Or are they saying:• “We really need to work from a budget”

As an example since the infamous project we changed

a quote from $400 to $2200 - the client took it well and

in the end it was exactly what it should have been

THE FOOD CHAIN

Our value proposition

VALUE ANALYSIS

If we had conducted a proper Value Analysis we

may have canned the project

The Sales Guy considered himself a:• Sales guy• Project manager• Reviewer• Mockup creator

VALUE ANALYSIS

Our core value propositions are:• Sales• Project management and technical communication –

key differentiator• Reviewing• Data modeling and business logic coding• Hosting

Where we were lacking at the time was:• Mockup PSD Design• PSD -> Theme development

VALUE ANALYSIS

He was taking more project dollars than warranted

his position

The value duplication was high

If we had thought of him as a partner rather than a

client we would have dropped the project

He promised us a stream of on-going work

What we didn’t realize is that we don’t want any of it

VALUE CRISIS

We sell, but he had sold

We had a good default interface, but he demanded

something else

We host, but he didn’t want hosting

We accepted him as a client based on ephemeral

outcomes of reputation and more sales

We had a core value crisis

VALUE PROPOSITION

Do you sell?

Do you create mockups?

Do you theme?

Do you model and code?

Do you host?

Do you manage projects well?

HIRE OR OUTSOURCE?

The eternal question

ESTABLISHED OUTSOURCING PARTNERS

Do they have a complementary value proposition?

Are they charging appropriately?

Are they delivering in a timely fashion?

Can you rely on them in a crisis?

Can they communicate technically and

professionally?

Australian vs India?

EXCUSES I HAVE HEARD

“The programmer responsible for your project is

on his death bed”

“We have been busy on other projects”

“No one works during Diwali”

“We didn’t understand your specification”

OPTIONS

No resort should be the last

CHUCK US THE BALL!

We have a list of alternate developers and their skill sets

We pass on projects if we think someone else has a higher

chance of completion

We try to develop in a way that allows a smooth transition

Some developers work for lock-in.

This is only useful in the wild west

Or with problem clients

We try to avoid both

THE HOSPITAL PASS

Find a partner who can manage late stage problem

clients:• High Quoting• Non-backstabbing• Knows how to be the last port of call

IN THE END…

We failed at Client Expectation Management

We hit all of the project requirements down to the

lowest specification in the quote

He still got litigious

Early in the project we should have realized it

would be a liability limiting exercise

We have since heard horror stories about him

FIGHT OR FLIGHT

We sort legal advice

We did the equation

We took heart

We settled

And we rejoiced!

THANKS FOR ATTENDING

Please send questions to [email protected]

drupal commerce group-buy a case study disaster. in brief what could have saved us: client...

Documents