Jumping Alligators: The Pitfalls of Planning


Published on

Every team or individual encounters pitfalls that attempt to derail the success of a project. Many times, theses pitfalls can be determined prior to encountering them. With proper planning, a team can take the appropriate measure to overcome any pitfall. In this session we discuss how planning starts during the estimation process and continues until the project is launched. Planning tasks that will be covered include; project estimation, feature specifications, use cases, wireframes, architecture, and build and release planning.

Published in: Technology, Business
1 Comment
1 Like
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Jumping Alligators: The Pitfalls of Planning

  1. 1. Jumping Alligators:The pitfalls of project planning<br />Presented by: James Polanco & Aaron Pedersen<br />D2W Conference 2011<br />
  2. 2. Who are these guys?<br />James Polanco & Aaron Pedersen<br />Co-founders of DevelopmentArc<br />Web Application Architects<br />Co-Authors of:<br />Adobe Flash Platform from Start to Finish: Working Collaboratively Using Adobe Creative Suite 5<br />Understanding the Adobe Flex® 3 Component and Framework Lifecycle<br />Understanding Flex 4 Component Development<br />Developers of Maque, Adobe WorkflowLab, Scion.com, Yahoo! Flickr Mail, and much more...<br />
  3. 3. Pitfalls of planning<br />
  4. 4. Common pitfalls<br />Budgets don’t allow for planning<br />Clients don’t understand why they should pay for planning<br />Clients often feel planning is already completed by their team<br />Budgets are defined before your involvement<br />Teams are worried they may lose the project, so we cut corners<br />
  5. 5. Common pitfalls<br />Estimation is done before planning<br />Estimation is often mistakenly considered the planning phase<br />Teams want goals before the problems are discovered<br />Clients want you to fix bid based on a rough sketch of what they want<br />We usually don’t really know what we want, yet we need to estimate how much it will cost<br />
  6. 6. Common Pitfalls<br />Excitement of a project buries planning<br />Clients are eager to start development and gloss over the planning process<br />Development teams (all disciplines) are eager to start doing what we do best<br />
  7. 7. Common pitfalls<br />Poorly implemented workflows give planning a bad name<br />“The problem with waterfall is it’s all about planning”<br />“We use agile because we can start developing right now”<br />“We already did all the planning we need... at the start of the project”<br />
  8. 8. Bad Planning Leads Too...<br />
  9. 9. Results of bad Planning<br />Scope Creep<br />Adding new features... is planning<br />But did you plan for it?<br />Estimation is done yet now we are adding new and unexpected features<br />Unexplored features are often bigger then we expected<br />Unexpected features lead reconsidering project milestones and goals<br />
  10. 10. Results of bad Planning<br />Over-budget & Overtime<br />More features = more time<br />More features = more resources<br />More time + more resource = more $$$<br />
  11. 11. Results of bad Planning<br />Conflict<br />Scope creep, budget bloat, extended deadlines cause unhappy clients<br />Poorly planned projects puts extreme stress on the development team<br />All work and no play, makes Jack a dull boy<br />
  12. 12. Tasks of Planning...<br />
  13. 13. Tasks of planning<br />Brainstorming<br />Brainstorming is a no-bounds or limit exercise<br />Allow the client (or you) to brain dump their vision<br />Include your team in this process<br />Create a two-way conversation<br />Defining Constraints<br />Understand time and budget limits<br />Prioritize time vs. budget<br />
  14. 14. Tasks of planning<br />Features<br />Define features based on brainstorming results<br />Prioritize features based on the defined constraints<br />Feature list should be organized into “must have”, “nice to have”, “if we can”<br />Technical Research<br />Define any technical unknowns that could impact constraints<br />Use this time to read up on and test technologies to understand their potential risk to the project<br />
  15. 15. Tasks of planning<br />Estimation<br />Estimate each feature individually<br />Organize based on priority<br />Always give a range of time (ideal vs. risk), not just a set number of hours<br />Budget for more planning tasks<br />Use case development, specification development, prototyping and wire framing<br />Budget for other non-feature specific tasks<br />Meetings, emailing, source control, environment setup, QA and deployment<br />
  16. 16. Tasks of planning<br />Use Cases<br />Create a set of use cases for each feature<br />Always consider non-intuitive uses<br />Use cases can be high-level or explicit based on the complexity of the feature<br />Specifications<br />Break features into clearly defined elements<br />Consider each element as a task that can be assigned during the project<br />This can be during sprints, iterations, backlogs, etc...<br />
  17. 17. Tasks of planning<br />Prototyping<br />Used to explore technical implementations<br />Used to explore usability<br />Used to explore different UX options<br />Used to gain quick feedback from clients and users<br />
  18. 18. Tasks of planning<br />Wireframes<br />Wireframes can come before or after the prototype process (or both)<br />Wireframes are visible representations of the feature specifications and use cases<br />Wireframes offer a workflow for client and team interaction<br />Wireframes can expose missing or unknown areas within the project<br />Catch it early, and plan for it... rather then later and pay for it...<br />
  19. 19. Real Stories...<br />
  20. 20. A bad scenario...<br />Misunderstood “Agile” project ran on fixed bid<br />Startup with grand (yet misunderstood) vision wants to launch yesterday...<br />Tight, three month-deadline, meant no time for planning<br />Inexperienced management team thought, “hey, let’s do this using Agile...”<br />
  21. 21. A bad scenario...<br />The Results<br />Project was 12 months late...<br />Multi-project managers were brought on and then let go during the project<br />Countless hours were given away for free to the client<br />Project team was disgruntled and had significant turnover<br />Client was pissed!!!<br />
  22. 22. A Slightly Better scenario...<br />Startup has a “big” idea<br />Wanted us to fix bid based on a 10 page slide deck of ideal features<br />They were all brief descriptions of what the features were<br />They wanted an estimate from us in a few days<br />There were huge technical challenges and unknowns with almost every feature<br />They had a 3-4 month window to complete before showing to egger investors <br />
  23. 23. A Slightly Better scenario...<br />The Results<br />We told them no... at least not without some research<br />We created a planning strategy to develop an estimate for the project<br />Technical Research -> High-level Feature Spec -> Estimate of cost<br />This estimation process cost us about 20 hours of unpaid time<br />
  24. 24. A Slightly Better scenario...<br />We didn’t get the project...<br />The client saw the project was way larger then they initially understood and took a different approach<br />We were actually happy to lose the 20 hours vs. committing to a project we didn’t understand<br />This ended up saving us hundreds of hours and a metric shit-ton of money<br />
  25. 25. How much time?<br />
  26. 26. How Much time?<br />More then you think...<br />Alan Cooper said (paraphrasing):<br />“Don’t ask me how much the project will cost. Ask me how much it will cost you to have me tell you how much the project will cost...”<br />
  27. 27. Convincing clients...<br />
  28. 28. Convincing clients...<br />Have planning and analysis as a separate contract<br />This is the Alan Cooper approach<br />Can save the client a ton of cash and energy<br />Gives the client a well-thought out strategy for achieving their project’s goals<br />We recommend that this is process is hourly-based, which can lead into fixed bid<br />Gives you and the client something to return to throughout the project<br />
  29. 29. Convincing clients...<br />Give your clients better insight<br />Help them understand the size and complexity of their project<br />Keep them involved at each step of the planning to understand what, and most importantly, why you are doing it<br />Allows for easier explanation of how “changing features” impacts the project<br />
  30. 30. Planning never stops...<br />
  31. 31. Planning never stops...<br />Projects are continually evolving<br />Features will change, it’s okay... this makes the project better in the long run<br />Continue to update your documents to reflect any change<br />Use project constraints to limit unnecessary (or unreasonable) change<br />Prioritize change, with the understanding that something has to give to stay within the constraints<br />We can’t catch everything up front, so budget for future unknowns<br />
  32. 32. Q&A<br />
  33. 33. Thanks!!!<br />Understanding Flex 4 Component Development<br />http://bit.ly/ptJLhC<br />Adobe Flash Platform from Start to Finish: Working Collaboratively Using Adobe Creative Suite 5<br />http://amzn.to/r0eqFs<br />Adobe Flex 4 Component Development Training (August 10th)<br />http://bit.ly/nb5ikl<br />Download Maque Beta 3:<br />http://maqueapp.com<br />