Building Results Oriented Websites: The Method That Ends the Madness

916 views

Published on

Content Management Systems gives you a huge tool box to deliver features. As CMSs accelerates the development cycle, the question changes from “How do we build sites?” to “What should we build?” This session presents the strategies and methodologies we have learned and used over the last 12 years to build results driven websites.

For decades the gold standard for measuring project success has been the project management iron triangle: on time, on budget, on scope. Despite increasingly more rigorous planning strategies, the average project is still 45% over budget, delayed by 63% and missing 1/3 of the promised functionality.
Worse yet, this obsession with certainty is reducing quality, innovation and value while burning out web development teams - and things are only getting more difficult.

A new way of thinking is needed to build truly successful projects. This session presents modern strategies and methodologies that have continually proven to beat the averages. We will review the latest research and advice from the world’s foremost software engineers. The session will conclude with a breakdown of the innovative methodologies that drive the majority of the world’s leading websites.

This session is for anyone looking to build more successful projects. Project owners will learn how to drive innovation, faster and with less cost. Your development team will learn how to continually deliver better work with less stress and long weekends.

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

  • Be the first to like this

No Downloads
Views
Total views
916
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Whenever I present I always like to get a feel for who is in the room.How many people here are owners of Drupal website?How many are builders of Drupal websites?How many are thinking about getting into Drupal?How many have done SEO on a Drupal site?How many people are new to Drupal SEO?How many people don’t even know what SEO is?
  • You might be saying wow that is a lot of planning. Why is it important to do that planning
  • So the question is how to you get to the top of the food chain?[do the speel]
  • So the question is how to you get to the top of the food chain?[do the speel]
  • There is a
  • So the question is how to you get to the top of the food chain?[do the speel]
  • All of this power and flexibility does come with a cost, Drupal can be very complex and comes with a learning curve. The Open Enterprise distribution greatly simplifies the common things businesses and organizations want to do with Drupal.
  • Install DAMP, import OE Core
  • This is how a traditional process for building a website. Or I should say, this is how a traditional website is supposed to be planned. Many larger sites are planned this way, but often to save cost steps might be skipped.
  • Our first web project at LevelTen back in 1999 was truly a big design up front. Planning took 6 months. Numerous meetings, interviews, surveys, user focus groups, wireframes, UML based functional specs.
  • Then then 2001 recession hit. People no longer wanted to spend six figures on project planning. The shift was on to compressed planning phases. I call this mid design up front. The primary focus of MDUF was quickly gathering the stakeholders requirements and engineering just enough to get a reasonable estimate for budgets and timelines.
  • So here is the typical project. Stakeholder recognizes that people like Facebook. Thinks, ah ha, what if we had a company extranet like Facebook, people would like us. Puts together a few pages of things facebook does, mashes in some linkedin, Twitter, and YouTube. Sends the project out for bit to a half dozen companies.
  • So how successful do you think these the big and midsized design up front process was at brining projects in on time, on budget, and in scope?[show slide]Pretty horrible. The average project is 45% over budget, 63% late and missing 1/3 of the originally promised features.…We already know that we are not getting long term value from the certainty we are generating. But it turns out that we are not even getting certainty. Which of course means we are spending time that is actually just a waste.
  • There is another significant problem with traditional waterfall processes. We force stakeholders to make the big decisions when they know the least amount about the best solution. So certainty also means that stakeholders get less of what they want.So how do we fix these problems? How do we get better certainty in our projects with more accurate estimates, understand better what the stakeholders want? More planning right?
  • Install DAMP, import OE Core
  • Agile processes are
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • There is a general perception that website requirements are something that exist somewhere out in the ethos and all we have to do is go out and gather them. The reality is that not all requirements are known at the beginning of a project. Most certainly not the best ways of build things is understood at the beginning of a project.The process we are going to use for rapid, light-weight requirements gathering is like trawling for fish. We start by casting out a wide net with a wide mesh. We are looking to quickly capture the big, most important requirements. We can then later use a finer mesh net to capture more detailed requirements.The important thing to remember is that agile requirements are not something that is done once at the beginning of a project and set in stone. The are revisited periodically throughout the project and iterated over. Don’t waste time adding details till just befom you really need it.Robertson and Robertson (1999) from User Stories Applied p 43
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • It powers some of the world’s top websites such as whitehouse.gov, The Economist and Examiner, all of Sony / BMG’s mission websites.
  • [photo: http://www.flickr.com/photos/missnita/509719978/]
  • Building Results Oriented Websites: The Method That Ends the Madness

    1. 1. Nov 19, 2011 Building results-oriented web projects [MM.DD..YY] [PRESENTER]Building ResultsOriented Websites:The Method thatEnds the Madness flickr.com/photos/cuppini/2719863711
    2. 2. Why do we plan? Stakeholder utility • Look and feel • Features Certainty • On time • On budget • In Scope End user utility • Emotional branding • Content • Features • Usability & Experience Organizational returns • Increased revenue • Reduced cost • Increased goodwill
    3. 3. 5 years from now A B C Features Certainty User delight Org. value
    4. 4. What is a results oriented website flickr.com/photos/ncreedplayer/5403123930 flickr.com/photos/masoncooper/456641277
    5. 5. Why should we plan?1. Maximize organizational returns returns2. Optimize user user experience experience3. Reduce waste stakeholder utility certainty waste
    6. 6. Traditional web development process • Concept • High-level requirements Requirements • Requirements gathering • Requirements spec planning • Product (UI) Design • Wireframes Design • Detailed Design • Functional specs • Creative design Implementation • Content • Development development • Unit testing Verification • Acceptance testing • Beta testing live Maintenance
    7. 7. Big Design Up Front6 months returns user $ experience stakeholder utility certainty waste
    8. 8. Mid Design Up Front6 weeks returns user experience $ stakeholder utility certainty waste
    9. 9. Fumbling towards estimates
    10. 10. The McCracken Uncertainty PrincipleThe higher the feature velocity of aproject, the less precise theresources needed can be predicted
    11. 11. Planning for certainty = certainty no long term value = certainty wastesource: blogs.msdn.com/b/dannawi/archive/2009/05/15/2009-standish-chaos-report-we-are-successful-in-the-failure.aspx
    12. 12. Getting what you want vs. knowing what you want Freedom to innovate =certainty less value innovation = $ Insight to innovate value more money time high level design & mockups validation live requirements architecture
    13. 13. Where to go Mid DUF Big DUF Agile certainty value waste cost $ $ $
    14. 14. A better approach waterfall agileRequirements website Requirements features 6 months 2 weeks Design Design Implementation Implementation Verification Verification
    15. 15. Project management methodologies comparison Cowboy Agile WaterfallRequirements Little formal Lightweight, Very formal Big requirements structured Design Up FrontOwner - team Usually fixed bid, Typically fixed Initially fixed bid byAgreements poorly defined budget or fixed stages. Modified by scope. scope – value based change orders.Owner – team Undefined Collaborative ContractualrelationshipOwner – team Whenever Cycle every 1-4 At majorcommunication weeks milestones. May be months apart.Improvement Whatever Discussed each Formal changechanges requests cycle – better ideas order process built easily integrated to resist changeRisk management ??? Adaptive - by doing, Predictive – by inspecting and planning adapting
    16. 16. Light weight planning2 weeks returns user experience $ stakeholder utility certainty waste
    17. 17. Results oriented light weight planning4 weeks returns user experience $$ stakeholder utility certainty waste
    18. 18. The plan agile project more management stuff online resultsresults oriented the user-centered right planning stuff a.k.a more of the right stuff
    19. 19. Process Models based • Light weight • Iterative • Comprehendible by everyone • Synchronization • Collaboration Types of models • Results models • User role models • User stories • Interface models Participatory workshops • Rapid • Comprehensive • Synergistic • Consensus
    20. 20. Results modeling ProcessDefinition: • Brainstorm •the benefits stakeholderswant to achieve with the Organizesite. • Consolidate & refine • Prioritize
    21. 21. Results modeling: types of results models objectives valued goals events
    22. 22. Results modeling: brainstorm increase bike The site should Reduce routine Staff should be sales have a clean and customer call able to add and professional look inquires by 50% edit content become a Be more viral Sell more bike Expand our recognized leader repair services digital footprint in the local biking community Show the To increase Sell more bikes Get 500 “Likes” pictorial history traffic to the site online on Facebook of results bikes The site should Increase bike Double our Visitors should be be intuitive and rentals by 100% mailing list able to find what easy to navigate they want in no more than 3 clicks
    23. 23. Results modeling: organize increase bike Increase bike The site should sales rentals by 100% have a clean and professional look Sell more bikes online The site should Reduce routine be intuitive and Show the Sell more bike customer call easy to navigate pictorial history repair services inquires by 50% Visitors should be of results bikes able to find what they want in no more than 3 clicks To increase Staff should be become a able to add and traffic to the site recognized leader edit content in the local biking community Be more viral Expand our Get 500 “Likes” Double our digital footprint on Facebook mailing list
    24. 24. Results modeling: consolidate Goals Objectives Valued events Features Show the increase bike To increase Increase bike pictorial history sales traffic to the site rentals by 100% of results bikes Staff should be become a Sell more bike Reduce routine able to add andrecognized leader repair services customer call edit contentin the local biking inquires by 50% communityThe site should Sell more bikes Double ourbe intuitive and online mailing listeasy to navigate The site should Expand our Visitors should behave a clean and digital footprint able to find whatprofessional look they want in no more than 3 clicks Be more viral Get 500 “Likes” on Facebook
    25. 25. Results modeling: refine Goals Objectives Valued events increase bike Increase by sales Bike purchase sales by 50% a month Value = 40% of within 6 months the retail price
    26. 26. Results modeling: prioritize Primary Secondary Tertiary increase bike Expand our Be more viral sales digital footprint Sell more bike To increase Sell more bikes repair services traffic to the site online become a The site should The site should recognized leader be intuitive and have a clean and in the local biking easy to navigate professional look community
    27. 27. User role modeling ProcessDefinition: • Brainstorm •a collection of definingattributes that characterize Organizea population of users andtheir goals, needs andintended interaction with • Consolidate & refinethe site • Define • Prioritize
    28. 28. User role modeling: brainstorm local newspaper people from out bike shoppers job seekers of town sports blogger fans person who new mom/parent wants to upgrade their bike website staff competitive rider casual bikers administrator hotels that need new bike rider bike owners tour guide bikes for guests
    29. 29. User role modeling: organize local newspaper person who staff wants to upgrade sports blogger their bike website administrator fans bike shoppers new mom/parent job seekers people from out of town bike owners hotels that need competitive rider bikes for guests casual bikers tour guide new bike rider
    30. 30. User role modeling: consolidate & refine enthusiasts shoppers staff local newspaper bike shoppers staff sports blogger new mom/parent website administrator fans person who wants to upgrade their bike renters owners job seekers tour guide bike owners job seekers people from out casual bikers of town new bike rider hotels that need bikes for guests competitive rider
    31. 31. User role modeling: define Demographics owners • Age: 25-55 • Gender: 65% male • Location: within 10 miles of store Psychographics • Active lifestyle • Prefers being outdoors • Green Behavioral • Significant web usage including search engines and social media • Research purchases online before buying • Significant use of mobile devices Brand • Custom service is significant driver for brand loyalty • Likely to buy again from same store. Typically 1 bike every 4 years. Site • Proficient web user • Likely to have high speed internet access
    32. 32. User role modeling: personas renter
    33. 33. User role modeling: prioritize Primary Secondary Tertiary shoppers enthusiasts job seekers renters staff owners
    34. 34. User storiesDefinition: Processdescribes a features andfunctionality of the site from • Brainstorm • Organize & refinethe viewpoint of a user role • Prioritize
    35. 35. Trawling for requirements
    36. 36. User stories: format As a [user role] I want [a feature or goal] so that [a benefit or reason] * so that is optional A user story is a documented requirement and a note to discuss later
    37. 37. User stories: brainstorm As a Bike Enthusiast, I would like to • read the latest bike shop news/blog • comment on the blog • share content through email and social media • see a calendar of events, classes, races • sign up for newsletter and alerts • see special offers • get contact information • see location and hours of operation
    38. 38. User stories: prioritize MoSCoW approach • Must haves – we need these stories in order to launch the project • Should haves – these are of high importance, but are not show stoppers for the next release • Could haves – If we get a couple of these in it would be nice, but they can be moved easily to the next release • Wants – These are not a priority but we want to keep track of them as possibilities for future releases.
    39. 39. Interface modelsDefinition: Common interface modelsgraphical or organizational • Navigation architecture & mapsrepresentation of siteelements and how they • Content modelsrelate to each other • Wireframes and prototypes • Design comps
    40. 40. Interface models: wireframes
    41. 41. Summary 1. Don’t obsess over certainty, you will get more done. 2. Software is for the end users, get out of your head and into theirs 3. It is about benefits, not features. Results should be a continual focus.
    42. 42. all-in-one results oriented website A results oriented website in a box* *box not included For organizations age 0 to 150 Super secret D7 version: http://apps.leveltendesign.com
    43. 43. thank you!Tom McCrackenLevelTen InteractiveDirectorPhone: 214.887.8586Email: tom@leveltendesign.comTwitter: @levelten_tomBlog: leveltendesign.com/blog/tomLinkedIn: linkedin.com/in/tommccracken

    ×