A Quick Guide Project Management Methodology
Posted by Brad EgelandA few months ago I covered all 8 phases of my general project management methodology over 8 separate and fairly long articles. What I would like to do here is condense them into one – still lengthy – quick guide type article for general reference to anyone who might need it. Let’s get started…
Purpose:
- Onsite meeting with the customer at the beginning of the engagement to review the SOW, the project team, the draft project schedule and milestone dates, and the process for managing the project
Activities:
- Prepare for onsite Kickoff session with customer
- Create/revise draft project schedule
- Create presentation slides for Kickoff session with customer
Deliverables:
- Kickoff session slide deck
- Initial project schedule
Purpose:
- Document business processes, further refine business requirements for the project, work with the customer to detail the difference between the “as-is” processes and the “to-be” processes. Further involvement by customer SMEs will be required.
Activities:
- Create the Business Requirements Document (BRD)
- Customer review and signoff of BRD
Deliverables:
- Business Requirements Document
- Revised project schedule
- Revised issues/risks list
- Weekly status reports
- Weekly status meetings
Purpose:
- Goal is successful completion and signoff of main Design phase deliverable, the Functional Design Document (FDD)
Activities:
- Work with customer SMEs and delivery team to further refine and finalize functional design requirements, reporting requirements, data migration requirements, data integration requirements, security requirements, etc.
Deliverables:
- Functional Design Document
- Revised project schedule
- Revised issues/risks lists
- Weekly project status reports
- Weekly project status meetings
- Assignment of development team members and other support personnel to the delivery team
Purpose:
- To develop a workable solution according to customer specs that is ready to move into the Testing phase
Activities:
- Develop a Technical Design Document (TDD) – mainly for use by the delivery team and the technical lead
- Develop the system to customer requirements
- Perform periodic demos or reviews to ensure that the solution is on track
Deliverables:
- Technical Design Document – optionally for the customer
- Periodic development reviews/demos
- Revised project schedule
- Revised issues/risks lists
- Weekly project status reports
- Weekly project status meetings
Purpose:
- To ensure that the developed system is tested, matches customer requirements and is bug-free for training and deployment
Activities:
- Define testing approach
- Document Test or QA Plan
- Create test conditions/cases – this should be a customer activity
- Conduct system testing
- Conduct User Acceptance Testing (UAT)
Deliverables:
- Developed system
- QA or Test Plan
- User Acceptance Testing signoff
- Revised project schedule
- Revised issues/risks lists
- Weekly project status reports
- Weekly project status meetings
Purpose:
- To train the customer or the customer’s trainers on usage of the production-ready system prior to Deployment
Activities:
- Development and delivery of a training plan
- Development and delivery of training materials
- Setup of a training environment or server with a production-ready copy of the system
- Training-specific data loaded to the database
- Delivery of training, or train-the-trainers training
Deliverables:
- Training plan
- Training materials
- Training environment
- Training data in training database
- Revised project schedule
- Revised issues/risks lists
- Weekly project status reports
- Weekly project status meetings
Purpose:
- To implement the tested and production-ready system into the live customer environment and deploy to all relevant users
Activities:
- Setup production environment
- Load production data to the production environment
- Customer review and signoff of go-live readiness
Deliverables:
- Production environment
- Live data load to production environment
- Deployed production-ready system
- Revised project schedule
- Revised issues/risks lists
- Weekly project status reports
- Weekly project status meetings
Purpose:
- To provide the customer with a window of time after go-live where the key delivery team members will still be available to the customer for issues, etc. and for knowledge to be passed on to the on-going support organization
Activities:
- Go-live support for an agreed upon timeframe (30-60 days) by the delivery team for the project
- Hand-off to support team
- Re-connect with the customer team for Lessons Learned sessions
Deliverables:
- 30-60 days of post go-live support by the current delivery team
- Lessons Learned documented and delivered to delivery team, customer team, and support team
Related posts:
Roy says:
I have no idea what this is….Seems that the steps you’ve listed is a mixture of project/product development.
The Project Management Framework is divided into five standard phases, as defined in the Project Management Body of Knowledge, PMBOK Guide. Each phase has associated activities, but, additionally, the phases overlap.
1. Initiating processes – preparing a notification followed by a project proposal, then, gaining approval and reserved funding for the project. The end to end life of the project must be taken into account at the proposal stage, for example, recognising that the information for an Activity Completion Report at the end of the project should be considered at the proposal stage and throughout subsequent stages of the project.
2. Planning processes – defining and refining objectives, preparing the Project Plans and associated sub-plans for running the project, then gaining final allocation of funding.
3. Executing processes – implementing the Project Plans; coordinating people and other resources to carry out the Project Plans. Typically, this is the longest phase of a project.
4. Controlling processes – ensuring that project objectives are met by monitoring and measuring progress regularly to identify variances from the plans; taking corrective action when necessary; tracking the variances and changes. Controlling has much overlap with other phases.
5. Closing Processes – bringing the project to an orderly end: formalizing and communicating the acceptance or conclusion of a project, handing over to the ongoing accountable area, completing an Activity Completion Report and, for major projects, holding a post implementation review.
Brad Egeland says:
Roy- What I have outlined is a practical process for managing a typical IT implementation. And I outlined each of those phases in detail back in the January – February 09 timeframe (see the associated embedded links). Those 5 steps are great…but they do not give a novice project manager much of a guideline for what to do, where development falls, when to test, and what to do as you deploy. My phases can be fit into those PMBOK processes. What I have defined is a quick guide to use for managing a general IT project.
Cherup says:
Good article Brad!
Project Management Methodology says:
Great informative post
Gary Bakshi says:
Very nice article! Thanks a lot!
Project Management: How to Successfully Kickoff a Project | Project Management Tips || Project Management, Collaboration and Knowledge Management Blog says:
[...] In my article titled “The Project Kickoff” I discussed how the project manager should handle a typical project kickoff session with an external customer on a sizeable engagement. In that post I covered what happened in the Kickoff phase – Phase 1 of the overall PM methodology I presented over eight articles and in summary form in “A Quick Guide to Project Management Methodology“. [...]
Dee says:
Nice summation of the IT SDLC phases. I use them in addition to PMBOK phases as outlined above by Roy.
Brad Egeland says:
Dee-
This is more of a hybrid PM/SDLC methodology that is very useful for managing IT development projects and the technical resources and deliverables required by these types of implementations. Thanks for commenting.
A Discussion on Project Management Methodologies | Project Management Tips || Project Management, Collaboration and Knowledge Management Blog says:
[...] do – there can really be no standard methodology to be utilitized to fit most or all projects – hybrid methodology must exist. Your methodology must fit what you do, who your customers are, and what your [...]