项目管理方法
Methods of Project Management
by Vox Guo
This article is not called methodology but methods, because it concentrates on the specific ways used in the software development procedure. It focuses more on practical applications than on academic analysis. But as you all known, these conclusions are based on the past project experience and my personal feeling. So it is not confusing if there are some errors. Any further discussions and suggestions, therefore, are welcome.
1. Overview
For the software development procedure, the most pivotal factor is controllable. A disordered project directly causes high cost, prolonged developing period and finally low-quality software product. Of course that is not the result that we would like to see.
In my opinion, when a project finishes, we need not only a stack of software, but also little maintenance (means high quality) and a bridle-wise team and a heritable developing procedure. Inheriting means accumulation and continuity. That is why many great companies can rapidly issue new products to survive from the competitive market. It is just like the words from a famous scientist, “I have gained so much success. Because I am standing on the shoulder of giant.”
For those developing little-sized companies, it is not worthy to manage software project entirely according to procedure of CMM (Capability Maturity Model for Software), because the cost is so high that these companies will lose their flexibility. Software developing, however, should conform to some basic rules for software quality management. It is helpful for the quality of final product.
If I am asked to describe the project management using only one sentence, I’d like to say it is controllable procedure. What I mean is that the quality and schedule should be controllable whichever software phase you are in.
2. Tips for Software Developing
Herein I list some tips for software developing. As the background and habits are different, these tips probably are not available to every person. But if these tips will bring you some further thoughts, I think they are valuable.
2.1 Software Estimation
The working-out for any plan is based on the software size. In case we grasp the software size and architecture cognition for software project, we can originally arrange the manpower resources and schedule. This arrangement must not be accurate. As the software developing procedure goes along and the understanding deepens, however, software estimation will become more and more accurate and also the plan arrangement will press close to practical case.
In the initiation phase of software project, we should carry out the first software evaluation. The software project can be divided into some correspondingly independent functional modules (note: the modules are different from those modules defined in HLD phase). Functional points of every module should be nailed down. According to these functional points, we can evaluate the size of the module through our software common sense (note: some methods are provided by software engineering). Meanwhile we can also realize which module is most difficult and which module is most significant. Once we have these data, our rudimentary manpower resources and schedule are not far from us. At the same time, we can keep our eyes on those difficult and significant modules on which more resources are used.
At the end of every software development phase, such as SRS and LLD, we should re-estimate our software size and adjust our project plan. In fact it is a review procedure to the project plan. The advantages of this review are to make good use of our project resources and find the existing problems in the project. Only through these continuous updates, can the project plan really direct our developing activities. Otherwise it will become a piece of useless white paper with the project going on. Then you will feel that the schedule is always controlled in your hand. Of course, it is a very pleasant feeling.
2.2 Discussion and Review
Software development is a team project. So we think that team spirit is very important, even it is a key to the success of the project. Usually there is not so much time left to software project because of market competition. Every project manager, therefore, should pursue doing a thing well in one time. Discussion and review are good ways to reach that goal.
A good project must have a good developing procedure. It is document that reflects this good developing procedure. How can we finish top-quality documents in limited time? I think there are three significant factors. First of all, before you begin to write, discussion among related team members is required. This discussion includes not only technical problems, but also some details such as document style. Once these problems are solved by the team, the following work is only documental work which is a piece of cake. Secondly, in the process of writing document, if you find new problems that you can’t understand or you think the previous design is wrong, please don’t hesitate to put forward these problems to discuss with your colleagues. Through this continuous discussion, we can converge the wisdoms of all the team members to assure there are few errors left in the final document. With the project going on, our understanding will deepen. Then we maybe find some ignored sectors which will influence our design. So the third factor to get top-quality documents, I think, is the review and upgrade of the finished document whenever we have new findings.
Undoubtedly, for a limited-period project, discussion and review mean abundant cost of time and it is not easy to arrange in most cases, especially in case of work occurring synchronously. The key to resolve the problem is elaborate partition for time and manpower. Giving an example, if we have some documents to review next week, it is reasonable to finish arrangement in this weekend. This arrangement includes attendees, time, sites and duration of every review. Only through this careful arrangement, can we avoid conflict of review. Usually before the formal review, we leave time to team members to prejudge the review content. In the review meeting, in order to save time, the only aim is finding problems, not solving problems. Further discussion should be held after the review meeting. Meanwhile we should adopt some steps to trace the problems found on the review meeting to avoid missing.
It is worth using plenty of time on discussion and reviews, because many personal errors are exposed in discussion and reviews. At the end of our project, we find that the value of discussion and reviews is incredible. Additionally, through this continuous communication and cooperation, we know each other better and the effectiveness of the team has been strengthened.
2.3 Venture Management
Venture occurs everywhere. In the process of software developing, we will meet many difficulties and we will indeed try our best to overcome them. On the other hand, we still need to forecast the ventures we will encounter in the future and take action to decrease the influence of those potential ventures. This is the concept of venture management.
For a software project, the most serious venture is manpower. Most projects are divided into different functional modules managed by individual engineer. Can you imagine some engineer leave the company suddenly? To avoid catastrophic sequent, manpower backup plan should be initiated in the beginning phase of software project.
How can we process manpower backup plan in case of lacking engineers, which is occurring in many companies? Although we have no way to make some engineers backup the other engineers, it is possible that some engineers are partly in charge of other modules. At least they must understand the basic principle of other modules. This thought can be realized in the process of discussion and review if we make management reasonably. If one engineer is selected as a candidate to a module, he should take part in all the discussion and review related to this module. That is to say he is relative to this module. When a project manager lays a course, therefore, he should consider this relationship. As long as we stick to this method, that engineer or more engineers will be familiar with that module which is not in the scope of his or their charge essentially. As a result, even if this venture becomes reality, the project can survive more smoothly.
There are other ventures beside manpower, such as lab equipment, tool software and test environment. All these ventures should be recorded and traced. Meanwhile the project should have a plan to reduce the effect of the ventures. While one venture disappears, the record related to this venture should be closed. At the end of every developing phase, project manager should call a meeting to discuss which venture we will probably meet in the next phase. It is just like a saying, “Although it does not rain, we should get the umbrella ready. ”
3. Epilogue
There are many factors determining the success of a software project. After all person with ability is the most important resource in a company. For most companies, we think that controllable and regular developing procedure is also an essential condition. Efficiency from the combination of person with ability and fine developing procedure will be incredible.
