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:

• Define the core features of the product – This is where we both define the most important goals of the project, as well as the high-level limitations of the project. This list should remain static, if possible, throughout the project. 
• Define the scope of each feature – Each feature can contain a large subset of tasks and goals. It is often at this level that scope creep occurs and must be guarded against. 
• Establish the value proposition of each feature – Each value proposition must be evaluated against the end users, and must be clearly communicated to everyone, both the team and stakeholders.
• Determine the scope of analytics – The type and scope of the analytics expected by the Stakeholders to track project progress should be defined early in the process.  This allows the project manager to integrate the analytics into the project plan, and to refer back to the original scope should the stakeholders ask for additional analytics later.

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. 

• Multiple discovery sessions – Depending on the complexity of the project and the time frame in which it needs to be pulled together, as many discovery sessions as possible should be scheduled to ensure a complete understanding of the product being developed. The more complexity, and the longer the project, the more important these initial discovery sessions become.
• Multiple user groups/ cross-functional groups – When planning these discovery sessions, everyone with any possible interaction with the product must be included. For example, an application that deals with oil and gas logistics may need to include field engineers from outside the team, because they will be the ones entering or confirming the data at remote locations. The interface has to make sense to them, as well as those reviewing the data at the dashboard level. If automated, there may need to be a validation process implemented somewhere down the line. These points of interaction need to be considered, and each individual piece must make sense to everyone involved, as well as fit together in a seamless whole. Determining who needs to interact with the product (back and front-end) may be a small discovery project in itself, and this might even need to come first on more complex projects.

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:

• How the product should generally work.
• Details of each feature.
• The expected outcome/s of each feature.

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:

• The roadmap includes all features within the scope.
• Each feature is clearly defined and fits within the project scope.
• The full roadmap fulfills all stakeholders expectations – this can be a challenge, especially when delivering an MVP, as some desired features might be on the cutting room floor.
• Make sure that the roadmap is synchronized with the expected timeline of the project and budget.
• Iterate until the roadmap is agreed upon by all parties.

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:

• Require a trade-off.
• Change the delivery dates (and the launch date).

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.”