Project Management

Management of the Project. And of People. And of Resources. And so much more.

SDLC

Take a methodology and break it down to detailed phases, and then produce a ton of documentation for each phase. Add some iterative improvements, and voila, you have a Development Life Cycle process that's Agile within a Waterfall process when executing Systems Implementations or Software Development. Confusing? Yes, and that's why I'm here.

SDLC, Software Development Life Cycle, is, like Waterfall, a linear progressive step process of Stage gates. (SDLC may also refer to Systems Development Life Cycle, but for this article, I’m referring to Software.) SDLC is intended to be a defined framework. Similar to the way Scrum is a framework for the Agile methodology, SDLC is the framework to identify the approval stages to progress through to reach Production release for Waterfall. When companies tell me they are Waterfall, they generally intend to follow the 5 key steps of the Waterfall methodology:

  • Plan
  • Design
  • Develop
  • Test
  • Deploy

When they want to be SDLC, they generally intend to follow and artifact for the 7 key approval stages:

  • Conceptualization
  • Requirements
  • Planning
  • Design
  • Development
  • Testing
  • Deployment
  • Maintenance
SDLC is intended to be process and communication heavy to ensure management knows what the team is planning to achieve, and that all teams, matrixed or otherwise, are aware of what’s being asked of them. With Waterfall, generally Plan consists of a Charter and Budget. Design could include Network and Architectural documents. They Develop the entire scope of the Deliverable, and then general Testing and Deploy a final release of the Product.

With SDLC, before Charters and Budgets, you have Conceptualization, which could be an executive memorandum, a formalized Scope statement or some form completed to explain the Idea behind the Project. That document is then reviewed and approved by a board for progression to the next step, Requirements gathering. Then Requirements are completed, and again reviewed and approved, and so on, through each Stage. With a well trained PMO, these templates can be refined for simplicity, and the reviews are quick and easy. Without expertise, SDLC can turn into a burdensome, process ladened nightmare of trying to release a product.

Another key point of SDLC, it should use specific and educated resources to create the documents for each sequential Stage. Conceptualization is handled by the Stakeholder executive. Those approved documents are then delivered to the Business Analyst, who in turn works to generate the Requirements document. The Requirements are then handed to the Project Manager to complete the Planning. And so on. Each Stage has its own RACI owners, separate from the preceding and succeeding stages.

SDLC also has a distinct advantage over traditional Waterfall, in that it allows for iterative work to occur in the Development and Deployment phases. This can help get Products to Market faster, and also enables faster feedback and in a greater frequency.

What I Bring to the Table

With 22+ years of experience in PMO and software environments, I can support development, enhancement, and thoroughness of SDLC approval gate artifacts. Or not. If artifact templates do not exist, I can support the approval process reviews with alignment of current documentation. Whatever it takes to keep things moving forward. And then as we progress through project reviews, we can begin identifying the artifacts required, and build the templates to support the environment.
Review boards to start:

  • Executive Leadership for Conceptualization reviews
  • Business Stakeholders for Requirement reviews
  • PMO leadership for Planning review
  • Architecture and Infrastructure leadership for Design reviews
  • Business and Application leadership for Development and Test reviews
  • Delivery leadership for Deployment reviews
  • Operations leadership for Maintenance reviews
Document templates to support:
  • Conceptualization
  • Ideation
  • Executive Memorandum of Understanding
  • Business Requirements (Non-Functional and Functional)
  • Technical Requirements
  • Charter
  • Project Schedule
  • Resource Planning
  • Budget Planning
  • Communication Planning
  • Risk Planning
  • Network Design
  • Architecture Design
  • Systems Requirement
  • Feasibility Studies
  • Code Check and Sign-Off
  • Use Cases and Test Scripts
  • QA Sign Off
  • Release Requests
  • Operational Maintenance Guide
  • Runbooks
  • And so much more…