Writing a Project plan for a new project:

Introduction: This article talks about the preparation needed for getting started with a new software project that involves providing improvements to complex software systems. There are several considerations to be made. When the project starts new resources might have been assigned who would require ramp-up time. The mission and the execution plan of the improvements might not have any clarity and even summed up in a sentence. The relevant dependencies might not have been listed. The stakeholders might not all be in alignment with the agenda. The architectural enhancements for the delivery of the software features might not have been thought through. A lot of steps might need to be prioritized before the end goal is reached. This is a helpful introduction to the planning involved.

Description: One of the advantages of software development is that this is a beaten path with plenty of templates and learnings available from the past. The objective may be new and unclear but there are several tools available to put the plan in place. First among these is the project management tools and the Gantt chart. This tool helps not only with the distribution of tasks and alignment of the task with the timeline, but it also helps with determining cost, as well as the critical path for the completion of milestones.  The timeline can be put in perspective based on a pegged release data and worked backward budgeting for tasks that can be squeezed in.  When a new project begins, even the tasks are not enumerated sufficiently. The difficulty to put them on a chart or in sprint cycles and with milestones becomes difficult. This can be improved by gathering the stakeholders and the resources in the same room for multiple discussions. These discussions will empower them both to present the facts and keep the milestones practical. These could be done internally as well as with biweekly stakeholder meeting where incremental deliverables are realized via two-week sprint planning, meetings, and demonstrations of experiments and prototypes. The earlier these conversations take place, the better the planning and the outcome for the team. New technologies require significant investments in learning and the convergence happens better when there are introductions by subject matter experts from stakeholder’s organizations. It will be more equitable for everyone when it happens in a conference room.  

Another tool that helps with this kind of software development is a functional specification document that has a well-known template for organizing thoughts. It starts with critical use cases that are articulated as stories involving a person who is trying to solve a problem. The narrative for the use case outlines both what is available to the user and what would have helped. The gamut of options and the impact of the feature requested become clearer with a well-written use case. It might involve a quantitative aspect to what needs to be done and elaborate on the kind of outcome that would best serve the user. When the objective becomes clearer this way, intermediate deliverables fall in place. There is no limit to the number or description of use cases if the end goal becomes clearer. The means and mode of delivering the features are usually not that hard to envision once the goal is in place. The delivery of the features takes time and the allotment of tasks to resources must consider internal and external factors that might alter the schedule.

One technique that helps with the deliverables is determining the priority and the severity. The former describes the relevance each item might have based on the feedback from the stakeholders. Usually, higher priority items are in the critical path for the release and must be tackled first. A backlog of items can help maintain the list that needs to be burned down while the priority determines their selection into the sprints. The severity is dependent on the impact of the task. If the task is touching data or configuration and potential to affect many users, it has a higher severity than others. It is somewhat easier to determine severity when the source code and architecture are well-understood. Sound architecture can handle evolving business needs with the least changes. The determination of the right design will help mitigate the high-severity tasks with ease. The design part of the software development lifecycle involves multiple perspectives, calculations, and validations. With a large team for the software development, it might be easy to distribute the design to virtual teams involving multiple or different hats for individuals rather than based on components alone. A DevOps cadence can help improve the mode in which the features are developed.

Another technique that helps with removing surprises and distractions is by handing out showcase user interfaces even before the actual functionality is delivered. This is a sound practice even for cases where it does not involve software. Such dry runs including emails to stakeholders can significantly eliminate noise and refine the expectations. Many tasks are done better when the communication is clear and involves the right audience. With more and more communication, it is possible to change course when things do not pan out. Mistakes are easy to occur, and corrective actions are easy to take when there is visibility.

Lastly, software development is about people and not just about process and practice. Changes, moderations, and selection of techniques depend largely on the intentions of those who benefit from them.