Điều không may, giải pháp điển hình là thay thế người quản lí dự án này bằng người quản lí khác và hi vọng rằng mọi sự sẽ tốt hơn. Cách nhìn chung là ở chỗ người quản lí chịu trách nhiệm cho mọi thứ. Nếu người quản lí mới được cần tới, công ti sẽ đặt họ vào chỗ đó nhưng nhiều dự án vẫn hỏng gợi ý rằng KHÔNG người quản lí nào biết phải làm gì hay nguyên nhân có thể là cái gì đó khác.
Cho dù người phát triển phần mềm và công việc của họ là khác với công nhân lao động và công việc chế tạo của họ, phương pháp quản lí truyền thống ngày nay vẫn dựa trên các nguyên lí từ công việc trong ngành xây dựng được Frederick Taylor phát minh thế kỉ thứ 19. Phương pháp của Taylor đã được thiết kế cho các công nhân không có giáo dục, phần lớn là những người lao động xây dựng xưởng máy, nhà cửa hay làm việc trong dây chuyền lắp ráp chế tạo. Phương pháp này tương đối đơn giản nơi người quản lí ra lệnh và công nhân tuân theo mệnh lệnh làm các nhiệm vụ thủ công của họ. Loại công việc lao động này và công việc phần mềm ngày nay là rất khác nhau, nhưng hầu hết các đại học vẫn dạy các nguyên tắc chỉ huy và kiểm soát của Taylor. Đó là lí do tại sao những người quản lí không có hiệu quả trong kiểm soát chi phí, lịch biểu, chất lượng dự án và dự án bị thất bại.
Vấn đề là ở chỗ với đào tạo hiện tại, người quản lí phần mềm KHÔNG biết người phát triển đang làm gì và làm sao thu được trạng thái dự án cho nên họ nói chung bị trách vì những lỗi lầm khi vấn đề thực là với phương pháp quản lí hay đào tạo người quản lí chứ KHÔNG phải là người quản lí. Câu trả lời thực KHÔNG phải là thay thế người quản lí, mà THAY phương pháp quản lí. Tuy nhiên, người quản lí dự án không biết thay đổi cái gì và ngần ngại thay đổi phương pháp mới KHÔNG được dạy trong trường.
Vấn đề chính với phương pháp quản lí hiện thời là ở chỗ những người phát triển và người quản lí có các cách nhìn khác nhau về thành công. Nghiên cứu của Carnegie Mellon thấy rằng những người phát triển coi dự án là thành công nếu công việc có tính thách thức kĩ thuật để họ tiếp tục “hoàn thiện nó” dù dự án có đáp ứng các mục tiêu chi phí hay lịch biểu không. Người quản lí coi dự án là thành công nếu họ đáp ứng các mục đích chi phí và lịch biểu mà không xem xét tới bản chất công việc kĩ thuật. Sự khác biệt này trong cách nhìn đã có tác động sâu sắc lên việc quản lí dự án. Chẳng hạn, khi người quản lí dự án yêu cầu các thành viên tổ để mắt tới nhiệm vụ hay cột mốc. Các thành viên tổ bao giờ cũng cho câu trả lời mơ hồ như “Tôi làm gần xong nhưng chưa xong” hay “Việc đã gần xong rồi, hoàn thành quãng 90%.” Khi công nhân tri thức biết điều đã xảy ra, họ thà tập trung vào “hoàn thiện mã” hay “cải tiến thiết kế” hơn là giữ lịch biểu bởi vì đó KHÔNG phải là vấn đề của họ. Đến lúc người quản lí dự án thấy ra rằng dự án bị chậm thì đã khó sửa rồi. Lịch biểu trượt điển hình xảy ra trước rồi đến chi phí quá mức và cuối cùng là vấn đề chất lượng vì người phát triển xô vào sửa lỗi và đưa thêm vào nhiều lỗi hơn. Cuối cùng, người quản lí cấp cao không còn chọn lựa nào ngoài việc cắt bỏ dự án hay tìm ai đó để thay thế người quản lí dự án. Trong nghiên cứu của tôi ở Carnegie Mellon, tôi đã phỏng vấn hàng trăm người quản lí dự án và họ tất cả đều bảo tôi rằng họ KHÔNG biết phải làm gì ngoài tập trung vào sửa chữa vấn đề nhiều nhất có thể được rồi đợi ai đó khác cắt bỏ dự án và đổ lỗi cho khó khăn kĩ thuật chứ không về bản thân họ.
Dự án phần mềm khó quản lí nhưng lí do chẳng liên quan gì tới công nghệ cả. Đó thực tế là công việc tri thức có bao hàm công nhân tri thức và quản lí công nhân tri thức, bạn sẽ cần người quản lí tri thức và một kiểu phương pháp quản lí khác. Trong xem xét cách quản lí công việc tri thức, vài năm trước, tác giả Peter Drucker đã kết luận rằng người quản lí không thể quản lí thực sự công việc tri thức được, người công nhân tri thức phải quản lí bản thân họ. Để làm điều đó, công nhân tri thức phải được đào tạo trong các vai trò, trách nhiệm và thẩm quyền đặc biệt và họ phải được đảm nhiệm để tạo ra kế hoạch riêng của họ, thương lượng cam kết riêng của họ, và đáp ứng những cam kết này bằng sản phẩm chất lượng. Công việc của người quản lí KHÔNG còn là chỉ huy và kiểm soát tổ làm việc tri thức mà là LÃNH ĐẠO, ĐỘNG VIÊN, HỖ TRỢ và HUẤN LUYỆN họ.
Trong thực hành công nghiệp hiện thời, tổ phần mềm bao giờ cũng làm việc theo cách này. Thay vì vật lộn để đáp ứng lịch biểu không hợp lí, họ bây giờ có thể thương lượng lịch biểu riêng của mình với cấp quản lí. Tổ sẽ chịu trách nhiệm về công việc của họ, họ biết tình trạng dự án, và họ thu thập dữ liệu để bảo vệ ước lượng của mình. Khi họ thấy có vấn đề, họ giải quyết chúng trong các cuộc họp tổ giữa các thành viên tổ và nếu họ không thể giải quyết được thì họ sẽ nhờ sự giúp đỡ của cấp quản lí. Ngày nay, nhiều công ti đã dùng nguyên tắc này trong dự án hệ thông tin của họ và kết quả rất có ý nghĩa. Không may là nhiều đại học không chấp thuận điều đó. Lí do đơn giản, nhiều giáo sư KHÔNG có kinh nghiệm làm việc thực tế để dạy loại kĩ thuật này.
Chìa khoá của kĩ thuật này là các vai trò, trách nhiệm và thẩm quyền được xác định rõ lúc bắt đầu dự án. Cấu trúc dự án phải được thiết lập tương ứng với nơi có Ban quyết định, bao gồm vài người quản lí cấp cao để ra quyết định về dự án kể cả ngân sách, lịch biểu toàn thể và bất kì quyết định nào ảnh hưởng tới kết quả của dự án, cũng như cung cấp tài nguyên cần thiết để tiến hành dự án. Vai trò của người quản lí dự án là hướng dẫn, huấn luyện, khuyến khích và động viên tổ đạt tới mục tiêu xác định: hoàn thành thành công dự án. Người đó chịu trách nhiệm về lập kế hoạch tổng thể, tổ chức, thực hiện dự án bằng cách làm việc trong CỘNG TÁC với các thành viên tổ để tạo ra môi trường làm việc năng suất để đảm bảo rằng dự án được chuyển giao đúng thời gian, trong ngân sách, và với chất lượng được yêu cầu. Người quản lí doanh nghiệp đại diện cho khách hàng và nhóm người dùng và chịu trách nhiệm xác định yêu cầu dự án và mọi thay đổi cần thiết. Trong cộng tác với người quản lí dự án, người quản lí doanh nghiệp tham gia vào lập kế hoạch và giám sát các nhiệm vụ khác nhau cần sự tham gia của người đó, như hiểu và tạo ra yêu cầu, cũng như kiểm nghiệm và chấp thuận sản phẩm của tổ dự án. Người kiến trúc hệ thống là một chuyên gia thiết kế và thiết lập kiến trúc cho dự án. Người đó chịu trách nhiệm duy trì phạm vi của dự án tuân thủ với các yêu cầu đã được thiết lập. Tổ dự án bao gồm người quản lí dự án, người quản lí doanh nghiệp, kiến trúc sư hệ thống và mọi thành viên được phân công cho dự án. Tổ dự án chịu trách nhiệm về kết quả của dự án, tức là sản phẩm hay dịch vụ được chuyển giao. Thành viên tổ là một cá nhân tham gia vào trong dự án và là một phần của tổ bên trong cấu trúc của dự án. Thành viên tổ có nhiệm vụ hay vai trò được phân công cho người đó và đảm nhiệm hoàn thành việc phân công đó. Hơn nữa, các thành viên tổ phải đo, theo dõi, và báo cáo về việc làm của họ. Trong kiểu cấu trúc tổ chức này, toàn thể tổ dự án có thể tham gia tích cực để làm cho dự án thành công.
Khi tổ tri thức có quản lí, đào tạo và hỗ trợ thích hợp, họ có thể làm việc tốt và nhất quán đáp ứng các cam kết chi phí và lịch biểu của họ bằng sản phẩm chất lượng cao. Theo Peter Drucker các nguyên tắc quản lí cho công việc tri thức là khác với các nguyên tắc cho kĩ nghệ truyền thống. Các nguyên tắc này là:
1. Tin cậy công nhân tri thức. Cấp quản lí phải tin cậy vào công nhân tri thức và tổ tự quản lí họ.
2. Đào tạo tổ đáng tin cậy. Tổ làm việc tri thức phải được đào tạo để cho họ sẵn lòng và có khả năng tự quản.
3. Dựa vào sự kiện và dữ liệu. Hệ thống quản lí phải dựa vào sự kiện và dữ liệu để ra quyết định thay vì quyền lực và địa vị.
4. Chất lượng quản lí. Chất lượng phải là ưu tiên cao nhất của tổ chức.
Khi công nhân tri thức đã được đào tạo và biết cách tự quản mình, họ có kế hoạch chi tiết cho công việc của mình và biết trạng thái của mình một cách chính xác. Họ cũng cảm thấy có trách nhiệm quản lí các vấn đề riêng của mình và khi cần giúp đỡ, họ có thể yêu cầu tổ hay người quản lí của họ. Tất nhiên, không phương pháp nào có thể xoá bỏ được vấn đề nhưng với kiểm điểm đủ, những hành động phòng ngừa nào đó có thể được thực hiện sớm cho nên vấn đề có thể được tránh hay được giải quyết nhanh chóng. Nguyên tắc then chốt của phương pháp này là chia công việc dự án thành nhiều nhiệm vụ nhỏ cho dễ quản lí. Thay vì dựa vào các cột mốc mà có thể cách nhau vài tháng, dự án nên được chia thành các bản đưa ra tăng dần nhỏ hơn, mỗi bản đưa ra với chuyển giao nào đó và trong thời hạn ngắn, có thể một tuần hay hai tuần. Theo phương pháp này, các nhiệm vụ chi tiết, cách đo chính xác, và quyền làm chủ là cốt yếu để cho công nhân tri thức có thể tự quản mình tương ứng theo vai trò, trách nhiệm và thẩm quyền của họ.
Để bắt đầu, chúng ta cần đào tạo người phát triển cách tự quản bản thân mình dựa trên các nguyên tắc và phương pháp mới. Nhiều vấn đề có thể được tránh nếu người phát triển biết phải làm gì, làm thế nào và khi nào làm nó. Với các dự án phần mềm, qui trình được xác định tốt là điều bản chất. Quản lí dự án phải được chia thành vấn đề chi tiết, và mọi bước đều phải được thực hiện tương ứng và đúng đắn. Như tôi làm việc trong doanh nghiệp hàng không, tôi biết rằng trước mỗi chuyến bay, phi công bao giờ cũng kiểm tra chuẩn bị bay bằng việc tuân theo danh sách kiểm chi tiết. Điều đó có thể được áp dụng cho dự án phần mềm nơi những người phát triển phải xây dựng danh sách kiểm riêng của họ và tuân theo chúng tương ứng để cho họ biết mọi bước họ phải làm. Khi họ làm điều đó nhiều lần, họ có thể tiếp tục cải tiến danh sách kiểm riêng của mình. Loại tự kiểm này thực tế là điều công nhân tri thức biết cách tự quản mình và đảm bảo rằng mọi bước đều được thực hiện đúng.
Hơn bao giờ hết, tôi mạnh mẽ tin rằng chúng ta cần cung cấp loại phương pháp này trong mọi phát triển hệ thông tin và phần mềm. Thất bại của các dự án phát triển tốn nhiều thời gian và tiền bạc, nó cũng tạo ra vấn đề chất lượng lớn cho ngành công nghiệp. Trong thế giới cạnh tranh cao này của toàn cầu hoá, không nước nào có thể đảm đương được với kiểu thất bại dự án này. Bằng việc làm chậm đào tạo hay từ chối chấp nhận các thực hành tốt nhất trong đào tạo đại học sẽ làm hại về mặt kĩ thuật cho các sinh viên có năng lực và làm hỏng việc phát triển công nhân tri thức, người là nhân tố then chốt trong việc tăng trưởng nền kinh tế và thịnh vượng quốc gia.
There are several studies indicated that most software projects failed NOT because of technology issues but management issue. Unfortunately, the typical solution is to replace the project manager with another manager and hope that things would be better. The common view is that the manager is responsible for everything. If new manager is needed, company would put them in place but many projects keep failing anyway which suggests that either managers do NOT know what to do or the cause may be something else.
Even though software developers and their works are different from labor workers and their manufacturing works, today’s traditional management methods are still based on the principles from construction works invented by Frederick Taylor in the 19th century. Taylor’s methods were designed for uneducated workers, mostly laborers who build factories, buildings or work in manufacturing assembly lines. The method is relatively simple where managers give orders and workers follow orders on their manual tasks. This kind of labor work and today’s software work are very different, but most universities are still teaching Taylor’s command and control principles. That is why many managers are not effective in controlling project costs, schedules, quality and projects do fail.
The problem is that with current training, software managers do NOT know what developers are doing and how to obtain project status so they are generally blamed for the failures when the real problem is with the management method or the training of manager and NOT the managers. The real answer is NOT to replace managers, but to CHANGE the management methods. However, project managers do not know what to change and are reluctant to change to a new management method that is NOT taught in school.
The major problems with current management method is that developers and managers have different views of success. Carnegie Mellon’s study found that developers considered a project was success if the work was technically challenging so they continue to “perfect it” whether or not the project met its cost or schedule objectives. Managers viewed projects as successful if they met their cost and schedule goals without consider for the nature of the technical work. This difference in views has a profound effect on project management. For example, when the project manager ask team members regarding a task or milestone. The team members always give vague answers such as “I’m almost done but not yet” or “It is almost done, about 90% completed”. While the knowledge workers do know what happened, they rather concentrate on “Perfecting their code” or “Improving their Design” rather than the schedule because it is NOT their problems. By the time project manager find out that the project is late then it is difficult to fix. Schedule slippage is typically happen first then costs overrun and eventually quality issues as developers rushing to correct defects and insert more. Finally, senior managers have no choice but cancel the project or finding someone to replace the project manager. In my research at Carnegie Mellon, I have interviewed hundreds of project managers and they all told me that they do NOT know what to do but concentrate on fixing problems as much as possible then wait for someone else to cancel the project and blame on technical difficulty rather than themselves.
Software project is hard to manage but the reason has nothing to do with the technology. It is actually knowledge works that involve knowledge workers and to manage knowledge workers, you will need knowledge managers and different kind of management methods. In considering how to manage knowledge work, several years ago, the author Peter Drucker already concluded that managers cannot truly manage knowledge work, the knowledge workers must manage themselves. To do that, the knowledge workers must be trained in special roles, responsibilities and authorities and they must be held accountable for creating their own plans, negotiating their own commitments, and meeting these commitments with quality products. The manager’s job is NO LONGER command and control the knowledge-working teams BUT to LEAD, MOTIVATE, SUPPORT, and COACH them.
In actual industry practices, software teams always like to work in this way. Instead of struggled to meet an unreasonable schedule, they now can negotiate their own schedule with management. The teams will be responsible for their work, they know the project status, and they collect data to defend their estimates. When they see problems, they resolve them during team meetings among team members and if they can not resolve then they will get management’s help. Today, many companies already used this principles in their Information Systems projects and the results were significant. Unfortunately many universities failed to adopt it. The simple reason, many professors do NOT have actual work experiences to teach this kind of technique.
The key of this technique is the clearly defined roles, responsibilities, and authorities at the beginning of the project. The project structure must be set up accordingly where there is a Decision Board, consists of several senior managers to make decision for the project including budgets, overall schedule and any decisions affecting the project’s outcome, as well as to provide the necessary resources to carry out the project. The project managers’ role is to guide, coach, motivate and mobilize the team to attain a specific objective: the successful completion of the project. He is responsible for the overall planning, organization, execution of the project by working in COLLABORATION with team members to create a productive work environment to ensure that the project is delivered on time, within budget, and with the quality required. The business manager represents the customers and user group and responsible for defining the project requirements and all the changes needed. In collaboration with the project manager, the business manager participates in the planning and monitoring of different tasks involving his participation, such as understanding and creating requirements, as well as validating and approving the products of the project team. The system architect is a specialist who designs and establishes the architecture for the project. He is responsible for maintaining the scope of the project in compliance with the established requirements. The project team is consisted of the project manager, the business manager, the system architect and all the members assigned to the projects. The project team is responsible for the outcome of the project, i.e. the product or service to be delivered. A team member is an individual involved in the project and who is part of a team within the project’s structure. A team member has a task or a role assigned to him and is accountable for the completion of his assignment. Furthermore, team members must measure, track, and report on their work. In this kind of organization structure, the entire project team can participate actively to make the project successful.
When knowledge teams have appropriate management, training, and support, they can work well and consistently meet their cost and schedule commitments with high-quality products. According to Peter Drucker management principles for knowledge work are different from those for traditional engineering. These principles are:
1. Trust the knowledge workers. Management must trust the knowledge workers and teams to manage themselves.
2. Train the trustworthy teams. The knowledge-working teams must be trained so that they are willing and able to manage themselves.
3. Rely on facts and data. The management system must rely on facts and data to make decisions rather than power and status.
4. Manage quality. Quality must be the organization’s highest priority.
When knowledge workers have been trained and know how to manage themselves, they have detailed plans for their works and know their status precisely. They also feel responsible for managing their own problems and when need help, they can ask their team or their managers. Of course, no method can eliminate problems but with sufficient reviews, certain preventive actions can be done early so problems can be avoided or resolved quickly. The key principle of this method is to divide the project works into many smaller tasks for easily managed. Instead of relying on milestones that may be several months, the project should be broken down into smaller incremental releases, each with certain deliveries and in short duration, maybe a week or two. In this method, detailed tasks, precise measures, and ownership are critical so knowledge workers can manage themselves according to their roles, responsibilities and authorities.
To start, we need to train developers how to manage themselves based on the new principles and method. Many of the problems can be avoided if developers know what to do, how and when to do it. For software projects, an well defined process is essential. Project management must be broken down into matter of detail, and every step must be implemented accordingly and correctly. As I am working in aerospace business, I know that before each flight, pilots always do their preflight checks by following a detailed checklist. It can be applied to software project where developers should build their own checklists and follow them accordingly so they know every step that they must do. As they do it many times, they can continue to improve their own checklists. This kind of Self-check is actually what knowledge workers know how to manage themselves and ensure that every step is done correctly.
More than ever, I strongly believe that we need to provide this kind of method in all software and information systems developments. The failure of development projects costs a lot of time and money, it also creates significant quality problems to the industry. In this highly competitive world of globalization, no country can afford to continue with this kind of project failures. By delaying training or refuse to adopt industry’s best practices in university training will hurt technically competent students and fail to develop knowledge workers, who are the key factor in growing the economy and national prosperity.
