SDLC usage
I often get asked what SDLC methodology I could recommend to a PMO. In many cases companies asking me this either have tried a homegrown approach and it was lacklustre at best...or copied something off the web and didn't work either. Selecting a methodology is only a fraction of the solution folks. My observation is that the SDLC must be under the ownership of the PMO. Not in the PE depr or QA dept. An initial assessment is required examining the types of project that are done, the formal org structure of the company, regulatory factors, global deployment of projects, standardization, etc...
Once the assessment is done, put together those key phases and components that would make sense for the org. (e.g, Discovery, Design, Build, Test, Deploy). If they are into making chemicals, then there would be a need for more rigor around safety and environment. So in the Test phase, create detailed test plans, checklists, etc. Getting this idea? Also build into place regular phase gate checkpoints where any senior executive can assist in moving the project from one phase to the next. Keep in mind that you do NOT (r) NOT want to make the SDLC so administrative that you slow down manufacturing or production lines, all because you need sign-offs on a key phase document. The business will only frown upon your well intended initiative.
I keep SDLC methodologies limited to (1) Small, (2) Medium, (3) Major projects
 Replies: {REPLIES} | Views: {VIEWS} |  Author: {AUTHOR} |  Last Post: Topic is empty
|
How many times do we need to create another SDLC??
Folks,
I am sure you must all be tired of reading about SDLC or methodologies all the time. What I wanted to blog about was how many companies get bogged down in re-creating the SDLC wheel all the time. Especially large companies that have multiple business units or units - they simply cannot agree on a sticking to one SDLC process and templates practice. Instead, every year or two, they find the need to re-create their SDLC again. Let me know if you get the same in your company. I bet you they are being designed by people who have never run a project before?
Replies: {REPLIES} | Views: {VIEWS} | Author: {AUTHOR} | Last Post: Topic is empty
|
Community Driven Development Project
Community Driven Development Project
Here are common steps in the process of SDLC, which may vary according to the size of the project.
Definition
Requirements
Client supplies a project requirements document, which states:
the purpose
goals
major features
compatibility issues
human interface issues
maintenance and support
documentation and training
terms and conditions for the project
Depending on the completeness of this document, vendor(s) involved in the proposal process may need to make inquiries and revisions to it before it becomes an adequate basis for a bid.
Analysis Proposal
If required, the out-sourcing vendor supplies this. It should include:
the scope of the project
cost and time estimates
a basic project plan
a definition of deliverables
acceptance criteria
any terms and conditions required
any assumptions used to make the proposal
This document may not be required if the project is fairly small or if the client has already created a technical specification that is adequate to make a Development proposal on.
Executed contract
Frequently, the client requests revisions to the proposal. Once those are agreed upon and the proposal is accepted, the contract is drawn up and executed. This document should include:
delivery date
deliverables
terms and conditions concerning non-disclosure
Intellectual Property Rights
a clear description of each partys responsibilities
functional specification provided by client
the price
payment terms
Pricing is usually on either a fixed-price or time-and-materials basis. The vendor meets milestones upon final acceptance by the client.
Payment terms for time-and-materials contracts are variable with weekly to monthly invoicing and terms of net 10 to net 30.
Preliminary Project Plan
The project plan is created by whoever is managing the project. It should include:
a work breakdown
the sequence of events (usually a PERT chart)
a project schedule
Both the client and the vendor should sign off this document.
Analysis
Functional Specification
Through interaction with the client, the vendor creates this document. It should contain:
an overview of the system/application
major objectives and any special system requirements
a description of all components and deliverables
a method for negotiating specification changes
acceptance criteria
client-vendor communications interfaces
responsibilities of both parties, and any terms, conditions and assumptions
Both parties should sign off the Functional Specification.
Preliminary Design
The Preliminary Design should include:
a high-level design of the system/application as a whole
a description of user-interaction, data-flow, and data storage
Project Plan revised
Update project plan to reflect the information in the functional specification and changes in available resources and technology.
Development Proposal
Final versions of analysis proposal
Executed contract
See Executed contract, above.
Design
Design Specification
Once a set of alternate top-level designs is devised by the vendors, the vendors should take the clients through a walk-through. Once this walk-through is complete, the vendor should complete the design process and create a Design specification.
This specification should include:
an overview
system requirements
design priorities
diagrams and naming conventions
parameter passing and database conventions
error handling
programming tools
descriptions of data records and storage
The specification should include all of the functionality stated in the Functional Specification.
Quality Assurance Test Plan
This test plan should include:
Alpha entry criteria
Beta entry criteria
Final Code Submission criteria
Acceptance criteria.
It can include more than one Alpha or Beta cycle and other intermediate cycles such as Gamma.
Project Plan revised
Update project plan to reflect the information in the design specification and acceptance plan.
Development
Alpha entry
Criteria for alpha entry should be agreed upon by client and vendor.
Quality Assurance for Alpha submission
QA is usually supplied by the vendor
Quality Assurance engineers follow the Acceptance test plan and report bugs to the development engineers
Bug fixes and minor feature enhancements
Development engineers fix bugs reported by QA and by the client. Minor feature enhancements, as agreed upon by client and vendor are incorporated.
Beta entry
Criteria for beta entry should be agreed upon by client and vendor.
Quality Assurance and Beta site testing
QA is usually supplied by the vendor
Quality Assurance engineers follow the Acceptance test plan and report bugs to the development engineers
QA engineers also do regression testing to insure previously reported bugs are fixed
Bug fixes and minor feature enhancements
Development engineers fix bugs reported by QA and by the client. Minor feature enhancements, as agreed upon by client and vendor are incorporated.
Final code submission
Criteria for final code submission should be agreed upon by client and vendor.
Acceptance
Acceptance testing
Acceptance testing as specified in the QA test plan is performed by the client, possibly with the vendor present.
Operation
Warranty-period technical support
Vendors should offer to fix problems caused by vendor free of charge for a certain period of time. The warranty period depends on the size of the project; however, 90 days is common.
Maintenance
This is usually a separate contract, detailing any maintenance requirements including:
adding features
fixing bugs
giving technical support to the client
Project post-mortem
Client and vendor should get together to discuss the project. Topics usually include:
a statement of original objectives and proposed solutions
project method and organization
a comparison of estimates with actual results
successful aspects of the project
problems encountered and how to avoid them in the future
Replies: {REPLIES} | Views: {VIEWS} | Author: {AUTHOR} | Last Post: Topic is empty
|
Getting it right for PMO implementation
Some key coments on deploying a PMO
1. Learn Best Practices from key industry groups such as (Gartner Group, Big 5, key whitepapers...)
2. Develop a clear communication strategy indicating when and how you will deploy the PMO
3. Inventory of all current processes and templates used with current SDLC/methodology
4. Get a grip on your current Business Plan and develop a 5 yr roadmap of projects. Map each years projects to a business plan and map those to the resources in-house
5. Determine skillsets of your PM's - you may need PM training or certifications
6. Obtain full executive support and their backing...any derailers from just 1 person on the leadership team will likely end up with negative perceptions and politics will end up being the issue of the day
Replies: {REPLIES} | Views: {VIEWS} | Author: {AUTHOR} | Last Post: Topic is empty
|
Deploying Agile in a Waterfall Shop?
Want a significant project culture shock? Well...if you've been slave to a waterfall methodology for years and finally seeing some standardization of policies and processes get ready for Agile. Most organizations are pushing their SDLC up the maturity ladder. For years you've been waging war on ineffective requirements , changing requirements and scope change - even dealing with ineffective PM's who really know the theory but don't know how to manage this process...As PM or Leader, you've made some inroads and held many meetings between teams to resolve these errors. Right, ...well along comes Agile, promising you faster incremental development, streamlined teams and improved customer involvement....Oi Vey It's most likely that your organization will still maintain (2) two methodologies. (you cant throw the Waterfall out now entirely anyway)...but hear me out My concerns for this week are to be most careful how and when you decide to deploy Agile. Firstly, let's socialize this new Agile SDLC very well with your leadership and business prior to deploying anything. Unfamiliarity with Agile can throw a major wrench or "spanner" in the works and come back and bite you in your proverbial Gantt chart. I was at a client site in this week observing a portfolio review and the invited project customers knew nothing about this Agile Product backlogs and Release retrospectives at all. They were nothing less than surprised about the change in events...."We didn't know, and was news to us"...said a senior VP for the Sales Team. Sure you may have a few select Agile guru's amongst your midst, but be wary of showing off too much and not communicating this SDLC effectively. Train folks and train them again on Agile. For example, in Waterfall SDLC - requirements are locked down using the URS templates right? Well in Agile, you don't entirely have a URS upfront and approving one is very difficult to say the least. All you have are list of Storyboards. Bottom line is Agile is capable of much, but if starting out from scratch and you're not familiar with Agile...plan this SDLC deployment out properly...Happy deployment.
Replies: {REPLIES} | Views: {VIEWS} | Author: {AUTHOR} | Last Post: Topic is empty
|
