With many project management methods and a huge percentage of failures in the implementation of the project, the key to its success is the choice of an appropriately adapted method to the specifics of the project. To make the right choice, the criteria that you can use are helpful. The basic ones include:
Criterion 1 - Knowledge of the solution
Each of the agile and classic methodologies assumes that the project goal is well defined.
Traditional methods should, however, be used in projects with known methods to solve the problem.
If the method is unknown, use agile methodologies. Translating more graphically, knowledge of the solution, i.e. creating another version of the same system, implementing another online store, differing only in products, computerization of the office with a well-known number of systems and positions is a premise for using traditional methodologies. The start-up portal, on the other hand, is an ideal example of using agile methodologies due to the innovation and uniqueness of the solution.
Criterion 2 - Project size
It is recommended to use classic methodologies for large and very large projects. In this case, it is difficult to imagine that multi-million projects would be implemented without a known goal and solution. Agile methodologies are better suited to smaller projects. However, nothing prevents a project that is managed in a classic way and has modules created agile. This is called HYBRID MODEL. In this case, the entire project is divided into subprojects, each of which can be managed using a different methodology.
Criterion 3 - Stability of requirements
Traditional methodologies require stable design requirements since no changes are allowed during the works. Therefore, if the requirements are not specified, or if we know from experience that the customer has a tendency to modify them, then the only way out is to use agile methodologies.
Criterion 4 - Customer availability
Theoretically, in the case of traditional methodologies, the client may be available to the project team only during acceptance and acceptance tests. In practice, however, customer participation is required at least at the stage of analyzing requirements (see the statement "the point below will be detailed at the stage of analysis" often found in the Specification of Essential Terms of the Order).
While classic methodologies do not assume the need to contact the client throughout the project's "life", in agile methodologies the client is an integral part of the project team and constantly supports developers. Therefore, its availability is a key factor in choosing the methodology.
Criterion 5 - Tolerance for changes in budget and scope
Projects implemented in classical methodologies always have a strictly defined scope and cost - they are carried out as a fix-price. Cascading (traditional) methodologies generally assume the implementation of a previously developed project plan and are unfavorable to major changes that turn the project upside down.
Each major change entails an increase in costs and an extension of project implementation.
However, such methodologies will be perfect for "stable" projects, where no changes in requirements or used technologies are expected during the project duration.
They will also work well in projects where a long preparatory period is needed before implementation works begin.
In the case of agile methodologies, due to changing requirements and priorities, it is difficult to estimate the total cost of the project. Therefore, if the client's budget is fixed and cannot be increased, functionalities with the highest priorities are delivered at the end of the project. In other words, the scope of work may be changed/reduced. Customer awareness in this regard is key, and a lack of understanding of this issue always causes problems.
Agile methodologies accept the occurrence of variability, so they are better suited to the implementation of projects that may evolve during their lifetime. They do not focus on detailed identification of requirements and planning for the entire project, but for a particular stage or tasks. So they will work better in projects whose result is not fully known or only the business need that the solution is to meet, but the project effect itself is not specified.
Criterion 6 - Delivery time
The main assumption of classic methodologies is to provide the client with a ready solution only at the end of the project. In the case of agile methodologies, a full, working solution is the end result of each iteration. Because of iterations last from 1-4 weeks, it is possible to quickly implement new functionalities in production.
Criterion 7 - Team
The competence of the project team is one of the most important factors in the choice of methodology. In a perfect world, each team consists of competent and experienced people, but in the era of constant resource problems, this is not so obvious.
If you choose a methodology, knowing that we have a weaker team at your disposal, choose a classical methodology.
In agile methodologies, the team is called "Self-organizing body", must be experienced, know each other for a long time, have the ability to estimate tasks, have good communication skills.
In the case of classical methodologies, the team's deficiencies can be offset by the supervising team of managers. They can possibly make changes in the assignment of tasks, in the composition of the team, which in turn should not take place in teams working on projects implemented using agile methodologies.
Criterion 8 - Integration with external systems
This point may seem incomprehensible at first, as most systems now integrate with other systems. However, for large projects where many applications are created simultaneously and which need to communicate with each other, e.g. using a data bus, it is better to use classical methodology. Thanks to it, we will always have defined communication methods and the team will be able to perform appropriate mock-ups.
In the case of agile methodologies, there is a very high risk of blocking the team's work by deficiencies on the side of other modules. It is worth mentioning here that often modules/applications are created by various companies, which does not make it easier to synchronize work.
Criterion 9 - Customer preferences
Customer knowledge of methodologies is the key to project success. Implementation of the project in a methodology unknown to the client will cause chaos and irritation. Therefore, due to the difficulties in changing the client's awareness (training is not always possible, the project team is often a dozen or so people), it is worth adapting to his preferences. We often have no choice - the methodology is imposed directly on the customer's requirements.
Criterion 10-Project financing schedule
For projects where the cost distribution and financing method is exponential (slowly increasing costs at the beginning of the project, further exponentially with the commissioning of individual parts of the project), an agile approach is recommended.
However, for projects with a logarithmic distribution of costs to cover them (high at the beginning of the project, stabilizing in subsequent stages), a traditional approach is recommended.
Criterion 11- Budget type
Even distribution of the budget over time can be a premise for using traditional (also agile) methodologies. However, high uncertainty and unevenly distributed use of the budget may be a premise for using agile methods.
Criterion 12- Formal requirements
Compliance with detailed and very formal requirements in relation to documentation (licenses, certificates, permits, patents, contracts between contractors) indicates the use of cascade methodologies. In turn, agile methodologies will work well in projects that emphasize the quality of the solution provided and the possibility of its further development instead of detailed documentation.
Criterion 13- Risk approach
Agile project management methodologies can be successfully used in low-risk projects. However, in the case of high-risk levels, it will be necessary to use 'heavier' cascade methodologies that place greater emphasis on risk management in the project and propose a number of tools to manage it.
Criterion 14- Organizational structure necessary to implement the project
Traditional methodologies will favor enterprises with a very hierarchical structure, where strictly specialized units are required. In the case of cooperative structures, it may be effective to use one of the agile methodologies.
Criterion 15- Psychological factors
You can't miss this point either!
Experience in project implementation with a given methodology is an extremely important aspect of the success of the entire undertaking. Sometimes, despite the fact that the project better matches the characteristics of another methodology, it is unprofitable and risky to introduce a new one, sometimes, in turn, it is more profitable to try a new approach, instead of stubbornly sticking to the old solution, which only generates additional conflicts and uncertainty. Also, depending on the degree of trust of management in the project team, a different approach will work better - agile with greater decision-making of the project team, traditional for the more important role of highly qualified specialists.
Criterion 16-Nature of schedule arrangements
The rigid time assumptions imposed in the schedule in relation to the planned tasks speak for the advantage of using classic methodologies. Approximate or relative deadlines suggest using agile methods.
Criterion 17- Number and level of documentation required and level of software quality
Compliance with complex requirements related to formal documentation, licenses and certification standards indicates the need for a classic project management methodology.
However, the project, in which the emphasis is on the quality of the software and the possibilities of its development, is in line with the philosophy of agile methodologies.
Criterion 18-Sector / industry of the project implementation
Industries that have a small number of raw materials and input at the entrance, and finished products at the exit are better suited for classic system design.
Criterion 19-Type of a system for which the project is implemented
Expert or knowledge-based systems often require a lot of knowledge about the implemented issue. If these systems are designed to be self-learning, it is recommended to use modern methodologies, otherwise - for systems based on established practices - classical methodologies
As mentioned earlier, a thorough analysis of the project and matching the appropriate methodology to it is crucial for its successful implementation.
It should be remembered that each of the methodologies has its own requirements, which in effect, apart from ensuring the successful implementation of the project, are associated with the costs of their functioning. The choice must, therefore, be carefully thought out and plugged into the company's budget.
Some other Project Management Methodology Suggestions?
The methodology focuses on methods of performing tasks, especially on management methods. An example is the Prince2 project management methodology. The methodology, unlike the methodology, answers the question "How to do it", while the methodology "What to do".
What methodologies, frameworks or techniques can we use in running the project? In the case of project management ( Project Management ), we can use the most popular, i.e. Prince2, PMBOK (PMI) or Scrum. In the case of Project Portfolio Management, we can use P3O (Portfolio, Program and Project Offices) or PMO (Project Management Office).
Let's start with Prince2. Prince2 is an excellent management methodology at the strategic level, e.g. in carrying out projects for government administration or large construction projects. This methodology puts a strong emphasis on management processes such as risk management, quality management, product configuration, and product planning. Prince2 defines 8 processes:
• Strategic project management (Directing a project). • Planning. • Project start-up / Starting up a project • Initiating a project • Controlling a stage • Managing product delivery • Managing stage boundaries • Closing a project
Due to the fact that Prince2 focuses on the strategic level, it should be used with other methodologies or operational processes, e.g. in the software development stage, e.g. with Scrum or with the use of critical path analysis.
PMBOK (A Guide to the Project Management Body of Knowledge) is a collection of best practices used together with other methodologies or frameworks. It has a wider scope than Prince2 and extends project management, including for operational areas. PMBOK describes best practices in 9 areas:
• Project Integration Management • Project Scope Management • Project Time Management • Project Cost Management • Project Quality Management • Resource Management Project Human Resource Management • Project Communications Management • Project Risk Management • Project Procurement Management
The next methods that are worth applying in practice are the so-called agile methodologies. These methods or frameworks are already used directly in the software development process. They are ideal at this stage and therefore can be used together with "higher-order" methodologies, for example with Princ2 or the techniques described in PMBOK. Scrum is one of the most popular agile methodologies. It has been described in more detail in chapter 1.6. So what methodology is best to use?
The answer depends on our knowledge, project organization maturity, and type of project. However, it is worth considering the use of Prince2 elements, PMBOK techniques in the strategic area (project groups, reporting, budgeting, quality control, risk management, etc.) and in the operational area on the application of Scrum. The combination of techniques from these methodologies gives us an ideal project management process and software development tailored to the project and organization. It is worth experimenting and using techniques best suited to our organization and type of project.
コメント