Drupal fixed budget projets : the art of estimates

Business & Strategy · Maxime Topolov @mtopolov · 24 September 2013

DRUPAL FIXED BUDGET PROJECTS:

THE ART OF ESTIMATES

100 Drupal Experts50 projects per year

@adyax

Forecasting & Estimates

4 tasks job

"Some things are so unexpected that no one

is prepared for them."-- Leo Rosten

Estimated by senior, done by

junior

Perimeter misunderstanding or changes

Human factor

What do we need to estimate ?

S1 : Simple site : no authenticated trafic, less than 10 content types, less than 20 templates, no external data flow, no or simple workflow

S2 : Medium site : simple user related features like comments, voting, sharing, from 10 to 20 content types, from 20 to 50 templates, some simple XML data sources, workflow and custom business features, simple data migration

S3 : Complex site : transactional web site with high trafic (e-commerce, social network, intranets), more than 20 content types, more than 50 templates, many custom business logic and several complex data sources, advanced data migration

Site complexity s1, S2, S3

Front-end complexity F1, F2, F3

F1 : Standard desktop output. Site is mostly blocs based, structure is simple. No front-end animations, not much Javascript. No accessibility. No mobile support. IE10+, FireFox, Chrome & Safari support.

F2 : More advanced front end with a mobile version for some templates. Some basic front-end JS animations. Basic level of accessibility support. IE8+ is now supported too. iOS & Android last two versions support.

F3 : Full-responsive design with 3 break-points. Level 2 of accessibility support. IE6+ (degraded mode) support. Responsive tested in iOS, Android, Windows Phone, UC Browser, Opera mini.

Drupal & modules install and setup

S1 : 2 to 3 daysS2 : 4 to 7 daysS3 : 8 to 15 days

Couple of days to setup : Redmine,

Users,Mailing lists,

etc...

Page titles URLS

ANALYTICS

AD

PANELSMICRODATA

CONTEXTS

SEO, URL, page titles, ads, analytics

S1 : 3 daysS2 : 5 daysS3 : 10 days

TEMPLATES

why templates are so importantTasksTasks Hours Hours F1F1 Hours Hours F2F2 Hours Hours F3F3

Sketching 1 2 4Wireframes &

validation2 4 8

Design 4 10 16HTML 3 6 16

Drupal templating* 8 12 16SCARY

TOTALS18 24 60

* complete bullshit, since Drupal templating strongly depends on features

Data migration

Data migration per content type

From Drupal : 1 dayFrom Structured DB : 2-3 daysFrom HTML : hell

EACH DEPLOY COSTs YOU $$$

Drupal Clouds* : 0,5 daysCapistrano like : 1 dayOld School : 3 days

* Acquia Managed Cloud, Commerce Platform, Pantheon

Tests & QA

how much you test ?

S1 : 15% dev daysS2 : 20% dev daysS3 : 25 to 30% dev days

Management

how much time to manage

S1 : 10% dev+qa daysS2 : 15% dev+qa daysS3 : 25% dev+qa days

Specifications

How much specificationsS1 DaysS1 Days S2 DaysS2 Days S3 DaysS3 Days

Content types 2 4 7+External systems 0 3 10+

Workflow 0 1 5+User related

features 0 2 5+Back-office 1 3 5+

Front-end 3 5 15+SEO & Analytics 0,5 1 5+Data migration 0 4 15+

Search 1 3 5+

Wait...

FEATURES

UserCentricRFPs

User centric RFP

Detailled presentation of features...

...but spreaded across several user stories.

You’ll need to be careful with templates and site structure...

...and with SEO, Analytics, Contexts, etc...

PageCentricRFPs

page centric RFPs

Easy to count templates

You’ll need to be carefull with business rules (why this magic bloc actually appears on that particular page) and the back-office (you need a dashboard for that ? really ?)

Features ListRFPs

page centric RFPs

Easy to get features

You almost have to imagine the templates, contexts and probably back-office features would not be described.

COSTS

HIDDEN COSTS

Back-office clean up and theming

Workflow, notifications and user permissions

WYSIYWG setup, CSS clean up

Optimisations and architecture fine tuning

How to avoid being the most expensive bidder.

avoid being the most expensive

Be precise in your quotes. Describe exactly what you’ll do. Usual number of rows in a quote : 20 (S1), 50 (S2) or 100 (S3)

Add as much options as you can.

In case of unclear feature, take low level estimate and explain exactly what you’ll provide.

...or underestimate your build and bet on the run (dangerous strategy usually employed by big IT companies)

BUILD PHASE

What's measured improves

Redmine & timelogs

1 line in your quote = 1 super task in redmine

Any issue must be a subtask of a quote-based super task

Force everyone to log time daily (specially project managers)

project ‘backlog’

Your quote data Actual project data

sprint ‘backlog’

timelog take home messages

Everybody must log time

Keep the link between your initial quote and actual issues & tasks

Share estimates with developers & QA so they can warn you if you go out of scope.

Stick to the plan, even during panic periods. (Yeah, i’ll log my hours next week, we have a release now...)

Credits & Debitshow to manage change requests keeping

client happy

credits & debits doc

change requests take home messages

Being precise in the initial quote, makes life easier when you need to bill changes

If possible, don’t send many small bills but keep track of evolutions in a credit / debit shared doc

When doing evolutions quotes keep in mind that the price should include the dev of the evolution itself and the integration into the site (which actually may be more complex thant the feature itself)

The STOP day.

Never ending acceptance

avoid never ending acceptance

You do agile bla bla but yet you always have this final acceptance period.

Acceptance must be time boxed. You MUST define, with the client a precise period of acceptance.

Days / weeks before the release define with your client ‘blocker’ issues.

Explain to the client what happens during the guarantee period.

Avoid doing new not blocking features during the acceptance.

Support & Maintenance

100 Drupal Experts50 projects per year

@adyax

THANK YOU!

WHAT DID YOU THINK?

Locate this session at the DrupalCon Prague

website:http://prague2013.drupal.org/scheduleClick the “Take the survey”

link