Với cấu trúc này, người phát triển có thể cảm thấy không thoải mái và khó điều chỉnh. Điều đầu tiên là thiếu hiểu biết về điều người khác làm. Để cho tổ được hiệu quả, mọi thành viên tổ đều cần hiểu mọi vai trò, trách nhiệm và thẩm quyền bên trong qui trình phát triển của dự án. Bằng việc hiểu rõ ràng chúng, họ có thể tránh xung đột thường xảy ra  trong dự án lớn. Điều thứ hai là vấn đề với cách làm việc tổ và kĩ năng mềm. Trao đổi hiệu quả, lắng nghe, động viên, và dẹp bỏ “bản ngã cá nhân” là các ví dụ về “kĩ năng mềm” được cần tới cho tổ hiệu quả. Thiếu những kĩ năng này thường dẫn tới quyết định không hiệu quả, họp không hiệu quả, và nhiều xung đột cá nhân hơn. Khó khăn thứ ba là không tuân theo qui trình đã xác định của dự án. Cho dù nhiều dự án có đào tạo về qui trình nhưng chừng nào còn chưa có chỉ đạo rõ ràng và cơ chế giám sát mạnh tại chỗ, thành viên tổ có thể làm nhiều điều dựa trên kinh nghiệm riêng của họ thay vì tuân theo qui trình được người quản lí dự án xác định.

Trong quá khứ, khi các dự án còn nhỏ, có thể năm tới hai mươi người, những người phát triển có cách làm công việc riêng của họ qua qui trình cá nhân “không chính thức”. Sau khi chúng được thực hiện, công việc của họ thành chủ đề để kiểm điểm và kiểm thử cho tới khi chúng được khách hàng chấp nhận. Cho tới khi họ làm cho việc của mình được hoàn thành, người quản lí dự án không quan tâm về cách họ làm cho công việc của họ được thực hiện hay họ tuân theo qui trình gì. Trong dự án lớn, đôi khi hàng trăm người tham gia, trình tự phát triển thay đổi. Qui trình để tạo ra phần mềm phải được xác định và phân công vì việc phát triển bây giờ bao gồm nhiều người thế với nhiều việc phải được tích hợp. Người quản lí dự án không thể cho phép mọi người làm bất kì cái gì họ muốn hay tuân theo bất kì qui trình nào họ thích, điều đó sẽ là hỗn độn.

Tổ phải hiểu qui trình được xác định của dự án vì công việc của họ phải được tích hợp dựa trên kiến trúc. Chẳng hạn, tổ phải đồng ý về những đặc trưng thiết kế nào đó là hướng dẫn cho các cá nhân làm công việc riêng của họ. Tổ và cá nhân làm mịn lặp đi lặp lại và đồng ý với nội dung như nó được tạo ra. Kết quả là sự cộng tác với trách nhiệm chung về sản phẩm. Về căn bản, dãy công việc được đảo ngược với kiểm điểm xuất hiện trước sáng tạo cá nhân. Trong kiểu công việc này, môi trường cộng tác tạo khả năng cho mọi người có truy nhập ngay vào sản phẩm công việc khi chúng đang được tạo ra để thực hiện có hiệu quả dự án lớn khi nhiều việc đang tiến hành đồng thời. Đây là lí do tại sao dự án lớn là khó vì nó yêu cầu nhiều lập kế hoạch, điều phối với các vai trò và trách nhiệm được nhận diện rõ ràng thậm chí trước khi dự án bắt đầu.

Cấu trúc dự án phải dựa trên việc phân chia chính xác vai trò và trách nhiệm của thành viên tổ để tạo ra bầu không khí làm việc năng suất; tránh việc trùng lặp nỗ lực tốn kém; cải tiến trao đổi giữa những người tham gia; động viên việc tự quản về phần những người tham gia trong việc thực hiện trách nhiệm của họ. Về căn bản, vai trò là chức vụ trong cấu trúc tổ dự án. Vai trò tương ứng với một tập các trách nhiệm. Một số người tham gia có thể giữ một vai trò và một số người tham gia có thể giữ nhiều vai trò. Điều này thông thường tuỳ thuộc vào phạm vi của dự án. Trách nhiệm là hoạt động được tiến hành bởi người tham gia trong một khu vực đặc biệt. Nó ngụ ý quyền ra quyết định và bắt buộc giả định nhận hậu quả của quyết định của người ta. Việc phân công rõ ràng vai trò và trách nhiệm là cần thiết để đảm bảo rằng từng thành viên tổ trong dự án biết đích xác cái gì được mong đợi từ họ và các thành viên khác trong tổ.

Để có hiệu quả tốt hơn, từng tổ phải có mục tiêu xác định với thủ tục ra quyết định thống nhất. Tổ phải nhận được đào tạo nhiều tuần trước khi dự án bắt đầu và đào tạo phải giải thích rõ ràng trình tự công việc, kiến trúc tổng thể và cơ chế giám sát. Tất nhiên, không phải mọi người đều sẽ đồng ý với cách dự án đang được tổ chức cho nên sẽ có thách thức và đây là chỗ kĩ năng của người quản lí và kiến trúc sư hệ thống được cần tới để giải quyết loại tình huống này.  Một số người lãnh đạo kĩ thuật có thể nghi ngờ miền trao quyền. Điều đó là thông thường cho miền khởi đầu được xác định không đầy đủ. Đôi khi người lãnh đạo kĩ thuật sẽ ra quyết định bên ngoài miền của mình hay ai đó không trong tổ có thể ra quyết định bên trong miền này. Trong cả hai trường hợp, phải thận trọng để giải thích cơ sở cho thay đổi quyết định để chắc rằng tổ và cách tiếp cận dự án không bị phá hoại.

Trao đổi dự án là việc thu thập, phát tán và có thông tin dự án đúng thời hạn. Trao đổi cung cấp móc nối cốt yếu giữa con người, và trao đổi ý tưởng và thông tin (như mệnh lệnh, thông điệp, báo cáo trạng thái, chính sách, v.v.) giữa các cá nhân cần cho việc thực hiện dự án. Mọi người tham gia vào trong dự án gửi và nhận thông tin, và họ phải hiểu cách trao đổi mà theo đó họ được tham gia sẽ ảnh hưởng tới dự án như một toàn thể. Người quản lí dự án phải làm việc để xây dựng trao đổi hiệu quả với các thành viên tổ dự án và quản lí cấp trên. Họ phải xác định nhu cầu trao đổi và thông tin của những người tham gia dự án, và cài đặt công cụ để nắm bắt thông tin, và để tạo điều kiện thuận tiện cho việc truy nhập và phân phối thông tin dự án có liên quan, theo chiều ngang cũng như theo chiều đứng bên trong tổ chức. Xác định nội dung đúng (như tóm tắt điều hành, nội dung đại cương hay chi tiết), và phương thức phân phối một mặt cho một thành viên tổ và mặt khác cho toàn tổ là điều bản chất cho thành công của dự án.

English version

Large software project

Today, most software projects are large, complex and project team usually consists of many people with different roles and responsibilities. With this structure, developers may feel uncomfortable and difficult to adjust. The first is the lack of understanding of what others are doing. For the team to be effective, all team members need to understand all the roles, responsibilities and authorities within the project’s development process. By clearly understand them, they can avoid conflict which often happen in large project. The second is the issue with teamwork and soft-skills. Effective communication, listening, encouragement, and the suppression of “individual egos” are examples of the “soft skills” that are needed for the team to be effective. Lack of these skills often leads to ineffective decision, ineffective meetings, and more personal conflicts. The third difficulty is not following the project’s defined process. Even many projects do have training on process but unless there is a clear direction and strong monitoring mechanism in place, team members may do things based on their own experiences rather than follow a process defined by the project manager.

In the past, when projects are small, maybe five to twenty people, developers have their own ways of doing works through “informal” individual process. After they are done, their works are subjected to reviews and tests until they are accepted by the customer. As long as they get their works done, project manager does not care about how they get their works done or what process they are following. In a large project, sometime hundreds of people are involved, the sequence of development changes. The process to create software must be defined and assigned as the development now involves so many people with a lot of works must be integrated. Project manager can not afford to allow people do whatever they want or follow whatever process that they like, it will be chaotic.

The team must understand the project’s defined process as their works must be integrated based on an architecture. For example, the team must agree on the certain design characteristics as guidance to individuals doing their own works. The teams and individuals iteratively refine and agree to the content as it is being created. The result is a collaboration with shared responsibilities of the product. Basically, the work sequence is reversed with the review occurring prior to the individual creation. In this type of work, a collaborative environment that enables everyone to have immediate access to the work products as they are being created is required to effectively implement large project as many works are concurring. This is why large project is difficult as it requires a lot of planning, coordination with roles and responsibilities clearly identified before the project even starts.

A project structure must be based on a precise division of team member’s roles and responsibilities to create a productive work climate; avoids costly duplication of effort; improves communication among participants; encourages autonomy on the part of participants in the execution of their responsibilities. Basically, role is a position in the project team structure. A role correspond to a set of responsibilities. Several participants can play a single role and a single participant can play several roles. This normally depends on the scope of the project. Responsibility is the activities undertaken by a participant in a specific area. It imply a decision-making power and an obligation to assume the consequences of one’s decisions. A clear assignment of roles and responsibilities is necessary to ensure that each team member in the project knows exactly what is expected of them and other team members.

For better effectiveness, each team must have specific objectives with consensus decision-making procedures. The teams must receive training several weeks before the project starts and the training must clearly explain the sequence of works, the overall architecture and monitoring mechanisms. Of course, not everybody will agree with the way the project is being organized so there will be challenge and this is where the skill of the project manager and system architect are needed to handle this kind of situation.  Some technical leaders may question the domain of its empowerment. It is normal for the initial domain to be incompletely defined. Sometimes technical leader will make a decision outside of its domain or someone not on the team may make a decision within the domain. In either case, care must be taken to explain the basis for changing the decision to make sure that the team and project approach is not undermined.

Project communication is the timely collection, dissemination and disposition of project information. Communication provides the critical links among people, and the exchange of ideas and information (i.e. instructions, messages, status reports, policies, etc.) between the individuals that are necessary for the execution of the project. Everyone involved in the project sends and receives information, and they must understand how the communications in which they are involved affect the project as a whole. Project managers must work at building effective communication with project team members and upper management. They must determine the communication and informational needs of project participants, and implement the tools to capture information, and to facilitate the access and distribution of relevant project information, horizontally as well as vertically within the organization. Determining the correct content (e.g. an executive summary, an outlined or detailed content), and mode of distribution to a single team member on the one hand and to all team members on the other hand is essential to the success of the project.