Một người quản lí mới viết cho tôi: “Tôi là người lãnh đạo tổ vừa mới được cử làm quản lí một dự án mới. Tôi muốn là người quản lí dự án thành công và bắt đầu dự án theo cách tốt nhất có thể được. Tôi có thể dùng kĩ năng nào từ người lãnh đạo tổ trong việc làm mới này và tôi cần cải tiến cái gì khác?”
Đáp: Có khác biệt giữa người lãnh đạo tổ và người quản lí dự án. Người lãnh đạo tổ chịu trách nhiệm về khía cạnh kĩ thuật của dự án bằng việc cung cấp việc lãnh đạo cho một tổ nhỏ (ba tới bẩy người) để thực hiện các chức năng nào đó của dự án. Người lãnh đạo tổ động viên các thành viên tổ làm việc hướng tới thành công dự án. Người quản lí dự án chịu trách nhiệm cho toàn thể dự án, cả về khía cạnh kĩ thuật VÀ quản lí. Người quản lí dự án kiểm soát và quản lí nhiều tổ bên trong dự án để hoàn thành mục đích của dự án. Là người quản lí dự án mới, bạn cần có đào tạo thêm và kinh nghiệm để thành công. Nếu công ti của bạn không cung cấp đào tạo thì bạn cần lấy đào tạo riêng cho bạn bởi vì người quản lí phần mềm KHÔNG phải là cái gì đó bạn có thể học trong việc làm hay bằng đọc sách.
Để bắt đầu dự án phần mềm, bạn cần biết khách hàng và người dùng của bạn là ai. Khách hàng là người trả tiền cho dự án; người dùng là người dùng sản phẩm của bạn. Khách hàng quan tâm tới lịch biểu; người dùng quan tâm tới tính năng và chất lượng của sản phẩm. Là người quản lí dự án, bạn cần nói chuyện với cả khách hàng và người dùng để tìm ra đích xác điều họ mong đợi từ dự án và nhu cầu của họ là gì. Nếu có nhiều khách hàng và người dùng thì bạn cần nói chuyện với tất cả họ vì họ có thể có những cách nhìn và mong đợi khác nhau và bạn cần biết tất cả các quan điểm của họ.
Từ những quan điểm này, bạn phải tổ chức các mong đợi và yêu cầu đó thành một danh sách ưu tiên những điều cần làm vì bạn không thể làm mọi thứ một lúc được. Bạn cần thẩm tra danh sách ưu tiên này với cả người quản lí của bạn VÀ khách hàng để chắc rằng họ đồng ý với nó. Một khi được chấp thuận, danh sách ưu tiên này sẽ là yêu cầu sơ bộ cho dự án của bạn. Bạn phải dùng Cấu trúc phân việc (WBS) để chia từng yêu cầu thành nhiều chức năng và từng chức năng thành nhiều nhiệm vụ nhỏ hơn. Bạn phải ước lượng thời gian để hoàn thành những nhiệm vụ này tương ứng với ưu tiên và sự phụ thuộc. Bằng việc thêm thời gian để hoàn thành những nhiệm vụ này cùng nhau, bạn đi tới “lịch biểu dự kiến” cho dự án. Bạn cần xác định liệu lịch biểu dự kiến của bạn có sánh đúng với mong đợi lịch biểu của khách hàng không. Nếu không, bạn sẽ cần thảo luận với người quản lí của bạn và khách hàng để đi tới lịch biểu thoả đáng. Từ danh sách các nhiệm vụ ưu tiên, bạn cần ước lượng số người mà bạn cần để thực hiện chúng. Có người thiết kế, người phát triển, người kiểm thử, nhân sự hỗ trợ như người quản lí cấu hình, đảm bảo chất lượng v.v. Bạn cũng cần quyết định về phương pháp và công cụ nào để dùng cho dự án của bạn.
Bằng việc đạt tới bước này, bạn phải biết: Ai là khách hàng và người dùng; mục đích của dự án là gì; nhiệm vụ nào là ưu tiên và nhiệm vụ nào không; nó mất bao nhiêu thời gian; và bạn cần bao nhiêu người để thực hiện dự án; bạn cần phương pháp và công cụ nào cho dự án. Tất cả các khoản mục này đều phải được làm tài liệu trong bản kế hoạch dự án sơ bộ.
Sai lầm chung mà những người kĩ thuật thường phạm phải là hội tụ ngay vào mỗi chức năng chi tiết. Đó KHÔNG phải là cách tốt nhất để bắt đầu một dự án phần mềm. Điều quan trọng cho bạn là hiểu toàn bộ hoàn cảnh dự án và lí do tại sao khách hàng cần dự án này. Nói cách khác, cách tốt nhất để bắt đầu dự án là hiểu chỗ bạn được giả định sẽ kết thúc. Dự án này được giả định hoàn thành cái gì mà sẽ đem lại ích lợi cho khách hàng và công ti của bạn. Điều đó nghĩa là bạn phải lấy bản kế hoạch dự án và kiểm điểm cùng khách hàng để đi tới thoả thuận về lịch biểu, tài nguyên, công cụ, phương pháp, cũng như bất kì rủi ro nào liên kết với dự án. Khách hàng càng biết nhiều về kế hoạch của bạn, họ càng tin tưởng hơn vào bạn và dễ dàng hơn trong thương lượng với họ về tài nguyên dự án và lịch biểu (tức là bạn cần bao nhiêu người để thực hiện dự án; nó sẽ mất bao nhiêu thời gian; nó sẽ tốn bao nhiêu v.v.). Phần lớn các khách hàng thường đặt lịch biểu không hiện thực lên dự án vì họ không có ý tưởng nào về lịch biểu cho nên họ chỉ đoán chừng. Điều quan trọng cho bạn là chỉ ra cho họ phân việc của bạn, ước lượng của bạn và kế hoạch của bạn về dự án vì trong thảo luận, bạn có thể phải thu gọn phạm vi hay tăng thời gian hoàn thành. Không có bản kế hoạch dự án tốt mà nhận diện rõ ràng khối lượng thời gian được cần để hoàn thành từng nhiệm vụ và số người được cần cho nhiệm vụ, bạn không thể thuyết phục được khách hàng hỗ trợ cho bạn.
Thương lượng dự án là kĩ năng mấu chốt mà người quản lí dự án phải làm. Để làm cho dự án bắt đầu theo cách tốt nhất có thể, bạn sẽ cần thương lượng lịch biểu với khách hàng để đi tới cái gì đó hợp lí, bằng không dự án sẽ thất bại. Có thay đổi phạm vi dự án (giảm chức năng) hay thay đổi lịch biểu (nhiều thời gian hơn hay ít thời gian hơn); hay thêm hay giảm số người v.v. Bạn có thể không có được điều bạn muốn và khách hàng có thể không có được điều họ muốn nhưng có thảo luận để đi tới thoả thuận nào đó trước khi bắt đầu dự án sẽ giúp cho cả hai bên tránh được nhiều vấn đề về sau.
Thương lượng dự án là khi bạn có thể thực sự phát triển hiểu biết rõ ràng về mục tiêu dự án và mong đợi của khách hàng. Bằng thảo luận và thương lượng, bạn sẽ có khả năng nhận biết về bất kì rủi ro hay vấn đề tiềm năng mà bạn có thể đương đầu về sau nữa. Quản lí rủi ro là khía cạnh nền tảng của việc quản lí dự án tốt. Bằng việc biết các rủi ro, bạn có thể tránh được chúng, thay đổi chúng, hay làm giảm bớt tác động của chúng lên dự án của bạn. Đây là lúc để khách hàng biết về rủi ro của dự án cho nên cùng nhau bạn và khách hàng đi tới bản kế hoạch quản lí rủi ro.
Sau khi có thoả thuận với khách hàng, bạn có thể thay đổi bản kế hoạch của bạn tương ứng. Thế và chỉ thế bạn mới xác định được ai phải ở trong tổ dự án của bạn, liệu bạn có người đã làm việc cùng bạn trước đây hay bạn có thể thuê người mới phụ thêm. Bạn cần thảo luận với tổ dự án về hiểu biết của bạn về mục tiêu dự án, trao đổi với họ về điều bạn đã được yêu cầu làm, và thảo luận với họ về bất kì nhu cầu đào tạo nào để làm cho dự án bắt đầu theo cách tốt nhất có thể được. Đây là lúc bạn chia sẻ với tổ về viễn kiến của bạn, mục đích của dự án và cách bạn giám sát tiến độ dự án. Tổ phải hiểu đầy đủ và quyết tâm hỗ trợ bạn. Cuộc họp tổ này là nền tảng mấu chốt cho việc tiến sang bước tiếp, nơi tổ sẽ bắt đầu làm việc trên chi tiết dự án.
—English version—
Starting a new project
A new manager wrote to me: “I was a team leader who just gets promoted to manage a new project. I want to be a successful project manager and start the project in the best way possible. What skills from team leader can I use in this new job and what else do I need to improve?”
Answer: There is a difference between a team leader and a project manager. Team leader is responsible for the technical aspect of a project by provide leadership to a small team (Three to seven people) to implement some functions of the project. Team leader motivates team members to work toward the project success. Project manager is responsible for the entire project, both technical AND management aspects. Project manager controls and manages several teams within the project to accomplish the project’s goals. As a new project manager, you need additional training and experiences to be successful. If your company does not provide training then you need to take training on your own because software project manager is NOT something that you can learn on the job or by reading a book.
To start a software project, you need to know who your customers and users are. Customers are people who pay for the project; users are people who use your product. Customers are concerned with the schedule and cost of the project; users are concerned with the features and quality of the product. As project manager, you need to talk with both customers and users to find out exactly what they expect from the project and what their needs are. If there are several customers and users than you need to talk to all of them since they may have differing views and expectations and you need to know all of their viewpoints.
From these viewpoints, you must organize them into a priority list of thing to do because you cannot do everything at once. You need to verify this priority list with both your manager AND customers to make sure that they agree with it. Once approved, the priority list will be the preliminary requirements for your project. You must use the Work Breakdown Structure (WBS) to break each requirement into several functions and each function is broken down into several smaller tasks. You must estimate the time needed to implement each task according to the priority and dependency. By adding the time to complete these tasks together, you come up with a “tentative schedule” for the project. You need to determine whether your tentative schedule matches customer’s schedule expectations. If not, you will need to discuss with your manager and customers to come up with a reasonable schedule. From the list of priority tasks, you need to estimate the number of people that you need to implement them. There are designer, developers, testers, support personnel such as configuration manager, quality assurance etc. You also need to make decisions on which method and tools to use for your project.
By reaching this step, you must know: Who the customers and users are; what the project goals are; which tasks are priority and which are not; how long it may take; and how many people you need to do the project; what method and tools that you need for the project. All of these items must be documented in a preliminary project plan.
The common mistake that technical people often make is focusing on the detailed functions right away. That is NOT the best way to start a software project. It is important for you to understand the entire project context and the reason why the customers need this project. In other words, the best way to start the project is to understand where you are supposed to finish. What is this project supposed to accomplish that will benefit the customers and your company. That means you should take the project plan and review with your customers to come up with an agreements about schedule, resources, tools, methods as well as any risks associated with the project. The more the customers know about your plan, the better confident they will have on you and it is easier to negotiate with them on project resources and schedule (i.e., how many people you need to implement the project; how long it will take; how much it will cost etc.). Most customers often place unrealistic schedule on the project because they have no idea about schedule so they just guess. It is important for you to show them your work breakdown, your estimates and your plan of the project because during the discussion, you may have to reducing the scope or increasing the time for completion. Without a good project plan that have clearly identify the amount of time needed to complete each task and the numbers of people needed to do the tasks, you cannot convince the customers to support you.
Project negotiation is a critical skill that project managers must do. To get the project starting in the best possible way, you will need to negotiate the schedule with customers to come up with something reasonable, else the project will fail. It is possible to change the scope of the project (reducing functionality) or change schedule (more time or less time); or adding or reducing number of people etc. You may not get what you want and the customers may not get what they want also but having a discussion to come up with some agreements before starting the project will help both sides avoid a lot of problems later.
Project negotiation is the time when you can really developing a clear understanding of the project’s objectives and customers’ expectations. By discussion and negotiation, you will be able to aware of any potential risks or problems you might encounter later too. Risk management is a fundamental aspect of a good project management. By knowing the risks, you can avoid them, change them, or lessen their impact on your project. This is the time to let customers know about project risks so together you and customers can come up with a risk management plan.
After having an agreement with customers, you can modify your project plan accordingly. Then and only then you will determine who should be on your project team whether you have people that have worked with you previously or you may have to hire additional new people. You need to discuss with the project team about your understanding of the project’s objectives, communicate with them on what you have been asked to do, and discuss with them about any training needs to get the project start in the best way possible. This is the time where you share with the team about your vision for the project, the goals of the project and how do you monitor the progress of the project. The team must fully understands and commit to support you. This team meeting is the critical foundation of moving on to the next step, where the team will begin to work on the detail the project.
