As Agile has moved from a revolutionary manifesto to a mainstream approach to product development and project management, project teams have created hybrid approaches that suit the needs of their projects and work environments. The question of whether Agile is compatible with formal project management has been asked and answered. The answer is yes, of course it is.
The first step in transitioning to a hybrid approach is to drop the capital ‘A’ in Agile. That leaves us with “agile”. This change is a symbolic one that begins to eliminate fundamentalist thinking. Then we can begin a rational and practical process to find an approach that is suitable to the situation at hand.
The right approach is neither too loose nor too tight. It is like tuning a stringed instrument. Too tight or too loose and the music is not good. We want an approach that is tuned for optimal performance. Too much control and formality wastes time, costs too much and requires unnecessary effort. Too little control and formality risks errors, unnecessary conflict, poor performance, legal ramifications and unmet expectations. It wastes time, money and effort.
The policies, procedures and practices that are followed to manage and perform a project is the project approach. There are many valid and effective approaches. No single approach is best for all projects. The project type, its environment, size and level of complexity are critical factors in determining the right project approach.
At the same time, there are basic principles that underlie all effective approaches. Among these are 1) clear values, objectives, requirements and roles and responsibilities must be mutually accepted by all stakeholders; 2) stakeholders must be identified and engaged; 2) communication must be candid, clear and regular; 3) risk, conflict, change and issues must be effectively managed; 4) take a situational approach to neither over do or under do documentation and adherence to process. How these principles are executed is the question to be addressed to craft an effective project approach.
Arguing about whether Agile is better than a more formal approach, may be interesting and entertaining, but it misses the key point. The key point is to find the right blend of agility and formality to satisfy the need to successfully complete projects and satisfy stakeholders. The right blend varies from situation to situation.
Every rational organization wants to be able to move with speed and grace; to be nimble. That is the definition of agility.
The Agile manifesto says: “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.”1
Formality is defined as being rigorous in methodically adhering to established rules or processes. It is also linked to a ceremonious adherence to rules or customs; something that is required but lacks real meaning or importance. In project management, a formal approach is one that has a prescribed process and that includes concrete written documentation – plans, contracts, artifacts, reports, etc. Clearly, we want to avoid formal processes that lack real meaning or importance. The PMOs that insist that every project develop every document identified in the methodology are heading for failure.
PMI’s PMBOK® Guide project management approach is an example used by many to exemplify formal project management.
The PMBOK® Guide is not prescriptive. It does not say one must do PM in a particular way. It allows for, in fact insists that, each project develops a specific plan that identifies how the project will be managed and performed. What the guide does say is that there are basic common project management elements (Knowledge Areas) – the integrated management of scope, time, cost, quality, human resources, communication, risk and procurement. For each of these there are a set of processes and artifacts, which together describe the knowledge area.
A parochial view of the PMBOK® Guide’s processes can, and have, led many astray. They think that the processes dictate a highly formal approach that must be taken to successfully manage a project.
A hybrid approach includes all the principles and elements identified in both agile and formal approaches in the right measure and prioritizes the critical ones.
Individuals need processes and tools. Documentation is as much a part of the product as the working software. The manifesto does not mean to trade contract negotiation away for customer collaboration. Contract negotiation, if done well, can promote more effective collaboration. Similarly, the manifesto does not imply that one should not plan. In fact one needs to plan in order to effectively respond to change.
PMBOK® Guide does not dictate a strict adherence to rules. It does not promote the development of documentation that is not useful or appropriate. It is a guide.
Take for example requirements definition. How much and to what level of detail requirements must be defined and in what format and media will vary from project to project. To maintain that requirements can be completely informal and undocumented is foolish. Such an approach will in all likelihood lead to conflicts and disappointment. Insisting upon highly formal documentation of every detail in every report or product feature with sign-offs by multiple levels of stakeholders in a project in which requirements are evolving is equally as foolish.
What then is the right approach? It is an approach which satisfies business, client and project team member needs.
There is no cookbook, there are principles and guidelines which can be combined in the right measures to create a balanced approach that when applied fits the needs of the situation at hand. This makes it the responsibility of organizations and project managers to create a hybrid approach, or multiple approaches, to suit the needs of their projects.
Reference: George Pitagorsky, PMP