Project Planning
It seems like it should be, right? But since I'm asking the question, you've probably already realized that something is up.
Project planning, from a Project Planning perspective comes after the Information Architecture, wireframes and flows are done. This is because you can't plan a project if you don't know what goes into it. How would a Project Manager accurately plan out a system if it was impossible to determine who will be doing what? Of course, it would be impossible.
A project plan is a set of tasks with assigned people, set times - usually in hours, priorities and types that guide the team in the build of the project. These tasks can be placed into groups, often called Epics, that compromise a specific feature or set of functionalities. These groups and tasks can then be processed through linearly (also known as Waterfall Method) or in time-boxed, flexible sets of work that are planned based on the last set of work completed (Agile Method). Both have their advantages and disadvantages, but more often than not, Agile Method, with some Waterfall Method aspects is used. This is colloquially known as a Mixed or Hybrid Method. There are several other development methodologies out there, but these are two of the most commonly used.
The project plan can be displayed visually as a Gantt chart for a smaller section of the project, or as part of the Product Roadmap, which shows how the project will evolve over time. This is a visual of the tasks, assignments, and order of work. It also shows the Critical Path, which is the set of work that must be completed in order to meet minimum operating standards.
Project plans always looks so set in stone when you take a look at the Gantt chart, but make no mistake, as soon as you get started things are going to change.
The SaaS Project Plan has the following:
- List of the stakeholders
- List of team members and their roles
- List of user types and what they can and cannot do. This is also an important aspect of the information architecture.
- The product roadmap. This shows how the product will evolve over time.
- List of tasks with
- Assigned person per task
- A Gantt chart, based on the tasks, stories, and epics that shows the general process to completion. This will change as you go forward, but you need to have something to start with.
- You may also have Initiatives and Themes as part of the project. Initiatives are groups of epics and Themes are larger groups of initiatives that span the entire company. It is rare to see Themes and Initiatives in a SaaS build projects, but it does occasionally happen.
- Estimated start and end dates for the different phases of the project.
- If you are using Agile Development Method, then a list of Sprints is often provided, but not required.
The goal of this book is not to educate you on the intricacies of Project Management, only to give you what you need to know to build a SaaS project. A SaaS Development Project Manager would probably say that the intricacies of Agile development are in fact a prerequisite. Personally, I think it's a great idea as well. Please consider a look at the Atlassian Agile Guide for the deep dive.
Last modified 4yr ago