Một số người quản lí dự án phần mềm (PM) không biết cách xây dựng bản kế hoạch dự án. Họ thậm chí không lập kế hoạch mà chỉ dùng lịch biểu được khách hàng trao cho họ. Họ không xây dựng viễn kiến cho dự án hay ước lượng nỗ lực dự án. Logic của họ là yêu cầu bao giờ cũng thay đổi, sao bận tâm tới lập kế hoạch cho cái gì đó mà sẽ thay đổi? Họ không hiểu mục đích hay ích lợi của bản kế hoạch dự án.

Bản kế hoạch dự án là tài liệu được dùng để trao đổi thông tin giữa người quản lí dự án với tổ dự án và khách hàng. Bước thứ nhất trong xây dựng kế hoạch dự án là đặt chiều hướng cho dự án. Khi dự án bắt đầu, tổ không biết phải làm gì; họ cần “la bàn” để hướng dẫn họ. Viễn kiến dự án là la bàn chỉ cho họ về chiều hướng được người quản lí dự án lập ra. Viễn kiến này giải thích cho họ thành công sẽ là gì; dự án sẽ giải quyết vấn đề gì cho khách hàng; mục đích và mục tiêu là gì và mong đợi của khách hàng là gì. Viễn kiến giữ cho nỗ lực của tổ được gióng thẳng với yêu cầu của khách hàng và mục tiêu dự án.

Bước thứ hai là mô tả vấn đề mà dự án được dự định giải quyết. Các thành viên tổ cần hiểu vấn đề, cũng như giải pháp thành công có thể là gì. Họ cần biết về khách hàng và người dùng. Dự án có thể có một khách hàng hay nhiều khách hàng với các yêu cầu khác nhau. Trong trường hợp này, tổ cần biết cách giữ cân bằng nhiều yêu cầu khác nhau và vẫn đáp ứng được như cầu của khách hàng.

Bước thứ ba là mô tả sản phẩm phần mềm. Cách tốt nhất để làm điều này là dùng Biểu đồ hoàn cảnh, trong đó người quản lí dự án xác định cách phần mềm tương tác với khách hàng hay người dùng, và cách thông tin chảy bên trong và ngoài hệ thống. Biểu đồ này sẽ cho tổ một tổng quan về phần mềm.

Bước thứ tư là mô tả chức năng mức cao của sản phẩm phần mềm. Người quản lí dự án phải mô tả từng chức năng dựa trên các yêu cầu của khách hàng. Nếu phần mềm là lớn và phức tạp, một số chức năng có thể được chia thành các chức năng con cho dễ mô tả. Điều quan trọng là người quản lí dự án kiểm nghiệm các yêu cầu chức năng này với khách hàng để đảm bảo rằng chúng là chính xác điều khách hàng cần.

Bước thứ năm là chia nhỏ các yêu cầu chức năng này thành các nhiệm vụ nhỏ hơn (Cấu trúc phân việc – Work Breakdown Structure) và liệt kê những nhiệm vụ này để cho các thành viên tổ có thể thấy mọi nhiệm vụ mà họ phải làm. Vì các yêu cầu thường xuyên thay đổi do nhu cầu phụ thêm, thông tin mới, hay thỉnh thoảng khách hàng quyết định thay đổi yêu cầu. Những thay đổi này sẽ ảnh hưởng tới mọi thứ trong dự án. Do đó dự án cần có bản kế hoạch để đảm bảo rằng chỉ các yêu cầu đúng là được thực hiện. Bằng việc giữ danh sách hiện thời của mọi nhiệm vụ, thành viên tổ biết nhiệm vụ nào đã bị thay đổi hay sửa đổi, và cách chúng tác động tới công việc của họ. Khi dự án bắt đầu, các thành viên tổ không biết mọi thông tin mà khách hàng muốn cho nên họ dựa hầu hết trên danh sách các nhiệm vụ này. Điều quan trọng là giữ cho danh sách này được cập nhật dựa trên thông tin phụ thêm. Bản kế hoạch dự án sẽ xác định cách giải quyết với các thay đổi, cách thay đổi sẽ được kiểm điểm, và cách danh sách các nhiệm vụ sẽ được cập nhật để đảm bảo rằng dự án sẽ đáp ứng nhu cầu của khách hàng.

Bước thứ sáu là xác định vai trò, trách nhiệm của từng thành viên tổ và phân công cho họ các nhiệm vụ dựa trên kĩ năng và kinh nghiệm của họ. Bằng việc nhận diện các thành viên tổ qua kĩ năng, người quản lí dự án sẽ biết kĩ năng nào sẵn có cho nhiệm vụ nào và kĩ năng nào được cần. Người quản lí dự án có thể nhận diện các thành viên tổ có những kĩ năng này, nếu không người đó có thể phải đi thuê người phụ với kĩ năng đặc biệt để hoàn thành dự án. Điều này là quan trọng bởi vì một số người quản lí dự án thường dựa vào số người sẵn có cho dự án thay vì kĩ năng của họ. Họ lấy cán bộ cho dự án theo số người được cần chứ không theo kĩ năng được cần. Chẳng hạn, nếu dự án cần 10 người thì họ thuê 10 người bất kể tới kĩ năng của họ. Đây là một trong các lí do mà nhiều dự án thất bại. Người quản lí dự án có kinh nghiệm bao giờ cũng lấy cán bộ cho dự án dựa trên kĩ năng chứ không trên số người được cần. Trong bước này, người quản lí dự án cũng nhận diện phần cứng, phần mềm, và trang thiết bị được cần cho dự án và cách chúng sẽ được thu nhận.

Bước thứ bẩy là ước lượng nỗ lực được cần để hoàn thành các nhiệm vụ này. Điều được khuyến cáo là người quản lí dự án làm việc cùng các thành viên tổ mà đã được phân công cho các nhiệm vụ để đi tới một ước lượng cho công việc của họ. Người quản lí dự án phải lấy từng nhiệm vụ và đặt chúng vào trật tự theo đó chúng sẽ được thực hiện rồi tóm tắt chúng trong thời gian được ước lượng toàn thể cần để hoàn thành mọi nhiệm vụ. Bằng việc dùng thông tin này, người quản lí dự án có thể thương lượng với khách hàng về lịch biểu dự án. Lịch biểu dự án nên căn cứ trên thoả thuận dựa trên lịch biểu mong đợi của khách hàng và tóm tắt về thời gian được ước lượng được cần để hoàn thành mọi nhiệm vụ. Người quản lí dự án có thể yêu cầu thay đổi lịch biểu nếu có khác biệt lớn về thời gian được lên lịch và thời gian được ước lượng; hay yêu cầu nhiều người hơn, hay yêu cầu giảm chức năng. Một khi thương lượng này được hoàn thành, người quản lí dự án sẽ cập nhật danh sách các nhiệm vụ và phân ngày tháng để bắt đầu và hoàn thành từng nhiệm vụ cũng như cập nhật ngân sách của dự án (tiền được cấp cho dự án).

Bước thứ tám là lập kế hoạch về chất lượng sản phẩm. Chất lượng không tự xảy ra; nó cần được xây dựng nên. Người quản lí dự án cần nhận diện chuẩn chất lượng theo đó dự án sẽ được đo và cách các thành viên tổ sẽ đo chúng. Chẳng hạn, chất lượng có thể được xác định như việc đáp ứng mọi yêu cầu của khách hàng; có ít lỗi (không quá 1 lỗi trên mười nghìn dòng mã); đáp ứng chi phí và lịch biểu v.v. Chất lượng phải được xác định rõ ràng và được kiểm điểm với cả khách hàng và người quản lí cấp cao để đảm bảo rằng dự án đang tạo ra sản phẩm chất lượng.

Bước thứ chín là quản lí rủi ro. Vì không phải mọi thứ xảy ra bên trong dự án phần mềm đều được biết hết, mọi sự có thể xảy ra bất ngờ vì chúng không thể được dự đoán. Những điều bất định là rủi ro và chúng phải được quản lí. Người quản lí dự án cần nhận diện rủi ro dự án, khả năng xuất hiện của chúng, cách giảm nhẹ chúng và cách trao đổi về chúng cho các thành viên tổ, nếu chúng xuất hiện.

Bước thứ mười là xác định tài liệu dự án. Tuỳ theo độ phức tạp và yêu cầu của khách hàng, dự án có thể được yêu cầu cung cấp tài liệu hỗ trợ như một phần của vật chuyển giao của dự án. Tài liệu bao gồm tài liệu sử dụng của người dùng, trợ giúp trực tuyến, tài liệu cài đặt, v.v.

—-English version—-

Software Project planning: The “Ten-Steps” process

Some software project managers (PM) do not know how to develop a project plan. They do not even plan but only use the schedules given to them by customers. They do not develop vision for the project or estimate the project efforts. Their logic is requirements always change, why bother to plan something that will change? They do not understand the purpose or the benefits of a project plan.

A project plan is a document used to communicate information between the project manager to the project team and the customer. The first step in developing a project plan is to set the direction for the project. When the project starts, the team does not know what to do; they need a “Compass” to guide them. The project vision is the compass that points them to the direction set by the project manager. The vision explains to them what success would be; what kind of problems the project will solve for the customer; what are the goals and objectives and what the customer’s expectation are. The vision keeps the team’s effort aligned with customer requirements and project objectives.

The second step is to describe the problems that the project is intended to solve. Team members need to understand the problems, as well as what a successful solution could be. They need to know about the customers and users. A project may have one single customer or multiple customers with different requirements. In this case, the team needs to know how to balance several different requirements and still meet customers’ needs.

The third step is to describe the software product. The best way to do this is to use the Context Diagram, in which project manager defines how the software interacts with customers or users, and how information flows in and out of the system. This Diagram will give the team an overview of the software.

The fourth step is to describe the high level functions of the software product. The project manager should describe each function based on customer’s requirements. If the software is large and complex, some functions can be divided into sub-functions for easy description. It is important that project manager validates these functional requirements with customers to ensure that they are exactly what the customers need.

The fifth step is to break down these functional requirements into smaller tasks (Work Breakdown Structure) and list these tasks so team members can see all the tasks that they must do. Since requirements often change because of additional needs, new information, or sometime customers decide to change the requirements. These changes will affect everything in the project. Therefore the project needs to have a plan to ensure that only the correct requirements are implemented. By keeping a current list of all the tasks, team members know which task has been changed or modified, and how they impact their works. When project begins, team members do not know all information that customer want so they rely mostly on this list of tasks. It is important to keep this list up to date based on additional information. The project plan will define how to deal with changes, how changes will be reviewed, and how the list of tasks will be updated to ensure that the project will meet the needs of customers.

The sixth step is to define the roles, responsibilities of each team member and assigns them to tasks based on their skills and experiences. By identify team members by skills, project managers will know which skills are available for which task and what skills are needed. Project manager can identify team members that have these skills, if not he may have to hire additional people with specific skills to complete the project. This is an important because some project managers often rely on the number of people available for the project instead of their skills. They staff projects by number of people needed rather than skills needed. For example, if the project needs 10 people then they hire 10 people regardless of their skills. This is one of the reasons that many project failed. Experienced project managers always staff project based on skills not on number of people needed. In this step, project manager also identifies hardware, software, and equipments needed for the project and how they will be obtained.

The seventh step is to estimate the efforts needed to complete these tasks. It is recommended that project manager works with team members that have been assigned tasks to come up with an estimate for their works. Project manager must take each task and put them into the order which they will be done then summarize them into an overall estimated time required to complete all tasks. Using this information, project manager can negotiate with customers on project schedule. A project schedule should be based on an agreement based on customer’s expected schedule and the summary of the estimated time needed to complete all tasks. The project manager can ask for changing schedule if there is significant different in scheduled time and estimated time; or more people; or reduce functionality. Once the negotiation is complete, project manager will update the list of tasks and assign a date to the start and completion of each of the tasks as well as update the project’s budget (Money allocated to the project).

The eight step is to plan for product quality. Quality does not just happen; it needs to be built in. The project manager needs to identify the quality standard to which the project will be measured and how team members will measure them. For example, quality can be defined as meeting all customer requirements; having fewer defects (No more than 1 defect per ten thousand lines of code); meeting cost and schedule etc. Quality must be defined clearly and reviewed with both customers and senior managers to ensure that the project is producing a quality product.

The ninth step is to managing risks. Since not everything that happens within software project is known. Things may happen as a surprise because they cannot be predicted. These uncertain things are risks and they must be managed. The project manager needs to identify project risks, their possibility of occurrence, how to mitigate them and how to communicate them to team members, if they happen.

The tenth step is to define project documentation. Depending on the complexity and customer requirements, a project may be required to provide supporting documentation as part of the project deliverables. Documentation includes user manuals, online help, installation guides, etc.