THE VALUE OF A SOFTWARE PROJECT ASSESSMENT
You already know the custom software you’d like to build and who is going to build it. So why is a project assessment crucial to its development?
A project assessment is the best way to determine your project’s goals, scope, and management approach before investing valuable time and resources in development. Before you start designing and building, it’s critical to get to the bottom of your objectives and expectations--specifically the features and resources needed, the levels of risk you are willing to take, metrics for success, and how you are going to get the project done. Every software project assessment should address these three critical steps: Project Goals (The “Why”), Project Scope (The “What”), and Project Management (The “How”). '
1. Project Goals (The “Why”)
Define your overall business goals. Goals might include improving efficiencies, saving money, enhancing the customer experience, or gaining a competitive advantage. Knowing what you want to accomplish will help determine project scope and inform the required budget.
When considering goals, remember to make them S.M.A.R.T. (Specific, Measurable, Attainable, Relevant and Time-based). If you can, be specific and attach hard numbers to goals, such as an X% increase in sales or a Y% reduction in costs. You will be better able to justify the time and resources needed to develop the appropriate software. Also, considering attainability and relevance when formulating your goals will help you prioritize the scope. Be specific, and make sure everyone is in agreement about the goals prior to moving forward.
2. Project Scope (The “What”)
Once you’ve set your goals, work on fleshing out the project scope in more detail. This is critical to success in that you will outline the complete framework for the entire project and understand what is required and how it will all work together. At Troy Web Consulting, we develop a workflow diagram--a visual process map to follow for each of the core concepts. Within this phase, you should also identify feature priorities--in other words, your “must haves” and your ”nice to haves” with an understanding of resource requirements needed for each. If you have never done this exercise, check out the MoSCoW method. One nice feature of this method is explicitly stating what the scope will NOT include, which can be very valuable to document early on.
The team then reviews the features and resources required to determine what will be in the project scope (and what will be addressed either down the road or not at all). This is important so everyone understands options and together makes the best decision considering all the variables.
The detailed project scope will clarify the features you want, the complexity of each and level of additional information required. (You may want to use a ranking system to identify scope items that are very well known vs. potential rabbit holes.) The scope assessment should also inventory external resources and dependencies, as well as stakeholder roles and usage. Finally, the scope assessment should define the critical success factors and key performance indicators (KPIs) that will be used to measure project success.
3. Project Management (The “How”)
In the final step of the project assessment, we look at how the project will run. Identifying the team members and making sure there is role clarity is a critical element. To do so, you’ll need to identify your “readiness” for the project in key areas--such as brand/product identity, strategy, availability of the stakeholders, technical capabilities and thorough knowledge of the business processes. By using a grading system in these areas of readiness, you can identify where you will need to get key team members in place to close any gaps in readiness.
Another key element of the project you will need to understand before you can fully make the call on how you will run the project is project risk factors. Almost every software project runs the risk of scope creep. Other risks that need to be considered are potential issues with technology, integration, funding, subject matter expertise or timelines. When assessing risk, be sure to identify both the likelihood and the impact of each risk. For every risk, there is a mitigation strategy that will need to be factored into your plan.
All of the analysis of “The How” of your project will steer you toward a project management methodology--one that is either more traditional or more agile, depending on the details. Should you start two-week sprint planning and use agile scrum, or should you take time to document all requirements and create a specification and a detailed design document? Every project is different, and once you have looked at your project readiness, your team, and the risks, along with the scope and the overarching goals of your project, you should be able to make a determination of whether your project management approach should be more predictive or more adaptive in nature--or something on the continuum between the two styles.
Once you complete your assessment you will have a much better understanding of what is needed to successfully develop your software and avoid some of the pitfalls and surprises that usually surface during software development projects.