Companies that fail to implement a project management methodology in the company adopt agile.
Have you tried to introduce a project management methodology in the company, but the result was catastrophic?
Have you heard that with the agile methodology it is possible to have a shorter time to market for your software project and do you believe it?
Have your projects that you tried to manage with a traditional PM methodology such as PMP or Prince2 ended up late and over budget?
… And you are now thinking of adopting agile.
I would like to clarify one point immediately: Agile does not mean cheaper. Agile doesn't mean faster. Agile doesn't mean better quality.
Agile is based on 3 assumptions:
- The tasks to be done and the features to be developed they can change during the project without a control system o need for approval by the project sponsor and without a change management system.
- There is no project manager responsible for the project in its entirety but only of the facilitators or coordinators who together with the client decide what to develop at each sprint.
- There project documentation it must be reduced to a minimum.
Problem number 1: development costs
First of all implementation costs of a project in agile mode they are not controllable by definition: first because there is no project manager, nor one project control function. While in the SME-type project management methodology the Project control activity is present and can be in charge of the Project Manager or a dedicated figure depending on the size of the project.
Problem number 2: delivery times
Since the specifications of a product can vary over time even from sprint to sprint, generating every two weeks, the delivery times of a product are potentially infinite. It is up to the good sense of the team and the Product owner not to change their minds too often or to try to keep the helm straight in order to go live with something. In the PMI but also Prince 2 methodology, changes in specifications or "scope" must be requested and approved by the project control team which can be a steering committee or the project sponsor.
Agile problem 3: quality (or project scope)
Since product requirements may vary over time, the final product does not necessarily reflect the customer's initial request. Agile assumes that the customer is an integral part of the project and contributes to the project by participating in stand-up meetings and deciding on priorities and directly approving changes. But in reality the customer is either not present or not represented at an adequate level, I mean, in the stand up meetings there could be a customer representative who does not have adequate decision-making power or experience. Sound familiar?
The quality of the product will not be better by applying the agile methodology because it does not provide for the definition of specifications against which to measure the quality of the product. In other words, less project documentation = less chance to verify that the product meets quality criteria because project and product specifications are missing. For example a BRD.
Agile problem 4: responsibility
In Agile, the responsibility lies with the team, which is made up of developers and a business figure. When the project is overdue or over budget, whose responsibility is it? It is not a rhetorical question. In a RACI matrix the number one rule is that only one person is Accountable, there will be a reason, right?
Welcome changing requirements
Agile Manifesto https://agilemanifesto.org/principles.html
But yes! … We also change the requirements every day, so much the customer pays.
Time to market
The time to market is not controllable, the possibility of changing direction of the project continuously can prevent the product from being put into production as the reasons for being of the same are changed.
Complex projects with agile
Agile then becomes particularly ineffective when it comes to implementing a complex project such as re-platforming an ecommerce site. Imagine having to migrate an ecommerce site from one platform and another let's say from Magento to Salesforce.
But we also think about the construction of a ship or a bridge, agile argues that you can develop a product without knowing the details before developing it, certainly this is not possible with a physical product, but it is not possible even with a complex software product. or a software product that has to comply with legal requirements such as banking software. Then for heaven's sake everything is possible, but I will hardly be able to think that it is possible to bring into production a software that must comply with banking regulations based on a development team that decides which features to develop and how.
Therefore, if we begin to exclude agile from the development of physical products and from software products defined by specific requirements, we could say that the use of agile is relegated to a narrow scope of applicability.
Project management in the company
For this reason, any company that wants to adopt a project management methodology that is nothing more than a team work approach to make a team of developers work together with a business figure (product manager), it would be advisable to learn how to manage projects with a structured methodology as PMI or Prince2