2. Discovery Phase: Why
We’ve all been involved in one of these
projects at some point in our professional lives.
Often times it’s not clear as to how we got
there and in many cases it’s not any one
person’s fault.
As projects get larger and more complex, there
is inherently more risk for both client and
agency. Moving away from waterfall and
towards agile methodologies can help mitigate
the risk illustrated in this cartoon. but Creed
has also found that a defined “Discovery” phase
provides a consistently solid project foundation.
Image credit: http://www.tamingdata.com/2010/07/08/the-
project-management-tree-swing-cartoon-past-and-present/
3. Challenges and Successes of the Discovery Phase
Bottom Line: The Discovery Phase doesn’t
exist in a vacuum. The maturation of
Sales, Creative and QA processes are all
vital to the increasing actualization and
effectiveness of the Discovery Phase.
Challenges of a Discovery Phase
● Helping the client understand the
rationale for the expense and what
they will get out of it.
● Avoiding the “small = simple” pitfall
● Determining who leads/executes
● Defining Discovery objectives
● Defining deliverables
● Finding a way to scale the process
4. Key Objectives of a Discovery
● To help Creed better understand the
Client and their needs in a controlled
timeframe.
● To help the Client better understand
the scope and demands of the project.
● To set the tone of management,
establish expectations and build trust
● To identify risks and limitations
● To establish an agreed upon criteria,
against which success is measured.
Bottom Line: The Discovery Phase IS NOT:
● An interrogation
● A questionnaire
● A free-for-all exploration
● A time to start development on the
project
5. Key Characteristics of a Discovery
Identifies key
objectives and
risks
Produces lean &
purposeful
documents
Flexible
&
scalable
Facilitates meaningful
conversation and
empowers team
members
Bottom Line: The Discovery Phase provides a clear time boundary for
project definition and leads to more accurate estimates and work plans.
6. When do we do Discoveries?
Maintenance
Discovery
Project
(Fixed Bid)
A discovery phase can be appropriate at several points in a project’s lifespan.
Discovery + Project
(Time and Materials)
Sales
Discovery +
Proposal
Bottom Line: When there seem to be more questions than
there are answers, it’s time for a discovery.
7. The “Discovery Stack”
Business Objectives
Design/UX Requirements
Measure of Success/QA
● Content Requirements
● SEO Requirements
● Technology Requirements
● Functional Requirements
PM/Sales
QA Lead
Creative Lead
Lead Developer
Discovery Team
Bottom Line: Every Discovery should provide the
opportunity for each team to identify risks and gather the
info they need to be successful.
Discovery Owner
PM
Determines the
discovery objectives
and deliverables and
reports to PM
Discovery Plan
Frontend Developer Frontend Requirements
9. Discovery Deliverables
SAMPLE TOOLS
Google Docs, Sheets & Slides
SmartSheets
InVision
JIRA
Deliverables are:
Purposeful documents & assets that answer key
questions defined by the Client, Technology,
Design & QA
Defined by the discovery’s owner and supported by
the other team members involved
Shared with all necessary parties
Able to be used to make educated decisions about
next steps.
10. Discovery Activities & Deliverables
QA
Activities
● Goal planning with
client
● Competitor analysis
● Analytics evaluation
● Client’s site review
● Identify stakeholders
Deliverables
● Objectives documented in
specifications document
● Business strategy for web
presence
● Scope Document / Project
Charter
● Competitor Brief
Design/UX
SEO/Tech/Content
Business Objectives
Bottom Line: Activities and Deliverables will depend on the project’s needs
11. Continued …
Activities
● QA questionnaire
○ Risk tolerance
assessment
○ Define measures for
success
○ Determine functional
priorities
Deliverables
● Completed Questionnaire
● Testing Tier Document
● Testing Brief
QA
Design/UX
SEO/Tech/Content
Business Objectives
Bottom Line: Activities and Deliverables will depend on the project’s needs
12. Continued …
Activities
● Audience audit
● Review of inspiration
sites
● Brand assessment
● Competitor analysis
● Identify browser
requirements
● UI components
Deliverables
● Design & UX specifications
● Wireframes
● Brand recommendation
document
● Competitor analysis summary
● In-browser styleguide
QA
Design/UX
SEO/Tech/Content
Business Objectives
Bottom Line: Activities and Deliverables will depend on the project’s needs
13. Continued…
Activities
● Technology audit
● Content audit
● Platform
recommendations
● Server audit
● SEO audit
Deliverables
● Scope document and/or technical
specifications
● Technical audit of existing system
● Platform evaluations
● Content audit results
● Sitemap
● Prototypes
● Workflow/logic diagrams
● SEO strategy brief
QA
Design/UX
SEO/Tech/Content
Business Objectives
Bottom Line: Activities and Deliverables will depend on the project’s needs
14. At the end of the day
While flexible and project-specific, a discovery will
usually include the following deliverables:
● Charter Document
● Specifications Document
● Creative Brief
● Sitemap
● Content Audit
● QA Tier Strategy
Bottom Line: A proper discovery phase
produces a blueprint for success
15. The Charter Document
Charter Document: Description of features,
roles, deliverables and time tables that are/aren’t
included in the project.
Document Anatomy
1. Introduction and definition of project’s
goals.
2. List of deliverables.
3. Business rationale and the justification
of the project.
4. List of stakeholders and their duties and
responsibilities.
5. List of resources and limiting factors.
6. Time table for deliverables.
7. Risk analysis and management.
Bottom Line: A proper discovery phase can help
prevent scope creep
16. The Specifications Document
Technical Specification Document: This defines in
detail, acceptance criteria for a specific feature or
functionality. Typically our specifications include a
blend of technical and functional specifications.
● This should be drafted after a scope has been
determined.
● Might be supported by diagrams and
sitemaps
Bottom Line: It’s not always a fun read, but it’s our responsibility to make sure the
client understands the document.
Document Anatomy:
● Project Overview
● Definitions
● Design Specifications
● Technical Specifications
● Functional Specifications
● Administrative Specifications
● QA Objectives
● Deployment Requirements
● Post-Launch Support
17. Writing Conventions: Goals vs. Objectives
Goals: Something the client is working
towards. Think long-term & not
measurable
Objectives: Description of what is being
done that relates to a goal. Think short-
term, measureable, actionable, assignable.
Example
Goal: Enhance company brand impact.
Objectives:
● Create a logo with a stronger reflection of the
“All In” messaging
● Measure user brand awareness
● Create a new brand style based on survey results
● Implement new visual style elements on
website, app and intranetBottom Line: It may sound like just
semantics, but using a common
language helps with consistency and
efficiency
18. Documentation: In Review
Specification Document: Nitty gritty of technical
and functional requirements and criteria for
acceptance.
Charter Document: What’s included in the project
and how it will be executed.
Bottom Line: In a “project specific”
landscape, discovery documentation is
often more of an art, than a science.
However, having a common
understanding of purpose and process
will help us execute effective and
efficient discoveries.
Diagrams: Use standardized formats and styles
Stylistics: Write in present tense, active voice.
Formulate descriptions so they are specific,
actionable and measureable.
19. Future of the Discovery Phase
Make Discovery
Standard
Involve more
People
Template Library
Bottom Line: There’s always room for improvement
20. Contact
Presented by Renata France,
Senior Developer and
Architect
Creed Interactive
275 4th Street E #810
Saint Paul, MN 55101
info@creedinteractive.com
www.creedinteractive.com
Notas do Editor
I hope that what I show you today feels intuitive. It’s not that we don’t know and want to do these things, but in the first blush of a project it’s easy to get swept away by the desire/pressure to “just get working”
Most successful ones have been self contained
A discovery should be intentional and have an objective -- what is it leading us to?
Ownership has been a challenge, but hopefully with a better understanding of WHEN, we will have a better idea of WHO
So many options, does this really get us anywhere other than “it depends on the project”
For our purposes, this isn’t a document that records programming models and data schemas
