Implementing Waterfall for both Execution and Management Teams in SpiraPlan
Introduction
Although businesses adopt agile practices to embrace change and respond to market needs, there is still a need for organizations to embrace certain principles and ideas that come from traditional waterfall project management. After all, if the good lessons learned from waterfall approaches, such as thinking of the milestones for payment terms, procuring resource commitments earlier to avoid delays in ongoing commitments, evaluating risks that challenge existing or future commitments, and technical architecture with scalability in design, are ignored, are we truly adaptive in strategic execution? It is essential therefore that any tool that we use lends itself to implementing both waterfall approaches and agile approaches because the total cost of ownership for the company to use the same tool across the organization is low.
Spira family of products support the agile framework with its rich set of features, numerous integrations with existing development and testing tool, and customization options. Yet, a question arises if we can use Spira to implement waterfall initiatives. In this whitepaper, we will discuss the approach to implementing the waterfall initiatives in Spira.
Essential Considerations
When implementing waterfall initiatives, two important things must be kept in mind? These are what we are delivering and who is overseeing the work. These are two different types of stakeholders. The first group focusing on delivery is interested in who does what and when. The second group focused on management is focused on how the project is doing in terms of scope and timeline. The level of communication differs because the execution group spends their efforts on problem-solving and the strategic group reviews the work in progress and work delivered towards decision-making.
The delivery group’s interest is in the details. This means the project team is interested in the requirements that will be delivered. Furthermore, they engage in the numerous tasks that make up the specific requirements. While one person may be accountable for delivering the requirement, there many be one or more people responsible for, consulted on, or informed about many tasks that cumulatively deliver on the requirement.
The management group’s focuses on the progress against the commitments proactively to evaluate the numerous risks. If progress is not satisfactory against the milestone committed in the project schedule or product roadmap, corrective actions may be required. Consequently, they may review a rolled-up version of the project schedule for these release milestones that align with procurement and financial agreements.
Figure 1: Elements of Waterfall Initiative
In order to meet these requirements, we need to have access to three critical areas – releases, requirements, and tasks. These are illustrated in Figure 1. SpiraTeam and SpiraPlan have all these three areas.
Example of a Waterfall Project Structure
Let us simulate an example of a waterfall project for an email marketing campaign. The requirement phase may consist of understanding the main messages in the marketing campaign, confirm the audience to be reached, identify graphical needs for images and videos to be included in the campaign, develop the script, and confirm approval to proceed. The design and development phase may include designing a wireframe of the email campaign, get initial approval, incorporate the feedback and do initial unit testing.
The next testing stages deals with the backend integration for user credentials, location of the images on the webservers, unsubscribe, and other links like the privacy policy. After defects identified during testing have been closed, the launch process is initiated where the list is prepared by scrubbing any user against opt-outs, user acceptance testing, and schedule the email send. The post-deployment phase, which is carried out as part of the post-deployment captures the email metrics and distribute the lessons learned for future project.
The phases containing the main milestones and requirements are captured in the project schedule below.
Figure 2: Email Marketing Campaign
Step 1: Establish the Release and Requirements
One of the critical elements of implementing a waterfall initiative is agree on the scope and a timeline. Now, even waterfall initiatives follow progressive elaboration and are structured in phases. The financial commitments may be identified in a Statement of Work (SOW) or other contractual artifacts identifying a payment schedule aligned with major or minor releases. Although the final project deliverable itself will not be delivered until the entire project is completed by waterfall design, customers can see interim deliverables, fund the project appropriately, or make course corrections. As a result, the essential need is to identify a consistent naming of these milestones and the time period covering these release schedule.
Once you have selected the specific project that you are working on, you can invoke the release module by going into the Artifact selection section and clicking on the release module. Then, you can click on the insert button and set up the releases as shown below to emulate the releases. The following Figure 3 demonstrates how these major milestones are setup using releases.
Figure 3: Major Milestones setup as Major Releases in Spira
Frequently, a major milestone may compromise of more than one deliverable being tracked. While this level of deliverable tracking is possible with in the requirement view, if management wants to also see the progress of these deliverables within the major milestones, these deliverables can be setup as minor releases. The following Figure 4 demonstrates this. An essential tenet of project management is for management to track the progress at the level the work has to be monitored. As you can see, Spira allows tracking releases at multiple levels to facilitate the extent of monitoring desired.
Figure 4: Release Setup showing setting up of Additional Deliverables in Spira
outlining specific things that needs to be delivered to meet the milestone commitments.
Step 2: Set up Requirements and Tasks
The next step in the waterfall initiative is to identify the deliverables. These deliverables are identified in the form of requirements in Spira and are relevant to the delivery team that works on them. These requirements can be nested hierarchically to support the way execution team thinks of grouping them. Subsequently these requirements are further broken into tasks as discussed. As the deliverables can be broken into many (0:N) tasks, the requirement grid panel shows progress tracking in the section #2 in Figure 5. Finally, these requirements can be mapped to specific releases as noted in section #3 in Figure 5 for rolling up to the project or program dashboard for management.
Figure 5: Summary of Requirement mapped to Releases and associated with Tasks
The summary of tasks that make up the project schedule can be viewed at the individual requirement level as demonstrated below in Figure 6. Here the detailed view of the selected requirement is shown and how they are broken down into specific tasks. The “Show/Hide Columns” can be used to bring the planned start date, end date, and the projected effort.
Figure 6: Summary of Task breakdown for a Specific Deliverable
When the project moves into the execution, tasks are assigned to specific individuals. While one may have a planned delivery date as part of the release timelines, the detailed estimates are done at the task level by the owner assigned to the task. At this point, the owner assignment, dates and effort become necessary. These can be entered at the task level in the task detailed pane as shown in Figure 7.
Figure 7: Task Detail Pane showing owner assignment, start and end dates, and effort
Project Dashboard
Once these releases, requirements, and tasks are mapped, the project dashboard displays the progress update against the releases and requirements entered. If projects are part of programs or portfolio, management can drill down from portfolio into all its programs and further into the programs, projects, and major and sub releases. Shown below in Figure 8 is an example of the Gantt chart built directly at the project dashboard.
Figure 8: Gantt Chart showing the release phases and requirements (entered for one phase)
Project Execution
As the project continues, work is executed showing progress on the tasks. For instance, let us look at a couple of tasks that are part of the milestone 1 requirement phase related to the requirement “Understand Main Message”. By going into the detailed pane of the appropriate task, the project manager or project scheduler can assign the task and the desired start/end dates. The assigned owner can start the task using the workflow operations, record the estimated effort, log the actual hours and the remaining efforts. These are shown below in Figure 9.
Figure 9: Task Assignment and Effort Tracking
By following similar logic, let us say we completed the second small task “Discuss webinars to highlight” associated with the same milestone “Understand Main Message” of the requirement phase. Let us further say the “Discuss upcoming events” was started but no effort has been recorded yet. In the task pane view, you can see the progress listing the first task as progress with a green bar tracking partial update, second task as completed with the green bar completely marking the duration, the third task as in progress but without any green bar tracking any effort logged, and the remaining tasks as not started. These status updates are tracked in the Figure 10 below.
Figure 10: Progress Tracking of Tasks in the Task Grid
Since tasks are aggregated to the requirements tracking the deliverables, you can see similar progress against the deliverable because the work logged against the individual tasks for that deliverable is rolled up. This progress on the requirements is demonstrated in Figure 11 below. As tasks start late or take more time, additional color coding will be shown to demonstrate the project manager to take the corrective action or support the team appropriately.
Figure 11: Progress Tracking of Tasks against the Requirements in the Requirement Grid
While Spira can be used to manage any type of project, such as managing change within an organization, Spira provides more support for software projects that can follow waterfall. As software development projects also have testing to ensure that the software developed meets the requirements, Spira provides a testing module to track test cases developed against requirements, progress of testing, and defects identified and resolved. The following screenshot demonstrates for a different project on how test progress and task progress with different status can be tracked. This diagram provides an expanded version of the project schedule showing who does what, when, and the status updates of the aggregated tasks and tests.
Figure 12: Progress Tracking of Tasks and Tests against the Requirements in the Requirement Grid
Project Monitoring
Execution of projects runs almost in parallel with the monitoring of projects. When projects are tracked in a project schedule application like Microsoft Project, the project manager does not always get a dashboard to monitor the health of the project with the ability to drill down deeper as needed. Often, the project managers run a number of reports in such applications to get at this project health (that I call Pulse Check). Both preventive and correction actions emanate from here towards properly managing stakeholders, team, risks, communication, and change.
Spira provides numerous widgets that equip the project manager to view the project (or program or portfolio) dashboard to quickly gather this information through a number of widgets. These widgets are further broken down based on the generic project details, project development, and testing so that the appropriate roles can further monitor these widgets to ensure projects are delivered on time and on scope.
Summary
Spira is designed to be framework agnostic supporting waterfall, agile, and hybrid approaches. It should be emphasized that project managers build the project schedule with all the deliverables and activities in Waterfall projects and the team writes their own tasks based on the requirements in the Agile framework. This blog summarized the steps to take to build a waterfall project in Spira.