Here are a few tips on how to manage a software project as well as some examples of documents I created for this blog post. Links to the templates can be found below.

The templates are created with Google sheets and Google docs and are based on a simple set of website features and using a MVC software pattern. This will not cover everything in your project and someone in the project will need to alter it to your teams need.

The important thing is you are defining a process, documenting (to communicate and analyse) and iterating (use feedback from the team to improve the project).

  • This guide is a blend between Agile and Waterfall.
    • Agile for UX-based design with user stories.
    • Waterfall to manage project milestone and sign offs.
    • You can take a strict agile or strict waterfall approach - whatever works for you and your team.
  • The more important thing is that you are if your team already has an alternative,  
  • Every project will encounter changes so these documents will need to regularly be updated.
  • All documents (relating to the project) should be versioned, this will provide a history and documentation of what was actually signed off at that time.
  • It is important you can cross-reference between documents and can view the full history of how you ended up implementing X, why it took Y and what was required.

First we need to define a process. This is going to be the process we use to go from ideation to release. You could take a more agile approach and use a simpler process for each feature / user story (agile) or go the other way and create more milestones and planning around the project for waterfall. Regardless of the approach, you should ensure that you review how the project is running on a regular basis, based on what you planned to release and how much you actually got done. This should be done with the whole team.

  1. Ideation - Define
    1. Feature requests
    2. User story definitions
    3. Engagement
    4. Document
  2. Discovery - Validate
    1. Engagements
    2. User story RAID
    3. Project Brief (optional sign off step)
  3. Design - Plan
    1. Engagements
    2. Document
    3. Sign off
  4. Build - Implement
    1. Task breakdown
    2. Task estimation
    3. Test build
    4. Document changes
    5. Sign off
  5. Release
    1. Document release
    2. Document release run log
    3. Soft release (optional contained testing)
    4. Hard release (public testing)



Task breakdown [Link to template]

I like to document everything I can relating to the project. By breaking down the tasks to a granular level you can set expectations and provide "rails" to your project team about what is expected and when. This will also allow you to measure whether work has been completed, track how fast people are at completing the tasks and understand how long the project will take at any given time.

If you take a agile approach, you will breakdown tasks and associate them with the relevant user story.

If you take a waterfall approach, you will breakdown tasks based and associate them with the relevant release.

  • Be as granular as possible
  • Create sub-tasks for everything.
    • If a task is to create a document. Create sub-tasks to outline each section the user needs to create.
    • If documents need to be reviewed after completion, that should be defined with a task. Don't just create tasks for the build. 
  • Estimate and iterate
    • Estimate by hours or by a difficulty rating but make sure you have these assigned before starting work on the task otherwise you cannot measure and improve.
  • Be consistent with your tasks, try to use some sort of convention when naming tasks. It'll make it at lot more understandable and easier to read.
    • Build - Backend - Build registration API
      • vs. Build an backend API to allow the user to update
    • Build - Backend - Update registration API with X feature
      • vs. Update the backend registration API to include feature X
  • Always flag what is required vs optional (must have vs nice to have). Delays will always happen, you will be limited on time and must pick what is the least important (MVP vs not MVP)
  • Tasks should take into account the assigned role when estimating (juniors and seniors should have different sets of expectations - see roles and responsibilities)
    • You can use the responsibilities + task completion throughput to help performance manage your team.

Roles and responsibilities [Link to template]

People join and leave companies during a project, you need to expect it. At some point someone in your project team will perform many roles, without assigning roles to people you will not know what they are doing and whether a person is overburdened with work. Roles also set a common set of expectations between the business and the team member. Roles and responsibilities should be agreed upon as early as possible in the project or before it even starts and be defined by the whole team.

  • Documenting this will provide an open set of expectations between management and the team.
    • Team members will also be able to understand who to go to when something comes up.
  • Roles are defined by a set of responsibilities and should be agreed upon by the team (collaboratively)
  • Roles and responsibilities reduce unnecessary questions and deadlocks that might arise during the project when a problem arises
  • Some people may have one role, others will fill many roles. Don't many your project based on people.
    • You may need to alter your roles after a project, or re-assign people into other roles. This can't be done if you assign it by person.

 Solution brief [Link to template]

This is optional. This is simply a document that can be shared across different teams to succinctly describe what will be built and should be kept high level. This should provide a summary, define the objectives, costs and impacts across the business. When businesses have multiple projects it can become hard to review large documents to find the relevant information.

  • Not essential but often important for larger companies (with multiple projects and large teams)
  • Summaries the impacts on the business, both technical and financial, at a high level
  • Allows the business to ensure everyone is aligned and to surface misconceptions before going to far down the road of implementation.
  • Should be 1-3 pages at most

Technical Spike brief [Link to template] 

Technical spikes are not always needed and are ways you can reduce risks within the build of the project. Technical spikes should use some convention or system to identify risky functionality and validate a potential solution to reduce the overall risk. User stories may relate to a feature, requirement or user story however should be considered as separate tasks.

For high risk and high effort tasks I create a document which outlines the problem, what I am expecting to solve and how.

  • Used to reduce a technical risk when building a user stories requirements, identified by the RAID task.
  • Use some form of system
    • I use risk / effort to understand when a technical spike brief is required
      • Low risk / Low effort - Do nothing 
      • High risk / Low effort - Get the solution validated from an expert - within the team or external 
      • Low risk / High effort - Get the designs approved - within the team or externally
      • High risk / High effort - Create the brief and validate with a POC
  • Should be a separate task relating to a user story.

Technical Scope [Link to template]

The technical scope document should be the blueprint of what is being built. I generally create tasks for documenting the build, implementing the build then updating the document at the end of the build.

  • Documentation should be done before the build and updated after the build
  • Bake documentation into your project - create subtasks for each build task to create and update the documentation.
    • This will give you more realistic project estimations.
  • The scope can be incrementally completed.
    • I normally breakdown the flow for particular user stories / scenarios
    • Create diagrams based on the flow
    • Document project, system and solution requirements.
    • Then over time add more sections for the remaining pieces (page layouts / components, external systems, etc)
  • User stories can be difficult to estimate and document against as they can cover multiple functional requirements
    • I sometimes estimate effort and design around requirements, then associate requirements to user stories to get a more accurate understanding of effort
  • Follow the motto "Measure twice, cut once". Don't just go strait into build.

Charts [Link to template]

I tend to use three types of charts, but you may need more. Gannt charts provide visual reference on how long the project will take and when certain milestones will be made. Burndown provide an idea on the effort / team.

  • Gannt charts provide the team understanding of project timelines and progress
  • Burndown charts provide understanding of workload and identify risks or issues with overburdening team members with work
  • Task charts demonstrate the work assigned to team members

Change log [Link to template]

Document the changes in your project, alternative options to previous proposed solutions are inevitable. Understand what was changed and why it was changed will prevent you from repeating the same mistake again. For my projects I tend to only log build changes and suggestions from meetings.

  • All changes throughout the project should be logged.
  • This will become the knowledge base of the project as it iterates, at the end of each sprint you will ask why you did X or Y. This provides those answers
  • You may also want to log other types of changes from  the discovery, design and release stages.

Release schedule [Link to template]

While regular (daily, etc) releases do seem great at first, with bigger teams you will need to share the changes with more and more people. The more frequent this is the less realistic it is to expect everyone to be able to complete their work so regularly. I personally think a 1-3 month release schedule is ideal. The point is however frequent you do your releases, you should document what is planned in the release. Again this is about communicating whats to be expected to the relevant people, marketers need to plan campaigns in advance, management might need to discuss with committees and owners with investors.

  • Document what is in the planned release
  • You will need to update this document when features are missed and delayed to a future release
  • The bigger the project the more important this becomes.