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.

Overlap of Processes along the project timeline

This diagram depicts the relationship of processes well, I like it.

Projectized versus functional organization

An organization can be either functional oriented or project oriented.

Organization Structure	Projectized	Matrix	Functional
Domain Expertise	Poor	Medium	Good
Project Coordination	Good	Medium	Poor

In practical, most of organizations are matrix based, i.e, team is organized by functional area, and team members work for projects most of the time under project manager.

The pros and cons of a project organization is listed below, although the truth is matrix organization can be a nightmare for Engineers.

Pros	Cons
Highly visible project objectives	Extra administration required
Improved project manager control over resources	More than one boss for project teams
More support from functional organizations	More complex to monitor and control
Better horizontal and vertical dissemination of information than functional	Functional managers may have different priorities than project managers
Team members maintain a “home”	Higher potential for conflict
Better coordination	Need extensive policies and procedures
Maximum utilization of scarce resources	Tougher problems with resource allocation

The life cycle of Process, Project, Program, Product

Process: a series of actions bringing about a result. Process is repeatable within an organization.

Project: a project is a temporary endeavor undertaken to create a unique product or service.  The project life cycle refers to a logical sequence of activities to accomplish the projects goals or objectives. 

Program: a program is a group of projects managed in a coordinated way to obtain benefits not available from managing them individually. Sometimes a program management and a project management can be treated as synonyms. A program management can also be treated as superset of subset of project management depend on situations. 

Product: The life cycle lasts from the conception of a new product to its withdrawal.

Light-weight CMMi deployment

I was talking to one of my ex-supervisor in Motorola on his experience of deploying CMMi to another organization out of Motorola. There are some interesting findings about customizing CMMi for different organization cultures.  As Motorola has officially announced closing down of its Singapore Software Center, now we can comment a bit on their CMMi process, and what other organizations can learn from it.

Motorola is famous for the CMMI level-5 deployment to its various software centers across the world. These software centers are such process oriented organizations that low to mid management level take it for granted that the software requirement, design, implementation and testing document must be in place, and process audit must be in place. There are plenty of diagrams, analysis reports generated that becomes over-complicated, for good and bad.

In early 1990s, Software was such a special technical skill that only a small group of elite people can do it well, so Motorola setup various software centers around the world, with software process deployment initiative. Both the organization model and the process proved to be quite effective initially. Later as the software complexity grows, software process also grows to ensure the quality and efficiency of the code, which is excellent. However, these centers are far away from the end customers. The marketing team cannot transfer their pressure to software developers effectively in this organization structure.  The mid-level management turns to process focus, instead of customer focus, because that is the instruction implied by the evaluation process (for sure top management still emphasize they are marketing oriented).  All software projects are internal, which are quite easy going. When the profit margin of software business goes down and the company eco-environment got worse, eventually the company cannot afford this over-complicated business model and close down the center. 

This does not mean it is not possible to marry the good merit of process-oriented approach to innovation-oriented approach. One compromise way we found is to simply the CMMi process and deploy it implicitly. More specifically, requirement and software configuration management are the two most important KPAs a software organization needs to pay attention to, next comes implementation and test define. i.e, to implement what you are required to implement, and test what you are required to test. By telling your customer about implement customer requirement, and control your software team so that the entire team works towards the same goal, instead of working against each other (not personally, but because either Architect or process has flaw, I have seen a lot examples that people work against each other.),  you have the CMMI corner stone lay out.

The process effort should not exceed 5% of the total project effort. If there is no full time process team, then do 2 things:

1. have one internet-savvy young engineer to update and maintain an intranet to publish requirements (it is important to put requirements, designs, … into a common repository). 

2. List the key process flow in one Page (A4), make sure the font size is readable, let the team has free access to it, and have an experienced Engineer to audit regularly (biweekly or monthly).  A white paper (such as Software Development Manual) more than 2 pages is only useful for process team, nobody in the project team will read it. So DON’T waste your time.

In summary, the ultimate goal for an organization is not to reach certain CMMi level (though it is a side output, necessary for many human performance evaluation), but to make the final output predictable and quantifiable. Process is like lubricating oil, you won’t feel it if your machine running smoothly, and it is actually performing its duty implicitly. The most important thing: Software Process must come from real-life experience.  There are endless documents out there, people won’t convinced if you are only repeating a book story.