Every good project outline needs these nine ingredients:

• Audience
• Goals & Objectives
• Deliverables
• List of out-of-scope work
• Timeline & Milestones
• Budget
• Approval Process
• Change Control Process
• Ongoing Support Plan

Let's look at each of them in detail:

1. Audience
   • It's important to understand the target for this project so their opinion and experience (not the client's, not yours) can be kept front and center for every decision.
   • If possible, gather input directly from the target audience through direct interviews, surveys, structured user testing, casual observations, or analytics.
   • Key question: who is the target audience for this project?
2. Project Goals and Objectives
   • This is the success criteria for the project as well as why this work is necessary.
   • At minimum, you should be able to define the technical requirements, business requirements, and customer requirements—what the project needs, what the business needs, and what the customer needs.
   • Objectives are different from Goals.
     • A goal is the desired outcome for the project, e.g. "Make it easier for visitors to provide feedback."
     • An objective is the specific, actionable work to achieve a goal, e.g. "Make the visitor feedback form more prominent on key pages."
   • Key question: Why are we working on this project?
3. List of deliverables (the "in scope" work)
   • Deliverables are the tangible assets clients receive throughout the project. For example, when building a website the deliverables could include a project brief, wireframe, mockups, interactive prototypes, and the functional website.
   • Deliverables should be attached to milestones and payment markers.
   • Key question: What are the major deliverables needed for this project? (note: this requires many, many follow-up questions)
4. List of out-of-scope work
   • This is our first major preventer of scope creep.
   • This section describes anything not covered by the scope of work. For example, if you are building a client website, you may want to state that hosting services are not included once the website is live.
   • It is as critical to identify where the work stops so clients will not mistakenly assume you will complete work not accounted for in the budget or timeline.
   • Key question: what work will NOT be completed as part of this agreement?
5. Timeline & Milestones
   • A timeline helps clients understand when critical milestones will be delivered. It also establishes beginning and end dates for each milestone as well as the project on the whole.
   • Milestones represent important steps in the project, like key meetings, major deliverables, and external deadlines. These are often attached to payments.
   • It's best to present this as a bulleted list so it is easy to scan.
   • Key question: What external factors control the timeline?
6. Budget
   • Equate this to car shopping. If the budget is $10,000 it doesn't make sense to look at models that begin at $80,000. (Why I need to know your budget)
   • Key question: How much budget is available for this project?
7. Approval Process
   • Determine how progress will be reviewed and who will be providing feedback.
   • A Stakeholder RACI chart is a great way to identify roles and responsibilities for any task, deliverable, or milestone. RACI is an acronym for Responsible, Accountable, Consulted, Informed.
     • Responsible: the person directly in charge of performing the work.
     • Accountable: the person responsible for overseeing the work and ensuring its completeness.
     • Consulted: The person (or people) responsible for review and sign-off.
     • Informed: High-level participants who need to be aware of progress but are not directly involved in the project in any way.
   • Key question: Who are the key stakeholders and decision makers? Who has the final say?
8. Change Control Process
   • This is a second major preventer of scope creep. It is used to capture any new requests and determine if they should be completed as part of this project, a different project, a change order, or not at all.
   • Determine at the onset how work outside the scope of this agreement will be handled. The most common approach is change orders for new work that must be included within this project and secondary work phases under new agreements.
   • There is always a cost to change. Sometimes that cost is a change to scope, sometimes additional time, sometimes additional budget, and sometimes all three. All changes must be documented in writing so they can be referenced later.
   • A winning approach is to budget additional time for unknown work in order to make it easy to say yes to a few of these unplanned but inevitable change requests.
   • Key question: How should we handle change requests?
9. Ongoing Support Plan
   • What level of support is needed after the project is completed?
   • Will the client need help with production work, regular maintenance, or both?
   • Would they be served by a monthly retainer of production hours?
   • Key question: What level of support would you like post-launch?

Scoping Questions

The goal of a good scooping session is to uncover both the technical requirements as well as the business requirements for the project. Both of these should be governed by the customer requirements, otherwise the project will be destined to fail.

• Business requirements are what the business needs to succeed.
• Customer requirements are what the customer needs to succeed.
• Technical requirements are what the you (the project) need to succeed.

General scoping questions:

• Who is this project for?
• Why are we working on this project?
• What business problems are we solving?
• What customer problems are we solving?
• What does a successful outcome look like?
• What are our objectives and deliverables?
  • Ask follow-up questions about each objective or deliverable to ensure you understand it completely.
  • Be on the lookout for competing or contradictory objectives.
    • i.e. Situations where satisfying one objective makes satisfying another either difficult or impossible.
• What restrictions do we have or what hurdles do we need to overcome?
• How much budget is available?
• What external factors impact the timeline?
  • Uncover things that compress the timeline (e.g. external deadlines) as well as things that expand the timeline (e.g. holidays, PTO for key stakeholders, etc.).
  • Some common examples:
    • Trade shows or conferences
    • Grant deadlines
    • Mergers or acquisitions
    • Holidays
    • Customer schedules (e.g. back to school)
    • Sales cycles
• What is out of scope?
  • Identify features or dependencies that definitely will not be part of this project.
• Who are the key stakeholders?
  • Domain experts with background information
  • Decision makers
  • Maintainers
  • Content providers
  • Interested parties
• What level of support and training would you like post-launch?
  • Would you like help with production work, regular maintenance, or both?
  • Identify the levels of training the client staff may need to manage their own production.
  • Determine if the client will be better served by ad hoc support or a reserved set of production hours each month.
• Is a discovery phase helpful? (internal question)
  • Consider the unknowns left from this initial scoping process and decide if they are better answered by follow-up questions or a paid discovery/prototyping phase.