Breakdown of Initiating-Planning-Executing-Controlling-Closing process

I got this list of possible project tasks.  personally I think it is a good practice to go through this list, and create marks on the project current status along the way.

Initiating

• Select Project Manager.
• Determine company culture and existing systems.
• Collect processes, procedures and historical information.
• Divide large projects into phases.
• Identify stake-holders.
• Document business need.
• Determine project objectives.
• Document assumptions and constraints.
• Develop project charter.
• Develop preliminary project scope statement.

I am working in technical domain, or more specifically,  embedded system development. I think it is vital important to verify architecture correctness while creating the project charter also. The best way is to do some prototype work, though maybe too luxury. To the bear minimum, the project manager should create some diagram and discuss with relevant stakeholders,  otherwise is just waste the organizations and money and time, and market opportunity.

 

Planning

• Determine how you will do planning – part of management plans.
• Create project scope statement.
• Determine team.
• Create WBS and WBS dictionary.
• Create activity list.
• Create network diagram.
• Estimate resource requirements.
• Estimate time and cost.
• Determine critical path.
• Develop Schedule.
• Developer budget.
• Determine quality standards, processes and metrics.
• Determine roles and responsibilities.
• Determine communications requirements.
• Risk identification, qualitative and quantitative risk analysis and response planning.
• (items above this lime will need Iterations ).
• Determine what to purchase.
• Prepare procurement documents.
• Finalize the “how to execute and control” aspects of all management plans.
• Create process improvement plan.
• Develop final PM plan and performance measurement baselines.
• Gain formal approval.
• Hold kick-off meeting.

My personal feeling is better to use 1/10 criteria for planning, that is, to estimate at the granularity level of 1/10. For example,  setup a monthly schedule for a half year to one year project, or create biweekly schedule for a one quarter project, or create a WBS with 10 to 20 tasks. I have seen task break down with several hundred tasks, eventually it becomes a game to figure out which activity goes to which task, and really a brain test for entire team.

Executing

• Acquire final team.
• Execute the PM plan.
• Complete product scope.
• Recommend changes and corrective actions.
• Send and receive information.
• Implement approved changes, defect repair, preventive and corrective actions.
• Continuous improvement.
• Follow processes.
• Team building.
• Give recognition and rewards.
• Hold progress meetings.
• Use work authorization system.
• Request seller responses.
• Select Sellers.

In my opinion, there are two key points for executing a project: 1. People management: understand what your colleagues can do and try to balance the workload. I think making presentation and/or have frequent chit-chat are good ways to bring the gap. At least I feel more clear of one concept after I can make others understand what I am talking about.  2. Build an adaptive process: Nobody can plan everything accurately at the beginning. I like the practice to check the status at the end of each week (or biweekly), and figure out how to make up next week. I think it is called iteration process or spiral model officially.

Monitoring & Controlling

• Measure against the performance measurement baselines.
• Measure according to the management plans.
• Determine variances and if they warrant corrective action or a change.
• Scope verification.
• Configuration management.
• Recommend changes, defect repair, preventive and corrective actions.
• Integrated change control.
• Approve changes, defect repair, preventive and corrective actions.
• Risk audits.
• Manage reserve.
• Use issue logs.
• Facilitate conflict resolution.
• Measure team member performance.
• Report on performance.
• Create forecasts.
• Administer contracts.

For Software/Firmware Development, There are organizations that project manager is busy working on collecting all the matrix, quality team building nice diagram/chart subsequently, and top management evaluating the organization / individual performance based on these charts. In the end, Engineers have to cook data so that the final evaluation will be good for them. I believe the role for project manager is to ensure the accuracy of monitoring. BTW: I also think cooking data is hard for Small and Medium Organization because SMEs always face customer directly.

Closing

• Develop closure procedures.
• Complete contract closure.
• Confirm work is done to requirement.
• Gain formal acceptance of the product.
• Final performance reporting.
• Index and archive records.
• Update, lessons learned and knowledge base.
• Hand off completed product.
• Release resources.

Not many project managers are lucky enough to lead the project until its official ending. However, I think a responsible project manager for an organization should collect historical information for this project, and put into a way easy to be utilized by the next project manager. Especially for a software development organization, attributes like Engineer productivity, defect density, percentage of each stage, and domain expertise are important for the sustainability of the organization.