Home >

Project Document Management From Project Handover

2009/5/6 14:28:00 42070

Project documentation is no longer required for project management, but the management of documents is usually the most easily neglected content in project management.

Actually, for any project, documents must be available, but not necessarily many, as long as the problem can be explained.

Recently, I am taking over a project, taking this project as an example to explain my experience.

This project has been developed and implemented, and has a certain customer base.

When taking over the project, the project has only results and no process.

There is only a complete user manual.

In response to this request, we need to add the following documents:

First, the results description document: all current deliverables, content descriptions and results assessment need to be explained.

The product description should at least describe the following:

1) the existing forms and status quo of results: for software projects, basically the results are in the form of executable code, but we must clearly specify the status of the code, whether it has been tested, if tested, it is necessary to submit relevant test reports, if not tested, whether it has been completed, after completion, if not completed to what extent, especially if there is no annotated code, should clearly explain the code to achieve the functional description and interface description.

2) the description of the research and development process: it mainly explains the traceability process of the results, where the code comes from, and whether it has the corresponding plan content. If not, what is the last step of the achievement, taking the code as an example, whether there is a design in the code part, whether there is a demand analysis in the design link, and so on.

This part of the code is based on what to do R & D.

If a result is not traced back to the initial stage, we need to pay attention to it.

3) availability of results: it is not that the final results will be effective and usable.

It may hide a lot of problems, which requires the relevant stakeholders to make usability descriptions. We all know that under the specific circumstances, we may adopt a temporary plan to realize a function, and then modify it when it is finally integrated, but in many cases, this temporary plan has become the final plan.

Therefore, we must explain the effectiveness of the results, if not, we must carry out strict testing and acceptance.

4) the result responsibility person explains: must have, is not seeks the responsibility, but is advantageous for the communication.

Submission results	type	Address of existence	current state	Final assessment
Description of deliverable content For example: * unit design document.* Module source code	Code File Design document	Current storage address	Completed and used Completed unused Hang in the air cancel	Availability and process integrity Available only results Usable part process Submission is not available Not submitted Hang in the air
Order automatic generation module	VB Code	VSS\sourcecontrol\Order	Completed and used	Available results Requirement documents, no design documents.
Order form	Documents (requirements raw data)	No electronic version, custodian: x x*	Completed and used	Availability and process integrity

Two. Plan management statement document: if a complete Porject plan is the best, but this document must pay attention to its accuracy. When using Project to plan management, it is often the longer the project progresses, the more changes, the more difficult it is to plan and maintain. At this time, it is possible that the plan can not reflect the actual project progress.

Plan management documents must be carefully studied, whether the whole project plan is properly arranged, what tasks have been formulated, but which tasks have not been completed, which tasks have been cancelled, whether these cancelled tasks belong to the predetermined functional requirements, which links have not been carried out, which links have been repeatedly reprocessed, and the interruption of tasks occurred during the work process, which can be seen from the plan management document, which is more conducive to assess the actual situation and risk situation of the project, and can be perfected according to the imperfect contents in the previous stage.

At the same time, the key point is whether there are abnormal situations in these tasks, such as: you think the difficult technology research and development work has been completed in a short time, all of which need attention and understand the actual situation.

Finally, through the plan management statement, the target is confirmed.

The content that has been completed should be consistent with the results presented above. If there is no document in this part, it is necessary to supplement the whole process according to the corresponding results and staff.

After completion of this document, it can also become a basis for subsequent management and optimize the processing.

If there is no plan to manage documents, when supplemented, it is recommended to use Project to complete, the first result is submitted to the document, and it is best to use WBS to organize the task arrangement, and submit the submitted corresponding to the corresponding tasks.

Through the explanation of the state of the previous document, mark the unfinished content and see whether there are different tasks in the same task, which should belong to repetitive tasks and marking.

Three. Requirements specification: it is necessary to explain the initial demand of the product. In fact, the importance of the requirement specification has been greatly reduced for the product I am currently taking over, because the product has been developed and completed, and a complete user manual has been provided. However, there are two main purposes for sorting out the demand note:

1, it is necessary to establish a complete process traceability process to prepare for the follow-up work.

2, verify the effectiveness and availability of the results through requirements.

The requirement specification is a document that can be simplified and complex. In this project, the requirement manual is more about extracting the needs from the user's manual, and the actual meaning is not very big.

But if it is to make a new project, the requirement specification should be the most probable way to describe the user's business and not to adulterate personal understanding.

As to whether or not it can be realized, how to achieve it is a matter of follow-up work, not the content of this link.

Four. System design specification: the system design specification is now unable to consider the design problem at this time, but the following contents should be provided at this time:

1, the system architecture design and structure adjustment in the application process.

And it is best to provide structural analysis of defects.

2, interface design specification and interface specification and design specification.

Now the system is basically loose, through the interface standards to achieve the ultimate integration of the system, so the interface part is very critical, this part of the content must be very clear and accurate.

3, if the design documents can no longer be provided, it is suggested that the design of the third party tools should be generated according to the code of the results, and the documents should be supplemented on this basis. The design is better than the code, so this part should be provided.

If in this new project, this part of the content page suggests consideration, mainly planning interface calls, object functions and object relationships.

Five. Database design specification.

I still attach great importance to database design. Although there are many tools for DAO and object modeling, the actual application process is very few, especially for data analysis.

So I think this document is still very important.

As for the format of documents, because this aspect has been very "standardized", it is not being explained.