Describing the SDLC

SDLC

While assisting an IT department through a Sarbanes-Oxley (SOX) audit, I had to document an organization's Systems Development Life Cycle (SDLC). The SDLC includes activities and functions that systems developers typically perform, regardless of how those activities and functions fit into a particular methodology.  Many assume SDLC is referring to a software development process.  In turn, there's a lot of debate about different development practices and approaches.  For example, when I lead Scrum teams for an organization, as part of an overall SDLC, all of the Scrum activities took place during the Implementation phase.  When changes were deployed to the Production environment, the Support team leveraged Kanban.  From Planning to Analyzing to Designing, they leveraged a Waterfall process.  It all began with a request for a change. Because a picture is worth a thousand words, Pictofigo has created a SDLC poster, with a little input from me. You can either purchase it from CafePress as a poster or you can download it from the Premium Pictofigo site.

Using Common Sense With Documentation

Though I really love good documentation, going heavy on it does not guarantee a successful project.  At my last engagement a product manager asked why she had to go back and complete a business case, a feasibility study, and a charter when her team was already several months into development of  the current release.  She was being consumed by back-filling this documentation.  I believe this was a poor business decision by someone higher in the organization.  They did not "get it".  Documentation is nothing more then a communications tool.  When improperly used, a tool will not necessarily give you the benefit you need.  Need to drive in a nail?  You wouldn't use a screw driver, would you?  Then why would you ask someone to use their valuable time and energy to create a document for the sake of creating the document?  Use the appropriate tool at the appropriate time to get the appropriate results.  If there was a 1 year project with a requirement stating there had to be a feasibility study, then you better have one.  You should have done it at the inception of the project.  But, if you have a project that is only 1 month long, use some common sense. My recommendation is you spend a little time identifying documentation that truly meets your needs.  More importantly, identify documentation that truly meets your customer's needs.  You're not impressing anyone with a SharePoint site or filing cabinet filled to the brim with documentation nobody ever looks at.  One good example of a document that provides value is a Project Charter.  I know, there are hundreds of you out there rolling your eyes.  You figure your stakeholders are not going to sign this document (though they should), formally authorizing a project or a phase.  But, this same artifact does document initial requirements that satisfy the stakeholder’s needs and expectations.  Having this document and answering those questions is going to increase the probability of you having a successful project.  Use it as a communication tool!

Since a majority of the search results coming to this website are from people looking for Free Project Management related templates and worksheets, I decided I better give my readers what they are looking for.  You are my customer!  You have expressed a need or want for templates and worksheets.  I should make it my goal to satisfy those needs.

I'm currently working on a new business case template. What will be in it, you ask?

Project Overview

1. Problem Statement
2. Project Description
3. Project Goals and Objectives
4. Project Scope (what's included and what's excluded)
5. Critical Success Factors
6. Assumptions
7. Constraints

Authority and Milestones

1. Funding Authority
2. Project Oversight Authority
3. Major Project Milestones

Project Organization

1. Project Structure
2. Roles and Responsibilities
3. Responsibility Matrix
4. Project Facilities and Resources

Points of Contract

Glossary

Revision History

Appendices

Did I miss anything?  Give me a few days and I'll have it done.

I welcome any feedback or comments.  Just post them below.

Regards,

Derek

Free Communications Management Plan Template

I participated in a Communication Working Group session for the PMO today. Imagine a dozen people sitting around a table laughing for 10 minutes, when they realized I had shaved off my goatee. After the excitement subsided, we rolled up our sleeves and got to work. It was really quite refreshing to see how excited everyone was to be there. (We only had 4 people for the prior meeting) Ishikawa diagrams littered the walls and the smell of Scripto markers filled the air. I can't stress enough how important it is to have a Communications Management Plan.  Feel free to download my template.  If not, I recommend following the next 7 steps to write your own.

1. List the project stakeholders and their associated roles and responsibilities
2. Specify contact information for each stakeholder
3. For each stakeholder identified, specify the information required to keep stakeholders informed and enable them to fulfill their project roles and responsibilities. Also, specify the timeframe, frequency, or trigger for distribution of the information.
4. List the information that must be collected, summarized, and reported in order to produce the communication outputs that fulfill the stakeholder information requirements. Specify the associated collection and reporting details.
5. List each report or document to be produced and distributed as a communication output to fulfill the stakeholder information requirements. Specify the associated distribution, storage, and disposition details.
6. List and describe the distribution groups that will be used to distribute project information.
7. Last, define all terms and acronyms required to interpret the Communication Management Plan properly.