At a glance

To optimize project plans you should do the following:

  • Accommodate the agility required by modern Dev Ops
  • Add a realistic ‘uncertainty’ buffer to plans
  • Utilize a standard, baseline project management template to reduce complexity


Do any of these conversations sound familiar?

      When will the project be complete?

            I don’t know. Maybe in a few weeks…

      What else do you need to do?

            Just wrapping up a few things…

      How will the new initiative impact your project?

            Hmm. I didn’t think of that. I’ll have to get back to you. 

One of the biggest challenges in any major business or technology transformation – whether they be a massive platform implementation or operational change management – is keeping track of the initiative. Are we on schedule? Are there any issues/risks we need to be thinking of?

The Hybrid Agile-Waterfall Project Plan Framework

For hybrid agile-waterfall project plans, it is important to maintain the overall time frame of a waterfall model while maintaining flexibility to respond to emerging requests and project changes. Include clear objectives and ample documentation at the start of the project to ensure success.

Formatting your project plans

Ongoing development initiatives will typically be the focal point for your project plans. Outlining all the steps required for execution will ensure that your projects cover all the bases, reducing the risk of going off track.

1. Project Planning & Management

Analysis and Design

Business Requirement Document

The business requirements document is where you outline all the changes requested by the client. The document should be kept simple so that the client and development team can easily understand the requirements. Detailed requirements review sessions should be held with the client to confirm understanding of the changes requested. Prioritizing each item will facilitate easily determining which changes to focus on


  • Business Requirement Document

2. Developing the Project Plan

Once the general requirements are clear you can work with your development team to develop the project plan. Review each change in detail, adding a time frame for each phase of development.



Dividing changes into sprints allows the development team to focus on a set of related functions within a predetermined period. Use internal testing at the end of each sprint to provide feedback for developers on any necessary fixes.

  • Development Requirements Review

The development team and the analysts plan the next sprint in detail. They review the requirements to decide how they are going to meet the business needs.

  • Tasks

During the development cycle, conduct Daily Scrum meetings that last no longer than 15 minutes to review all tasks. Discuss what has been done so far and what will be done next. Use the time to share any potential roadblocks or problems. Seek opportunities to streamline the working progress.

  • Internal Testing

This is your first chance to review the development progress before the UAT. Refer back to the requirements document to be sure that business needs are being met.

Code Review

Set up a time for another developer to conduct a code review with the main project developer. An objective set of eyes can provide insights into how to avoid potential issues and optimize the code. During the session, discuss alternatives and possible workarounds that might work better for the situation without insisting those solutions are the best or only way to proceed.


The overall objective of adding a buffer to your plan is to protect the project deadline. Analysis of multiple project management methodologies has determined that only 44% percent of projects finish on time (1). It is impossible to predict that all of your team members will be available or whether an “all hands on deck” emergency might divert resources from your projects. Adding two or three days can give you peace of mind to be able to handle the unexpected. Also, it’s not the worst-case scenario if you don’t use the buffer and deliver the project ahead of schedule!

3. Testing and Validation

User Acceptance Testing (UAT) Preparation + Test Case Setup

UAT Testing gives the client a first look at the changes and an opportunity to ensure that they meet their requirements. The test plan should be reviewed with the client team prior to the start of testing to confirm that the scenarios cover all the intended business cases. Also, the developer should prepare any necessary environments and test data.


  • UAT Test Plan

User Acceptance Testing (UAT) and Bug Fixing

Tests should be carried out by subject matter experts, who should be real end-users of the application in development and have the authority to approve and disapprove features. The ideal scenario is a group conference environment where all stakeholders work together on acceptance test cases. A defect found by the user is noted in the test plan and fixed before the next session. The user then performs the test again.

UAT Test Results Review and Code Freeze

Finally, it’s time to move forward with the release. As soon as everything is working as it is supposed to, the user/client/customer representative will sign off on the application, indicating that it meets their needs and is ready to be used. The code freeze begins at this point, and the developers will not be able to make any more changes.

4. Training and Documentation

Create/Update Application Manual

End-user documentation should explain how to perform the application’s functions as simply as possible. The manual should reflect any incremental changes made to the application, allowing the document to remain current.


  • Application Manual

End-User Training

End-user training is one of the keys to the successful implementation of any application. When users are unsure of how to use the features of an application, the impact of a new implementation or change of software is diminished.

A training plan should be developed with the client to provide end-users with the fundamentals of using the application. The number one objective is to minimize any productivity losses resulting from the transition to a new business process. During training, real-life data should be utilized to make the application more relevant to your organization. For future reference, a recording of the training should be made.


  • Training Plan

5. Release

Draft and Review Production Script

The development team will create a script to migrate changes from the test environment to the production environment. Before making any changes, all potential unintended consequences should be considered.


  • Production Script

Draft and Review Migration Plan

A migration plan outlines all the steps needed to release the application. This should include pre and post-execution activities, along with quality assurance checks at key points of the migration.


  • Migration Plan

Execute Migration Plan and Application Release

When the release window is reached, an official go-ahead is given to the development team to begin work on the development release.

6. Post Release

QA in Production Environment

A new release should be reviewed in the production environment to ensure all features are functional. Since you are now in a production environment, you may not be able to run a full suite of tests, but at least make sure that the application’s basic features are still working. Upon completion, the client’s team can use the application.

Finalize Documentation

Post-release any related documentation should be compiled for future reference. A release log should list out all the features in the new application version.


  • Release Log

Standardizing Project Plans

Aligning your plan formats into a common data framework is the final step in optimizing your projects. Standardizing all project details will facilitate easier access to information, improve the efficiency of project management, and reduce the timeframe for release cycles. Project statuses, resource allocations, and deadlines should be tracked for all projects. Without a unified data framework, information may be misappropriated or lost due to naming differences. The standardization of terminology and frameworks is a step towards moving from “intuitive” project management to an organization with greater operational maturity.

Establish a baseline Project Plan Template format: 

  • Gather a sample set of successful plans used in previous projects
  • Determine which KPIs should be used in the baseline project plan template
  • Format the template to include actual and proposed project start and end dates to monitor project completion variances


  • Standard Project Template with Data Framework

Do you need help developing hybrid agile-waterfall project plans for your organization?

It is a well-known saying that you cannot manage what you cannot measure. At Karma Advisory, we have experience transforming disparate initiatives into cohesive project plans that achieve measurable results.

For more information about how Karma Advisors can help you with establishing a hybrid agile-waterfall project planning framework, please email