drupal commerce group-buy

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

Documents