Business & Strategy · Maxime Topolov @mtopolov · 24 September
2013
DRUPAL FIXED BUDGET PROJECTS:
THE ART OF ESTIMATES
100 Drupal Experts
50 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 changesPerimeter misunderstanding or changes
Human factor
What do we need to
estimate ?
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 ...
Front-end complexity F1, F2, F3
F1 : Standard desktop output. Site is mostly blocs based, structure is
simple. No front-en...
Drupal & modules install and setup
S1 : 2 to 3 days
S2 : 4 to 7 days
S3 : 8 to 15 days
Couple of days to setup :
Redmine,
Users,
Mailing lists,
etc...
Page titles
URLS
ANALYTIC
S
AD
PANELS
MICRODATA
CONTEXT
S
SEO, URL, page titles, ads, analytics
S1 : 3 days
S2 : 5 days
S3 : 10 days
TEMPLATESTEMPLATES
why templates are so important
TasksTasks HoursHours F1F1 HoursHours F2F2 HoursHours F3F3
Sketching 1 2 4
Wireframes &
val...
Data migration
Data migration per content type
From Drupal : 1 day
From Structured DB : 2-3
days
From HTML : hell
EACH DEPLOY COSTs YOU $$$
Drupal Clouds* : 0,5 days
Capistrano like : 1 day
Old School : 3 days
* Acquia Managed Cloud, Co...
Tests & QATests & QA
how much you test ?
S1 : 15% dev days
S2 : 20% dev days
S3 : 25 to 30% dev
days
Management
how much time to manage
S1 : 10% dev+qa days
S2 : 15% dev+qa days
S3 : 25% dev+qa days
Specifications
How much specifications
S1 DaysS1 Days S2 DaysS2 Days S3 DaysS3 Days
Content types 2 4 7+
External systems 0 3 10+
Workflo...
Wait...
FEATURESFEATURES
User
Centric
RFPs
User centric RFP
Detailled presentation of features...
...but spreaded across several user stories.
You’ll need to be care...
Page
Centric
RFPs
page centric RFPs
Easy to count templates
You’ll need to be carefull with business rules (why this
magic bloc actually app...
Features List
RFPs
page centric RFPs
Easy to get features
You almost have to imagine the templates, contexts and
probably back-office feature...
COSTS
HIDDEN COSTS
Back-office clean up and theming
Workflow, notifications and user permissions
WYSIYWG setup, CSS clean up
Opt...
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...
BUILD PHASEBUILD 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
...
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
Shar...
Credits & Debits
how to manage change requests keeping
client happy
Credits & Debits
how to manage change requests keeping...
credits & debits doc
change requests take home messages
Being precise in the initial quote, makes life easier when you need to bill
changes
If ...
The STOP day.The STOP day.
Never ending acceptanceNever ending acceptance
avoid never ending acceptance
You do agile bla bla but yet you always have this final acceptance
period.
Acceptance must b...
Support & Maintenance
100 Drupal Experts
50 projects per year
@adyax
THANK YOU!
WHAT DID YOU THINK?
Locate this session at the
DrupalCon Prague website:
http://prague2013.drupal.org/schedule
...
Drupal fixed budget projets : the art of estimates
Drupal fixed budget projets : the art of estimates
Drupal fixed budget projets : the art of estimates
Drupal fixed budget projets : the art of estimates
Drupal fixed budget projets : the art of estimates
Drupal fixed budget projets : the art of estimates
Drupal fixed budget projets : the art of estimates
Drupal fixed budget projets : the art of estimates
Drupal fixed budget projets : the art of estimates
Drupal fixed budget projets : the art of estimates
Drupal fixed budget projets : the art of estimates
Upcoming SlideShare
Loading in...5
×

Drupal fixed budget projets : the art of estimates

4,085

Published on

Session given during the Drupal Con Prague 2013.

https://prague2013.drupal.org/session/drupal-fixed-budget-projects-art-estimates

In many countries accross Europe, websites projects are bought using fixed budget engagements from vendors.

RFPs we receive have often a very poor level of details, while client still wait for a fixed budget and timeframe.

During this session we'll present how we do at Adyax, bidding on fixed budget projects only to ensure that projects are always delivered and we get some money for it.

Session will cover several key points, like :

How to analyse and RFP and convert it to a Drupal Project Plan
How to count templates and related charges
Reading between the RFPs lines, detect those features that are not clearly described
How to avoid being the most expensive bidder by providing options
Some sharing about our estimation rules, tips & tricks
How to prepare a detailled planning
Important risks that can blow up your margins
In what Drupal is so different from others CMS / Frameworks
How to keep an eye, during the project on your margin
How to deal with change requests and evolutions
How to make your customer happy even when you ask them more money and/or time
10 usual mistakes that any Drupal Shop do.
Session will be supported with a set of concrete examples...

Published in: Technology
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,085
On Slideshare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
40
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide
  • Estimates are probably the most dangerous work a project manager do. Many projects are late, we even say that 70% of IT projects are late. Doing fixed budget projects, you may loose money.
  • Everybody here knows the scary deadline. Approaching. And most of the time deadlines are not met.
  • So after a while deadlines are not so dead and scary. Is meeting deadlines and make right estimates is really impossible ? After all, we're smart guys, you all here, you do Drupal, so you ARE smart. And we do crazy things. We do Panels, Views we even understand how to create a module in Drupal 8. We're experienced developers or project managers. But wait, you do estimates in every day life, and you do them pretty well. Imagine you're in Prague, with a good Drupal friend.
  • He call's you in here, and says wazaaaaa.... hum, says let's have a glass of wine in the best bar in Prague. He gives you the address and what do you do ?
  • You'll probably open google maps, check how to get there, time you'll need. Add some extra time in case of any unpredictable problems.And usually, you'll be on time.
  • Not always. Everyone here knows some friends who're always late. Actually what make us late, in every day life, are errors in estimates and unpredictable events.
  • If you want never being late, you should add risks and estimate impact of risks over your plan.
  • For example : how long will it take to get to my bar if there is a strike and I have to go there walking.But you should also estimate the chances of actually this particular risk will happen and apply this percentage to your estimates. With all possible events. The problem of this approach is that some risks have unfinite consequences on your journey.
  • As said Leo Rosten, "Some things are so unexpected that no one is prepared for them." But let's being honest, during a Drupal project you have a limited amount of events making your estimates going wrong :
  • The first thing your developpers will work on, is Drupal & modules setup and content structure definition. Of course depending of site complexity you'll spent more or less time. We do not try to go deeply in details. But you'll need time to install this bulk set of modules, you eventually can speed up the process going with a distribution.
  • This is an exactly example of hidden costs. You setup a ticketing system with your client, create user accounts, setup GIT repository, branches, install your developpment server or create a pantheon or commerce guys platform. But you'll spend time on this too.
  • Contexts, you'll have a lot of small work to do with contexts. SEO, Analytics tag plan, Advertisement, Page titles, URLs, all rely on context. More contexts you have more work you'll have to produce. I rember this client we got. Big french machines rental company, Kiloutou. While we were in last stages of project release, you know those 2 weeks sprints that lasts 2 months... well we asked this client to send us tags plan. Site was a 30 templates e-commerce site. We got a 70 pages specifications and 300 tags to implements on pages, but also on clicks, actions, and different checkout scenarios. God, we spent 2 weeks implementing it. So be careful with contexts related tasks as they are directly linked to the number of templates.
  • Now we'll talk about something very special. Something that from my point of view gives you the most accurate way to measure the site's size. The templates. Templates are so important because while creating a brand new website you will there are so many people and time used on each of them, it always freaks me out.
  • You start sketching the product page, you sketch in all 3 responsive versions, then you probably try to make validations, backs and forths with the client so you create 3 wireframes. Finally, after that your designer will produce PSDs (again to validate them with the client), finally you'll produce statics HTML of each template to test on so many devices you sold to your clients (yeah rember during the presales phase when you actually said that this responsive will work even on a Nokia 3310, they finally silently added nokia's support to the contract). Then your drupal developer will work on implementing it in drupal. Finally. Let's see some metrics. Those numbers are some kind of empiric values from 250 projects we've done so far in Adyax.
  • Very diffcult to estimate but usually you spend from 2 to 5 days per content type depending of the source easiest from Drupal to Drupal, then from a highly structured DB to Drupal, and finally the worse, from unstructured HTML (with those so easy structure, if you have a <P> tag put is as teaser, and then, always, promise, always a <strong> means sub-title, hum, yeah really really all our contributors try to respect those rules... since 5 years....).
  • Deploy is always a big debate. If you're running on Acquia, Pantheon or Commerce Platform you can almost do continuous integration stuff and each deploy will take you minutes. On more classical hosters it will depends of the deploy policy you've setup with your client. So alway take this in account at early stages of the project. I got a big customer and we agreed to deploy after each sprint, so we agreed on 12 deploys. The problem was the client was running his live environemnt with an old school very big hosting company, who deploy manually using a tar.gz files on an FTP. Making errors during each and arguing it was our fault. We spent 25 man days on deploys. But wait, we said that deploying on Acquia, Pantheon or Commerce Platform would take minutes, that's not exactly truth. Deploy means, write down release notes (export deployed tickets from redmine for example), prepare your features, write some module_update functions, test the deploy, and THEN deploy. It take time. Usually each deploy
  • I do wonder why developers do bugs. They do, and that's why we need testers. How many of you have dedicated test teams ? ... Actually that might be developers doing QA or dedicated, doesn't really matters. What we've actually noticed is that testing is directly related to developpment time. It takes from 15 up 30 percent depending of site complexity. I include and mix here manual and automated testing.
  • Here again many variants are possible. A freelancer project may not require any management at all, while a big project envolving 10 developpers may require several project managers. But again, even a freelancer does some management work. The hard thing in estimation of management is the fact that management efforts depend not only from the project, not even from the knowledge level of your team, but from the kind of the client you have.
  • You know I had a project, an invite only community site, and the client was like 5 persons without any knowledge of the web stuff at all. Thoses are usually spotted by us, but we don't know why we accepted this project and the nightmare lasted for several months... Like why the site is not opening when i enter the url [email_address] . Those kind of clients may make you loose money, if you can avoid them just do it. Best processes cann't nothing against human factor.
  • Do you write specifications ? For all of your projects ? Say the truth. I think that agile did a lot against specifications. Actually I think that specs are the most important thing that will save your margins. You can write specs at the begingin of the project, or do it sprint by sprint, but you need to describe entirely the project by specs. And make sure you validate them with the client. This is the only way to decide what's in the scope what's not, what's a bug and what's a feature. I think even small project need specs. And large project need specs being constantly updated as they'll also serve as project documentation. If you don't want to lose money, write specs for all projects.
  • But wait, guys. What about features.
  • I mean those things that make your project unique. There is not only modules and templates. There are a lot of business logic, small or complex features. There are no rules of estimate of those things. The only way is to divide the features into small parts, templates, find modules that you could use and try to estimate the time for each part. As for the rest, the more precise you'll be the more accurate will be your estimates. For example for a "voting feature" you should estimate how long it would take to install and configure Voting API, FiveStars, do the theming for the fivestars, add some custom blocs, theme them, test everything, apply updates on content types, etc...
  • Your project is live, client finished paying doesn't mean you finished spending money. The client will call you and while during the project it’s ok and probably included in specifications, project managemment and stuff. Once your project is live, how do you deal with support ? You guys once your project is live if the client calls you in ? Well the problem with the support is the fact that it’s so close to the commercial relationship you’ve setup with your client, so you cannot bill easily that. I mean you cannot say when the client has spent 6 month with you on the phone that you’ll not take his next call because he did not took the support. So the right thing to do is to prepare the client from the very beging of the project and explain your support policy. You can go for a global fixed annual price or a ticket based system, but the most important is to prepare you client from the begining of the project or even during the presales phase.
  • Drupal fixed budget projets : the art of estimates

    1. 1. Business & Strategy · Maxime Topolov @mtopolov · 24 September 2013 DRUPAL FIXED BUDGET PROJECTS: THE ART OF ESTIMATES
    2. 2. 100 Drupal Experts 50 projects per year @adyax
    3. 3. Forecasting & Estimates
    4. 4. 4 tasks job
    5. 5. "Some things are so unexpected that no one is prepared for them." -- Leo Rosten
    6. 6. Estimated by senior, done by junior
    7. 7. Perimeter misunderstanding or changesPerimeter misunderstanding or changes
    8. 8. Human factor
    9. 9. What do we need to estimate ? What do we need to estimate ?
    10. 10. 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
    11. 11. 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.
    12. 12. Drupal & modules install and setup S1 : 2 to 3 days S2 : 4 to 7 days S3 : 8 to 15 days
    13. 13. Couple of days to setup : Redmine, Users, Mailing lists, etc...
    14. 14. Page titles URLS ANALYTIC S AD PANELS MICRODATA CONTEXT S
    15. 15. SEO, URL, page titles, ads, analytics S1 : 3 days S2 : 5 days S3 : 10 days
    16. 16. TEMPLATESTEMPLATES
    17. 17. why templates are so important TasksTasks HoursHours F1F1 HoursHours F2F2 HoursHours F3F3 Sketching 1 2 4 Wireframes & validation 2 4 8 Design 4 10 16 HTML 3 6 16 Drupal templating* 8 12 16 SCARY TOTALS 18 24 60 * complete bullshit, since Drupal templating strongly depends on features
    18. 18. Data migration
    19. 19. Data migration per content type From Drupal : 1 day From Structured DB : 2-3 days From HTML : hell
    20. 20. EACH DEPLOY COSTs YOU $$$ Drupal Clouds* : 0,5 days Capistrano like : 1 day Old School : 3 days * Acquia Managed Cloud, Commerce Platform, Pantheon
    21. 21. Tests & QATests & QA
    22. 22. how much you test ? S1 : 15% dev days S2 : 20% dev days S3 : 25 to 30% dev days
    23. 23. Management
    24. 24. how much time to manage S1 : 10% dev+qa days S2 : 15% dev+qa days S3 : 25% dev+qa days
    25. 25. Specifications
    26. 26. How much specifications S1 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+
    27. 27. Wait...
    28. 28. FEATURESFEATURES
    29. 29. User Centric RFPs
    30. 30. 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...
    31. 31. Page Centric RFPs
    32. 32. 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 ?)
    33. 33. Features List RFPs
    34. 34. page centric RFPs Easy to get features You almost have to imagine the templates, contexts and probably back-office features would not be described.
    35. 35. COSTS
    36. 36. HIDDEN COSTS Back-office clean up and theming Workflow, notifications and user permissions WYSIYWG setup, CSS clean up Optimisations and architecture fine tuning
    37. 37. How to avoid being the most expensive bidder.
    38. 38. 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)
    39. 39. BUILD PHASEBUILD PHASE
    40. 40. What's measured improves
    41. 41. 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)
    42. 42. project ‘backlog’ Your quote data Actual project data
    43. 43. sprint ‘backlog’
    44. 44. 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...)
    45. 45. Credits & Debits how to manage change requests keeping client happy Credits & Debits how to manage change requests keeping client happy
    46. 46. credits & debits doc
    47. 47. 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)
    48. 48. The STOP day.The STOP day.
    49. 49. Never ending acceptanceNever ending acceptance
    50. 50. 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.
    51. 51. Support & Maintenance
    52. 52. 100 Drupal Experts 50 projects per year @adyax
    53. 53. THANK YOU! WHAT DID YOU THINK? Locate this session at the DrupalCon Prague website: http://prague2013.drupal.org/schedule Click the “Take the survey” link
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×