As software developers, we may not need to write project plans, but a good understanding of the project plan is crucial. It makes sure there isn’t a gap between our product manager/customer and the application we are building. So that we don’t spend our time and efforts doing something that isn’t wanted.
A simple yet effective project plan consists of SBSSRT, a Summary, Basic story, Scope, Structure, Resources, and Timeline.
- Summary
This should be on the first page of your project plan with a brief overview of everything. Despite this being first, it’s best to be done at the end since you’ll be drawing the main points from the rest of your plan.
Summary often contains overviews of project goal, framework, final deliverables, scopes, milestones, and resource cost estimates.
This is also the most often viewed by stakeholders and project managers to ensure the project is on track to launch and meeting its requirements. It is designed to get a snapshot of your project quickly without having to go over the whole thing.
- Basic Story of your application
This is the section that should be written from the user’s perspective. The app is created for someone to use. As a user, what I can do with it?
Put yourself in your user’s shoes. What do you want to see and be able to do with this application?
For example, this NASA website. before building, what do you want your user to be able to interact with it?
As a user, I can see the most recent 3 pictures of NASA photo of the day along with its date information and title on the page when it first loads.
As a user, I can select the beginning date of the 3 days and see those 3 photos.
As a user, I can click a button and see 3 random photos of random 3 dates.
As a user, I can like and also see how many likes this photo has.
as a user, I can comment on the website and feel like being a part of the community.
- Scope
It’s bad when you aim for the wrong things. This section should outline the starts and finishes with expectations and requirements. Make sure everyone involved is on board on what the project entails.
There should also be a clear and concise on what is meeting requirements for the deliverables and the process for these approvals.
- What is IN scope? Describe the core feature of your MVP (Minimum Viable Product). What needs to be built?
- What are your stretch goals?
- What’s out of scope. It is good to clarify this if there are assumptions that something might be included in the end product but it actually isn’t.
The last thing is to outline risks with each requirement and a way to mitigate them. a comprehensive scope goes a long way to let you and your team aware of what is expected and when should be done.
For example, again, this NASA website.
What’s IN scope: It’s a single-page application, everything exists within 1 page. Home page populated with photos and info fetching from NASA API. JSON server will manage to store the likes and comments from the users. etc.
Stretch Goals: user can comment on each photo. when clicking on the photo, there will be a full-screen view. etc
What’s NOT in scope: User can NOT get more than 3 photos on one page.
- Structure
There are many frameworks out there to choose from. Each one is different some go through all the stages of development sequentially while some might have different processes.
Building a React App, for example, the structure of the project ( the App) will be the structure of the components. Explain how the components are related to each other, how each component functions. Explain in detail.
- Resources
What resources are available for this project? eg. time, budget, people, technology, etc.
Assess what you have before starting is important because you don't want to cook a meal with the wrong ingredients. Be realistic about your resource limitations.
- Timeline
Having a good timeline increases your project's success, although most of the projects don't always follow it. The timeline also depends on how you structure your project and the resources you have.
A good timeline allows you to break down your tasks and goals and track the progress.
It can be written by day or week or any timeframe that you think it s suitable for your project. For example when building a React App and have the timeline written by day.
June 24th:
task 1: finish the basic structure of the website, have all the components created
task 2: …
June 25th:
task 1: …
Finally made it to the end! now you are equipped with all the project planning tips you need and you’re welcome for saving your weekend!
