Project/Program Management Lessons Learned

Project/Program Management Lessons Learned

“It’s about Management Control and Quality”
Turn the listed items into checklists to be used for assessments and evaluations.

The following is a list of lessons learned that have been identified and documented during a successful career of executing projects and programs.
1. A project manager must not only be responsible, but be accountable, for the project.
2. Programs/Projects must be aligned with the overall business plan and strategy.
3. Understand the proposal, contract and standards referenced for use on a project/program.
4. Obtain senior management support and commitment.
5. Conduct business with high ethics.
6. Use Best/Good Practices, tailored to the project and program.
7. Prepare a complete activity, work or task breakdown (known in the industry as a WBS), reviewed by key team members and accepted by the customer.
8. Document lessons learned during each phase/process of a system or software development life cycle (SDLC)(requirements definition/analysis, design, implementation/construction, test, delivery/deployment, and support/maintenance) and after each activity, task, and deliverable.
9. Have customers and users participation in the beginning, and throughout, the project.
10. Don’t overlook team building – having the right people with the right skill sets.Having a stable “Core” team is essential.
11. Build teams while considering retention and backup plan and strategies.
12. During the sales and proposal stage ensure key people are involved and participate in reviews (e.g., PMs, System Architect, Lead developer, or other leads).
13. Ensure all team members (including client/users) understand the project plan (get buy-in from leads/inputs to the project plan).
14. Document other agreements or expectations in the “Future Consideration” of the requirements document (Including for Agile or other iterative development processes. The limited or specific documentation used for Agile and other iterative development processes should be contained in a document.).
15. Provide realistic estimates of project activities and costs.
16. Perform Configuration Management (CM) and Quality Assurance (QA) to ensure good product development management, compliance and that quality is built into the product, as both (CM and QA) begin at the beginning of the project. Don’t confuse configuration management with just documentation and don’t confuse quality assurance with just testing. (link (or see) book or articles)
17. Determine which development process to implement for the project: Agile, Iterative, waterfall, or combined elements. Traditional or Iterative and incremental development may be required depending on the solution and complexity of the project. (Each or combined elements have been used in past project successes)
18. Product requirements must be defined, understood and documented (specified) up front and/or throughout development for iterative development processes (Agile, etc.) (Must be traceable back to business requirements and throughout development, mutually agreed to and signed off).
19. For Agile development, ensure that an architecture is created, documented and developed to understand, agree to, identify and determine the up coming iterations.
20. A company’s culture and politics cannot be ignored.
21. Prepare a traceability matrix to accompany requirements documentation. This document can also be used as a check list.
22. Identify, document, and manage risks before execution of, and during, a project.
23. Develop a communication plan and execute it.
24. Document terminology and definitions. Include in planning and requirements document/documentation.
25. Ensure that audits and reviews are performed/conducted for oversight and to ensure consistency and compliance.
26. Perform and document usability testing when required.
27. Establish a centralized repository – containing a knowledge base, lessons learned, project information, templates, etc.(Could be web based or intranet)
28. Ensure knowledge transfer and training takes place.
29. Document and share lessons learned, but more important use them.
30. Ensure a mechanism for feedback for improvement is in place.
31. Monitor and obtain customer satisfaction/dissatisfaction throughout the project (inquire/survey).
32. Close Out Project. Ensure that (not limited to or in a particular order):
a. A project close out meeting is conducted with the customer/client to define that all close out criteria have been satisfied (financial included)
b. Any issues are addressed
c. Lessons Learned are shared
d. All deliverables (product included) were signed off and delivered
e. A repository is set up (or was) and all documentation/data archived
f. All team members are formally released from the project
g. The project success criteria was met and is reviewed
h. The project performance and evaluation reports were completed (performance reports provided to team members line managers if project supported a matrix environment)
i. A team close out meeting is conducted to the thank the team (recognized and/or rewarded)
j. A final survey/evaluation sheet or form for customer/client input is left with the client (to be provided back to the company)
k. A letter for close out is signed by customer and project manager