Waterfall
Waterfall is the road trip of Project Management: You come up with an idea of going somewhere; you plan on where and when to go; you come up with a budget of how big the trip is going to be; you go there, and you're done! Now it's about reliving the memories and dreaming of the next trip.
It's a single stream of consciousness that flows from start to finish with the single idea of creating the vision, then releasing it and sitting back to watch it play out. There are no iterations during the process. No revisit. No re-engineering. The building of the Pyramids would simply not allow you to go back and put a skylight in.
Basic Principles
Waterfall work is executed is a linear series of tasks that may be grouped as phases, where one group is created before continuing to the next. Generally, these groupings are identified as:
- Analysis
- Requirements
- Design
- Build
- Test
- Deploy
Waterfall makes perfect sense, as each phase, and the tasks grouped in that phase are reviewed and approved before going to the next phase. This ensures that all the concepts and works completed are perfect and everything is aligned with the original vision of the Mighty Wizard who came up with the idea. RIGHT!!!
Waterfall still has a place in corporate Project Management. It just needs to be more effective and more in tune with the project effort. Waterfall aligns well with Infrastructure projects. Projects that are physical in nature. It must. Unlike Software projects, Infrastructure can't change on a day-to-day basis. And costing is a big contributor to this slow but steady planning as well. Sure, you can scope and execute work in sprints, but the concept is still done in baby steps: First we recognize the issue, then we design a solution, then we cost it out, then we order the hardware, then we wait, and by the time its gets here, we better use it!
Waterfall is the slow and steady pacing of the environment that gets the job done. Documentation is King here. Charters or Solution Analysis statements lead to Requirements docs, that lead to HLDs and POCs. Once we confirm our build, Testing affirms the work quality, and we prep for Deployment. It's tried and true, and "works most of time, for most of the projects."
This is where a Project Manager shines. Keeping all of this aligned, in order and moving forward at all times is paramount. Understanding the delivery cycles, Stakeholder expectations, budget constraints and the project risks, all comes together in nice and tidy status reports that give a precise picture of the progress made, and work remaining.
Following the PMBOK helps keep the project aligned and properly documented, which in turn, supports the approvals needed to continue the effort and move forward towards Deployment. Reviewing the Budget, tuning the Schedule, updating Test plans all comes together in a wonderful symphony of data that becomes information to the Stakeholders to support their road map decisions. PMBOK will group the work into these management areas:
- Scope
- Schedule
- Cost
- Quality
- Resource
- Communications
- Risk
- Procurement
- Stakeholder
Immediately, you may begin to see how Waterfall may fail in your organization, and the PM may have to resort to other methods to control a project. The lack of authorization to Procure equipment may delay a project beyond Stakeholder expectations and acceptance. I have seen this cancel many projects, the inability to execute the basic process in a timely manner due to inter-departmental disruption is always a major risk in any corporate level project.
What I Bring to the Table
After 24+ years in the Corporate IT Project world, let's say I've seen a thing or two. Project Charters. Schedules. Risk logs. None of these makes or breaks a project. But what does, is a lack of acknowledgement as to what these tools represent. Without a Charter, you don't have a properly aligned scope. Without a Schedule you don't have a properly aligned timeline of expectations. Without a Risk log, you're unaware of the external forces impacting your delivery. Taking the time to understand these items, and all the other tools at a PM's disposal, is the key to a successful project. And to communicate them to Stakeholders and Leadership is critical to keeping the Project moving forward and meeting Stakeholder expectations.
That's what I bring. Clarity. Clear communications for the critical decisions Stakeholders need to make about their project. Clear communications to the development team so that they understand what's expected in their deployments. Clearing the road so the Road Map actual can deliver the products business needs for its customers. And for itself. Working through all areas of the PMBOK to provide the leadership the Project needs:
- Supporting leadership with executive level road map planning
- Supporting leadership with resource planning and capacity planning both at operation and project levels
- Developing project schedule and budget with enterprise or proprietary tools such as MS Project, Workbench, Smartsheet, Monday, Jira, Excel.
- Presentations to support kickoff meetings, communication to cross functional teams and leadership when needed, to convey and stress resource integration points and clarify deliverable and timeline expectations
- Project schedule maintenance and leadership status reporting
- Project execution maintenance and resource performance monitoring
- Define and execute leadership escalation paths to support project progress
- Deployment schedule and communications. Project conclusion and closeout activities
- Systems and application decommissioning and sunsetting
