Key Steps to Effectively Plan a Software Project

At some point in the past, we have all experienced a project that went off the rails, or at the least succeeded despite obvious challenges in software project management and planning. Sometimes this is a good thing because if you never experience failure, or do not overcome challenges, you do not learn. But that does not mean that you should not try until you fly. Just as there are (or should be) pilot lessons before a plane is taken into the air, a template on how to plan a project to avoid the worst of the challenges can help you avoid the worst outcomes. In the following article, we are going to outline some clear steps toward a successful project plan. 

Define Scope

The first step in planning your project is to define the scope. This is arguably the most important step in your project plan, as scope creep is one of the biggest enemies faced in a given project. Without clear goals, a clear definition of the core features of your product, and a scope/definition of each feature within the product, the project is likely to fail, or at best, become bloated and unrecognizable by the end. 

This step requires clear and consistent communication with the stakeholders. Based on this communication, you will:

In other words, this stage of the project is all about discovery, but discovery from the key project stakeholders. In defining the scope, we define the key aspects of the product, where the value propositions are, how the product improves the experience of its users, etc. We want to avoid confusion or lack of clarity two months into the project, so as many details as possible should be gathered from the stakeholders.

Discovery Sessions 

This stage is also about discovery, not only from the stakeholders. Here it is important to involve everyone that will interact with the product, or that will use its analytics or admin panel so that we can consider carefully how these pieces fit together. 

The key goal of this discovery process is to prevent unidentified stakeholders from jumping into the project at a later stage believing their concerns were not addressed, or that a big piece of the product or the analytics in determining value or progress has been missed during planning. 

Design and User Research 

Next, we begin to get down to the nitty-gritty. Once we have a clear outline of the project, and the input of all those affected by or using the project, it is time to flesh out the product and its individual features with a little design. At this point in the planning process, we will begin creating the flows that will lead to the final product.

First, we will outline the visual user flows, often with whiteboards, and very basic wireframes outlined by aligning the stakeholders with the design team. During these initial design sessions via stakeholder/design team discussion, we flesh out:

We then do some preliminary user research to validate these visual flows, and to understand the product we intend to build. The visual flows are also a baseline that will be used to create the user journey map.

These visual flows are then shared with the key stakeholders in order to confirm that the goals are (to this point) being met and that the product envisioned matches their expectations. Not only that, with this preliminary user research, we get a glimpse as to whether the proposed solution provides real value to the end user.

User Story Map and Project Roadmap

The next step is to create a user story map. This step clearly delineates the activities, steps, and details that will be a part of a given process in the technical product. These user story maps are based on each of the visual user flows created in the previous step. This can also be a point of reflection for the team, with discussion leading to a consensus and understanding of the scope of individual workflows.

Once individual story maps are created, the project manager can then integrate them into a project roadmap based on the estimations established for each. This roadmap must include the work of the design team and any impact that design factors may have on the work of the development team. If the design team is well-integrated into the earlier stages of the product, key design decisions should be made already, and have limited impact on the scope of the product, as it is much harder to overlay design atop already existing development than to fit development tasks to an existing design.

Stakeholder Validation

Now that we have the user story map for each feature and an overall project roadmap created, it is time to return to the key stakeholders, and share the ‘final’ results, remembering of course that nothing is final until consensus is reached. Each user story map should be approved, along with the timeline established for each feature and the project as a whole. 

When getting this consensus from the stakeholders, double-check that:

At this point, we have to clarify what this consensus actually means. We need to clearly state that anything added at a later stage of the project, anything deemed missed in planning, or anything that is outside of this established and agreed-upon scope will either:

Plan First Sprints

Now that we have buy-in from our key stakeholders, and a project roadmap (with user story maps) serving as an outline, it is time to put the plan into action. This means sprint planning. Before beginning work on project deliverables, the first two sprints (at least) should be planned and communicated to the team and stakeholders. These first two sprints are key to understanding the dynamics of the project, and to helping the stakeholders understand the sprint-level deliverables. In turn, this also helps them understand how to gauge progress, which can prevent tension later on. The planned Sprints should line up as closely as possible to the user story maps and project roadmap, to maintain stakeholder expectations. 

Once we have these first two sprints, all that remains is to lean back, smile, and say: “I love it when a plan comes together.”