Before we begin, could we please re-iterate that projects and tickets are not the same! A ticket may give rise to a project (and often seems to do so in the NetSuite world), but if you do not separate your tickets from your projects, you'll find yourself in quite the mess. This is a long one. You might want to just skim through and review the graphics! # Types of Projects - NetSuite Implementation - Initial implementation: Bringing all pertinent business processes into ERP across an entire (or most of a) business - Business Unit Onboarding. Brining a new business segment into NetSuite - Business Process Optimization - Bringing a process previously scattered across multiple systems into a single system (NetSuite) - Support for a modified (enhanced) business process within NetSuite. # Roles and Responsibilities Define who is filling each of these roles in your project. A clear definition of roles and responsibilities can be the difference between project success and project failure! | Role | Description | Responsibility | | -------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Project Sponsor | The person who wants a thing done. Sometimes also a stakeholder. | Define goal/desired outcomes. | | Project Manager | The person making sure things get done. | Align stakeholders and resources.<br>Ensure proper documentation across entire project.<br>Ensure desired outcomes are met. | | Project Stakeholders | The people affected by the project | Define requirements.<br>Validate results of project. | | Project Resources | The people getting things done | Do the work. Meet the requirements. Train the stakeholders. | # Project Phases ![[NetSuite Support Process - The NetSuite Project Process.jpg]] 1. Initiation 1. Project Plan 2. Initial requirements 2. Iterations (cyclical) 1. Requirements 2. Design 3. Configuration 4. Validation (Training and UAT) 3. Go-live & Review # Project Activities Understanding what happens during a project and who is responsible is critical for getting a project done. When you don't know who is responsible, it's difficult to push in the right spot. | Activity | Responsible Party | Phase | Document | | ----------------------- | --------------------------------------------------------------- | ------------------------- | ----------------- | | Project Planning | Project Manager (with Project team, especially Project Sponsor) | Project Plan | Project Plan | | System Design | Project Resources (with Project Stakeholders) | Iterations | BRSD | | System Config | Project Resources | Iterations | NetSuite | | User Training | Project Resources (to Project Stakeholders) | Iterations | User Guides | | User Acceptance Testing | Project Stakeholders (with help from Project Resources) | Iterations | UAT Documentation | | Requirements Gathering | Project Resources (from Project Stakeholders) | Initiation and Iterations | BRSD | | Write UAT scripts | Project Stakeholders (with Project Resources) | Iterations | UAT Documentation | # Project Documents ("Artifacts") Project documents serve as the hub for all knowledge about a project. If a meeting occurs without significant advance in the writing of one of these documents, that meeting was a waste of everyone's time - you've got to document everything! | Document | Purpose | | ------------------------------------------------- | ----------------------------------------------------------------- | | Project Plan/Charter | Enable smooth project executions | | Business Requirements & Solution Documents (BRDs) | Guide system design and configuration | | User Guides | Immediate user training<br>Future Reference | | UAT Documentation | Document how stakeholders will validate successful configuration. | Where do Change Orders fit in? They don't! These documents are LIVING documents. Iterate on them. Don't duplicate them - just update them. Use software that shows revision history (in case anyone is ever REALLY interested in an older version). Do this throughout the entire life of a project. ## Project Plan Whatever the type of project, you need to track certain things. Each of the below sections of a project plan are important: without any one of them, you may decrease your chances of project success. You ***can*** put N/A in a section or leave some boiler plate text, but doing so does introduce a risk to the project. With each section you do NOT complete clearly and accurately, the risk of project failure increase X amount (X is intentionally left as X due to lack of real stats). You can create a template document with these sections or just create this once and duplicate the page every time you have a new project. Note one section you might think is missing - the requirements section. You'll want to create separate [[Business Requirements Documents]] (BRDs) for each major section of the project (the BRD will likely be your first milestone). If you're running a NetSuite implementation project, you should have multiple major sections, the same applies if you are running a large NetSuite project. A smaller project may have just one or two BRDs. **Quick Tips:** - Use AI to write the the initial draft - Ruthlessly modify AI output to make it accurate and clear (cut out fluff) - Shoot to generate this first draft within 1 hour - Schedule a meeting with your supervisor or team to collaboratively finalize the Project Plan ### Sections (ChatGPT) | Section Title | Purpose | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Executive Summary | Provides an overview of the project, including its objectives, scope, and high-level approach. This section is aimed at stakeholders and provides a concise snapshot of the entire project. | | Project Objectives and Goals | Clearly defines the project's purpose and what it aims to achieve. It includes specific, measurable, achievable, relevant, and time-bound (SMART) goals. | | Scope Management | Details what is included in the project (in-scope) and what is not included (out-of-scope). This section helps manage expectations and prevent scope creep. | | Project Deliverables | Lists the tangible outputs or products that will be delivered upon project completion. Each deliverable is typically associated with a specific milestone. | | Project Milestones and Timeline | Defines key milestones or significant points in the project. It includes a timeline or schedule showing the start and end dates of tasks, dependencies, and key deadlines. | | Work Breakdown Structure (WBS) | Breaks down the project into smaller, manageable components or tasks. This hierarchical decomposition helps in better resource allocation and task management. | | Resource Management | Identifies the human resources, materials, and equipment required for the project. This section may also include roles and responsibilities, as well as a resource allocation plan. | | Risk Management Plan | Identifies potential risks, their impact, and the likelihood of occurrence. It outlines mitigation strategies, contingency plans, and risk management processes. | | Communication Plan | Specifies how information will be communicated to stakeholders, including the frequency, methods (meetings, reports, emails), and responsible parties. It ensures transparency and effective information flow. | | Quality Management Plan | Defines quality standards, control measures, and quality assurance processes to ensure that deliverables meet the required standards. | | Cost Management and Budget | Details the project's budget, including cost estimates for resources, materials, and other expenses. It also outlines how costs will be tracked and controlled. | | Stakeholder Management | Identifies stakeholders, their interests, influence, and involvement in the project. This section outlines strategies for engaging and managing stakeholders effectively. | | Change Management Plan | Provides a process for handling changes to the project scope, timeline, or resources. It includes guidelines on how changes will be documented, reviewed, and approved. | | Procurement Plan | If applicable, details how goods and services will be procured, including vendor selection, contract management, and procurement timelines. | | Monitoring and Control | Describes how project progress will be tracked, monitored, and controlled. This section may include key performance indicators (KPIs), reporting mechanisms, and evaluation criteria. | | Project Closure Plan | Outlines the steps for closing the project, including final deliverables, project handover, evaluation, and lessons learned. It ensures that all aspects of the project are completed and reviewed. | | Appendices | Includes additional documents, templates, charts, or references that support the project plan, such as detailed schedules, risk logs, or glossary of terms. | ## Business Requirements and Solutions Documents (BRSD) You document the business requirements and the proposed solution in a BRSD. If you're gathering just requirements and want the solution document separate, use a Business Requirements Document (BRD) and a separate Solution document. ## User Guides (Training) If a NetSuite project is going to result in a useable product, you'll want user guides. These documents serve to provide continuity from the point of system implementation through the sunsetting of that particular process in NetSuite. Your systems configurators (consultants) will often be the writers of these user guides, but you may consider hiring a specialist in writing such documents! As you review these documents, keep the following checks in mind: - Are these in a format where we can make updates when we change the process? - Is it understandable for both existing and new users? - Does it follow a logical structure? - Are graphics used appropriately? ## UAT Documentation User Acceptance Testing. It's critical to validate the system will meet the needs of the business. How do you do it well? Here are a couple of ideas: **Keep it simple, stupid:** don't build some elaborate system for testing that requires training for the stakeholders simply for them to run their tests. **Speak their language:** Write the tests in language that the business has provided or agreed to adopt (in cases when NetSuite terminology does not fit the business's processes). **Keep it simple, stupid:** make it easy for the user to understand 1) what their supposed to do, 2) how to do it (link to User Guides), and 3) how to provide feedback. # Project Execution # Scope Creep