Project Documentation: Astro360 Salesforce Case Study

Following from our introduction to the Astro360 project, this is the second article in the Astro360 Salesforce Case Study, a fictional account of how AstroLift used Salesforce to manage their customer relationships in the most cost-effective way by putting them at the centre of everything they did.

A Product Backlog

Nel, the Product Owner, has asked the Arcturus team to spend a few weeks during the coming up with the documentation needed to set the CRM project stream up for success. He’s asked them for:

  • This is a set of functional requirements that the Salesforce system will be expected to provide
  • These requirements will be broken down into epics, user stories, and tasks that summarise what the future state solution will do, and will be stored as cards on a kanban board
  • As-is and To-be Process Maps should be developed and attached to the relevant epic or user story card, to capture personas, systems, actions, and data required in a process
  • Dependencies should be identified:
    1. between epics and/or user stories relating to in-system Salesforce development
    2. between between epics and/or user stories relating to development required in systems upstream from Salesforce
    3. between between epics and/or user stories relating to development required in systems downstream from Salesforce
  • Requirements traceability will be maintained on each card, making it clear which part of the AstroLift business requested a given feature and allowing for cost/benefit analysis down the line
  • The Product Owner or his proxy should provide delivery prioritisation on each card using the MoSCoW method
  • Each user story will have an order of magnitude effort estimate, quick solution notes, and an indication of what development skills will be needed
Salesforce Project Documentation
Klaus sometimes likes to sketch out his project documentation before putting it into the final documentation to present to the client

A High Level Design Overview

  • This document is an overall description of the vision, business problem statements, and target business outcomes for the project
  • It will describe the Salesforce solution as it relates to the current state, transitional state, and future state architecture, and the architectural considerations to be addressed during the project
  • It will describe in-scope and out-of-scope features for the Salesforce project stream
  • This will guide the Salesforce and wider project development teams and give them context to know what the technical aspects of the system will be delivered
  • It will be a living document stored on an online workspace, updated regularly as architectural decisions are made throughout the project
  • This document can contain diagrams such as

A Project Management Plan

  • This document sets the outline of how the team will work together across the streams, and operational procedures specific to the CRM stream
  • A Project Governance Approach to outline project stream roles and who is responsible for what
  • A Risk Management Approach to manage and mitigate project stream risks
  • A Quality Management Approach to ensure what is being built lines up with what’s required, including processes for
    • Unit testing
    • System testing
    • User acceptance
    • Bug fixes
    • New feature requests
  • A Change Request Approach to manage scope, stream cost, timelines and the approval of change requests
  • Communication Management Approach to ensure relevant stakeholders are kept appropriately informed on project stream progress
  • An outline of project phases, sprints, estimated timelines and releases
  • An outline of required CRM stream resources and personnel, with an estimated cost for the stream team

After a quick conversation between the CRM stream team, Klaus has volunteered to take responsibility for the backlog, Ernie the Solution Design Overview, and Frankie the Project Management Plan

A RACI matrix on the Discovery phase deliverables to show the roles involved with each

In the next post we’ll see how Klaus went with putting his Product Backlog together.

Leave a Reply