Project Management in China

Project Management in China -By Professor Hubert Vaughan
Institute of International Engineering Project Management, Tsinghua University

PMBOK was introduced to China at the beginning of this 21st Century. Since its early introduction, professional and senior management realized the advantages and benefits of project management practice can help them minimize project delay, reduce project cost, improve product and  service quality, and utilize their technical resources effectively.

After seven years of learning and using PMBOK contents, the current status of project management practice in China is encouraging. More than fifteen thousand professionals are certified by PMI, and numerous organization hiring and training project managers to manage their projects. However, the end result is not encouraging. Project Managers still find their projects being delayed, cost over-run, quality had not improve, and still lack of resources to perform project tasks. Most organizations, specially IT and Telecom groups, are unable to determine the value of project management practices and the return of their investment on training project manager.

Few in China realized the fact that project management is in fact a management culture, a culture that must embedded into the project delivering models in order to maximize the management knowledge in practice, and make project management worked.

Project Delivery Models

Most projects delivered in China do not have a well defined, structured delivery approach. A simple 3-stages delivery process was use in most projects, the initial Preparation Stage, the central Execution Stage, and the final Close-up Stage. The Execution Stage is a cycle of Analysis,
Design, Construct, and Review, which make the Execution Stage a continuous Code and Fix cycle until project objectives are archived, or the original concept have to be modified to suit the end result, or perform the necessary patch up work to close the project.


Project Delivery Model is the key factor for successful project management practice. Project failed if any one of the project delivery stage runs into a continuous cycle of repetitive activities. This 3-stages project delivery model always starts off with an ill-defined project objectives. It will not allow project managers to determine the project baseline. It will not be able to determine the overall project time-line because one will not know how many cycles are needed to finalize the Execution Stage. As a result, the project cost, resources requirement, delivery efforts cannot be estimated, quality plan and milestones cannot be determined. Project Management knowledge cannot map the delivery model effectively to manage the project progress.

We are all used to a well defined, structured approach in project delivery which is known as Project Life Cycle. We planned and manage activities in each of the well defined delivery stages. This allows us to estimate efforts, estimate project investment and resources requirement. As a
project manager, we have to define project scope and manage subsequent delivery stages. The project scope is the foundation of project success. Our estimates which formed the project base-line and our quality plan for the final deliverable all depends on the project scope. Scope
deviation and change will drive us into the repetitive cycles of delivery model. That is why we have to manage the scope and the change requests so diligently during project delivery.



Even under a well-defined project life cycle, project simply failed if we do not manage stage end deliverable according to the project milestones, or if our cost and effort estimates are not developed according to our project plan with appropriate skilled resources assigned.
Successful project management depends on a well defined project delivery model. Harmonization of Management Methodology and Delivery Model is the key to successful project management. Most project managers failed to integrate his/her management process with the delivery model and find it difficult to plan and track.



The most critical stage within a project life cycle is the Concept stage, which formed the basis of project scope definition. We are no longer in the Automation age where IT projects are simply turning a business process into a computer application. Most projects nowadays are concept
oriented, to achieve the final deliverable from vision instead of a business process. Therefore most project managers find it difficult to define project scope all over the world and projects runs into repetitive cycle along our delivery processes.

Managing Project Scope or Project Deliverable
We had been trying to determine Project Scope through Statements of Work (SOW), sometimes known as Requirement Statements inside the Project Charter. Most Project Managers also conduct Requirement Gathering to finalize project scope. Unfortunately few Project Charters, or
Fact Finding exercise, can identify all requirements that allow us to form a well defined project scope that enable us to deliver the Project Objective Statement. The completeness of these SOW, RS, and our interpretation of the Requirements may vary, and technology subsequently deploy in
creating the solution, may produce different result causing in-consistent deliverables. A slight misinterpretation of the requirement may land us miles away from the original project goal. We are trying to produce solution that formed the final deliverable based on these uncompleted or
misinterpreted RS while project sign-off based on deliverable.

We often look at information given to us by Stake-holders as requirement. It is in fact far from truth. What Stake-holders told us “they needs……(this), they needs …..(that)” functions in the final solution really means that they want to see these functions available at the end of the project. It is not exactly requirement, it is a WISH list.
We may define the so called project scope at the start of a project based on Project Charter or project SOW, we are continuously refining our requirement during fact finding and analysis stages.
These refinements can and will become part of the Do and Fix cycle causing scope change and affect our project base line. Thus managing Project Scope converted from these RS cannot effectively manage project deliverable expected in Conceptual Stage. Therefore I have beenmanaging project deliverable in Projects instead of managing project scope during the last few years in China.
Are Engineers a “craftsman” or a “Professional”?
I always start a new PM class by telling my graduate student a story for them to think about. A few years after their graduation, he or she had saved up enough money to pay for a new house, and wish to re-model the interior that suit his/her living style. The new home-owner will spend time to define and determine their needs in their new home, and told the home-builder to build it the way he or she dreams of. The home-builder builds it according to the requirement given by the new owner, and dare not change the requirement. The home-owner provides all the requirements,
and the home-builder, the craftsman, build it accordingly. Engineers today asked for requirements, like the home-builders, from system owners how they want the system. And always put the blame on the System owner for not able to tell the engineers “the requirement”.
If 30 years passed by, the once new home owner is ready to retire, made enough fortune to live in luxury, and brought a villa near the lake for his or her retirement. At this stage, the Villa owner no longer spend time in defining and determining his/her needs for the villa. Instead, an Interior
Designer will be called in, and told the Designer how he wants the villa to be like, without too much requirement, just a concept of how he wants it. The Designer will define the requirement for the villa-owner, and based on the designer’s experience and skills, convince the villa-owner
how to best use his villa, and painted a nice and pret ty picture of how the villa look like into the mind of the owner. The requirements are developed by the Designer to the owner once the final deliverable is confirmed. In this case, the Designer is a true Professional.
Now, let us ask ourselves a question, are we a “craftsman” or a “professional”. Why can’t we define user’s requirements by confirming  deliverable? After all, our project sign off are based on deliverable we accomplished, and today’s technology is so diversified that same requirement built by different technology application will have different deliverable. No wonder we have such a hard time in getting our sign off.

Project Component Decomposition Method
In fact, I was using a method developed during the last 10 years or so for the purpose of identifying project deliverable based on Project Objective, i.e. what do we want to perform? I consider SOW as functions we want to perform in our final deliverable. This method I called “Project Components Decomposition Method” had been used in numerous projects during the last few years to define project deliverable.



Managing projects requires Project Managers to view the requirement or SOW in Project Charter as project objectives. Evaluating each and every project objectives to come up with project’s Benefits Statements (i.e. what is expected to achieve at the end of the project). Then analyze the
approach we can use to achieve each benefit. There may be one or more approaches to achieve each Benefits Statements and sometimes two or more approaches can lead to the delivery of one single benefit. Likewise, each approach can have various solutions that can convert as project
deliverables.
The requirement can than map with each of the solutions and see how well it fit into the overall needs. Project Scope can derive from these Project Deliverable and requirement is a component of building the final deliverable. Knowing what we need to produce enable us to manage the
construction processes, which means managing the Project Objectives.

Managing Project Baseline
The Code and Fix Execution Stage will not allow project manager to develop realistic project baseline. Without knowing the construction process of stage end deliverable, any number representing timeline, effort, cost, resources, and quality are baseless. It cannot be used to measure against progresses and determine variances.
Most of the so called project baseline in China is the end result of “a snap of the fingers”. Either it is based on past experience, or gut feel, the number is there as a financial guide. Instead of managing project baseline, we are managing project guidelines instead.

Managing Progress and Budget
This financial guide management approach will affect the way we manage progress in a Code and Fix environment. We can no longer manage progress by what we achieved because we never know when the project will reach its goal and close we have to manage by “what need to do” within available financial guide. To do this, we have to truncate project work into small interim deliverable (work package with a clear identifiable interim deliverable) and estimate the effort and cost for the Work package. When the interim deliverable is completed, reduce of cost of
delivering the Work package and re-calculate the cost of what work need to do to close the project. If the end-result of the Work package is not meeting delivery requirement, then maintain the management focus on the Work package until it meet its goal. All Fix Work (time and cost) will be reduced from the original guide and calculate the balance available.



This will force the technical team to spend more time thinking about Work package delivery instead of project deliverable. The weekly progress report should emphasis “works remain to complete” instead “what is done”. This will enable Project Manager to identify, at anytime of the
project life cycle, remaining work, available budget, and effort remaining.

Managing Planned activities and Un-Planned Activities
At the beginning of each work package, the project manager should identify tasks to complete the work package deliverable. Team members should report the planned tasks, as well as the un-Planned task. Project manager should review each un-planned task and determine if it is
necessary for the completion of the interim deliverable. If it is not necessary, all work on the un-planned task should be halted immediately.
If the un-planned task is a must for the interim deliverable for the assigned work package, then the project manager should update the project plan and re-adjust the project schedule for the remaining Work Packages of the project to meet its original goal.

Managing Solution rather than Problem Reporting
When the project encounters a technical difficulty that holds up project progress, instead of simply reporting the problem, project team members should consider how to solve the problem and the estimated time it will take to overcome the technical difficulty. They should also report who can help resolve the problem, or where solution can be found and how he/she intends to resolve the problem, report on the new completion date so that project manager can adjust project plans accordingly, and estimate project impact based on the revised completion date for the Work Package.

The Challenges for Project Managers in China
The above highlight some of the major differences of managing projects in China compared to that in the West. We cannot change the culture and the local work habit overnight. We have to adapt our management methodology to suit the local culture that makes Project Management work. By enforcing this management mechanism, we may one day change the Code and Fix mentality to a well structured delivery process. The knowledge we learnt from PMBoK remains unchanged, it is just that we have to look at the box that contained Project Management Knowledge from outside the box instead of from within the Box.

Hubert Vaughan
Professor of Project Management
Institute of International Engineering
Project Management Tsinghua University
Beijing, China

Professor Hubert Vaughan is a graduate of Melbourne University in Australia, with an MBA from York University in Canada. Professor Vaughan commenced his career with National Mutual Insurance in the field of Information Technology in 1972. During the last 30+ years, he has lived on all five continents and held senior technical and management positions with such international organizations as IBM, DEC, Unisys, Tandem, Cable & Wireless, Bell Canada, ANZ Banking Group and Bank of Montreal. His career has covered software development, professional services,  echnology consulting, project/program management, strategic planning as well as business development. Mr. Vaughan is a Professor at the Institute of International Engineering Project Management of Tsinghua University, Beijing, China. He also teaches PM at the Graduate School of the
China Academy of Science; Software College of Beijing University of Astronautics and Aeronautics; Software College of Nankai University, and the
School of Software Engineering of the Harbin Institute of Technology. Apart from his teaching engagements, Hubert also acts as consultant for several State owned organizations in China. Professor Hubert Vaughan is an International Editorial Advisor for PMForum and PM World Today; he can be contacted at hubertvaughan@pm.tsinghua.edu.cn. Additional information can be found at http://www.pmworldtoday.net /team/editorial_advisors.htm.