Start tracking your progress
Trailhead Home
Trailhead Home

Create a Functional Project Plan

Learning Objectives

After completing this unit, you’ll be able to:

  • List three documents used in a project.
  • List three required project plan elements.
  • Explain how to create a project plan.
  • List three project plan milestones.

Introduction

Delivering a successful Salesforce B2C Commerce implementation is what it’s all about. If you completed the Salesforce B2C Commerce Functional Consulting and Salesforce B2C Commerce Client Analysis modules, you’ve already documented or collected material about the merchant’s existing system. Now you need to document the approach you plan to take.

As you create this documentation set, you should be able to quickly identify key elements that are missing. You should also be able to identify features that aren’t part of the B2C Commerce core feature set or configuration. Then you can advise on the feasibility of required customizations and their adherence to B2C Commerce best practices.

These are the documents you need.

  • Functional Project Plan—Outlines and tracks the functional aspect of the implementation.
  • Operating on B2C Commerce Checklist—Documents key areas such as merchandising, operations, administration, and organizational roles within the client organization.
  • Architecture Diagram—Documents the entire planned system, with an emphasis on data flows and formats.
  • Client Data Model—Describes the merchant’s data architecture.
  • Content Inventory and Control—Describes content assets and slots and assigns IDs to them in a logical fashion.
  • Storefront Reference Architecture (SFRA) Wireframes—Describes the standard page functionality of the SFRA so that the merchant can add customizations.
  • Integration Review―Documents the planned third-party integrations.
  • Functional Specification Document (FSD)—Documents in detail the planned storefront functionality, separating standard functionality from customizations.

This unit focuses on the functional project plan.

Client Discovery

The project plan is the first document your project team should consider. It underpins all other deliverables and ensures there are clear expectations within the various teams involved with the project.

Project plan required elements

It’s a good idea to document the project plan in a spreadsheet or planning tool so you can track progress. Include these required elements.

  • Timeline—Define phases in the project and their duration. Examples are discovery, documentation, development, testing, quality assurance, user acceptance testing, and performance testing.
  • Dependencies—Define which phases depend on completion of another phase before they can start. For example, you can’t create documentation until the merchant has completed the discovery phase and defined requirements.
  • Stakeholders—Define who is responsible for the different aspects of the project. Example stakeholders are project manager, technical architect, business sponsor, and developer.
  • Milestones—Define key moments in the project and set target dates. For example, a project plan can include the following milestones: discovery complete, development complete, end-to-end testing start, training start, and launch date.

Documentation

A typical project plan includes environment setup, integrations, and the functional aspects of the implementation, such as search and browse. It breaks the project into a distinct series of work packages, each of which contains subtasks, or milestones, that move the project along. Each subtask has a target timeline so you can track by subtask all the way to launch.

The order of the work packages defines plan dependencies. Each subsequent work package relies on the completion of the previous work package.

This is an example of a project plan structure. A real project plan also includes stakeholders and a timeline with bars for each task to track across the projected months in the project.

  • Work Package 1—Foundations
    • B2C Commerce Environment Setup
  • Work Package 2—Integrations
    • Systems Integration
    • Client Systems Integration Testing
  • Work Package 3—Search and Browse
    • Functional Specification Sign-off
    • High-Level Design Phase
    • Development
    • Test Scripts
    • Testing and Bug Fixing
  • Work Package 4—Product Page
    • Functional Specification Sign-off
    • High-Level Design Phase
    • Development
    • Test Scripts
    • Testing and Bug Fixing
  • Work Package 5—Basket and Checkout
    • Functional Specification Sign-off
    • High-Level Design Phase
    • Development
    • Test Scripts
    • Testing and Bug Fixing
  • Work Package 6—Static Page and Store Locator
    • Functional Specification Sign-off
    • High-Level Design Phase
    • Development
    • Test Scripts
    • Testing and Bug Fixing
  • Work Package 7—My Account
    • Functional Specification Sign-off
    • High-Level Design Phase
    • Development
    • Test Scripts
    • Testing and Bug Fixing
  • Work Package 8—Tagging, Email, and SEO
    • Development
    • Test Scripts
    • Testing and Bug Fixing
    • End-To-End Testing
    • End-To-End Testing Bug Fixing
  • Work Package 9—Launch Readiness and Data Migration
    • Go-Live Configurations
    • Data Migrations
  • User Acceptance Testing
    • User-Acceptance Testing
    • Bug Fixing
  • Go-Live
    • Go-Live
  • Post-Live Warranty Period
    • Post-Live Warranty Period

Project Plan Elements

The project plan spreadsheet has certain required elements. It’s important that you document them.

Timeline

Clock

The first required element is a timeline. In a typical project plan, the timeline is in months, and a bar chart for each element in the timeline spans the days or weeks as appropriate. The timeline is updated as each task is completed.

Dependencies

Checkmark

The plan dependencies are captured by the order in which the dependencies appear in the sheet. For example, work packages must be completed in the specified order.

Stakeholders

Stakeholders

The plan must explicitly name each stakeholder, so that team members know who is responsible for each step along the way. For example, Work Package 6, Testing and Bug Fixing, would have one or more names assigned to the task in the spreadsheet.

Milestones

Milestones

The sample structure uses standard milestones. Add more granular checkpoints such as discovery complete, development complete, end-to-end testing start, training start, and launch date if it helps your project.

Next Steps

You’ve seen the types of documents a functional architect needs to create and what details your functional project plan needs to include. In the next unit, we cover what a functional checklist is and why it’s important.

retargeting