Staying Relevant in Project Management
As they say, “change is the only constant.” And, even in project management – where we strive to bring order to chaos, plan for the expected and unexpected, mitigate risks and study lessons learned so that we are not doomed to repeat them – we, too, are faced with the inevitable. Our foundational methodology is evolving in a direction we cannot ignore and unless we become agile, we will become stale, ineffective and irrelevant.
Agile is not just for software developers, either. Defined as a method to “determine requirements for…development projects in a highly flexible and interactive manner,” I cannot recall a time nor project when I did not have to be agile-esque. What was once widely accepted as change management, i.e. managing and documenting exceptions or changes to the rule, has become the norm and a ‘quote-unquote “new” way of managing projects’.
Not unlike many of my project management peers, I had been struggling with managing constant and necessary changes to project requirements which impacted resources, schedule and budgets, while still striving to deliver the best possible product amidst these changes. And for me, a black and white project manager – the struggle was less about the impact these changes were having on the success of the project and more about my inability to reconcile delivering a project that had experienced so many curveballs. Kudos to me (and all the other PMs) for successfully delivering robust products on time nonetheless, even when our methods were contrary to the traditional and waterfall techniques we had learned so well.
So, becoming a little more agile certainly cannot hurt; the language of agility will become more and more ubiquitous as organizations catch on to its time and resource-saving capabilities and communication-rich philosophy. But, the standards still maintain their merit, at least until Agile is time tested against larger and longer-term projects, for which its application receives the greatest criticism.
So, whether you’re in the Agile, Traditional or Waterfall camp – the truth is, being knowledgeable about all of the tools and methodologies we, as PMs, have to utilize and more importantly – having the intuition to know WHEN it’s most important to use each will dictate how successful our projects are.
Wishing You Success,
APPENDIX of TERMS*
- Traditional Project Management: The primary challenge of traditional project management is to achieve all of the project goals and objectives while honoring the preconceived constraints.The primary constraints are scope, time, quality and budget. The secondary —and more ambitious— challenge is to optimize the allocation of necessary inputs and integrate them to meet pre-defined objectives.A traditional phased approach identifies a sequence of steps to be completed. In the “traditional approach”, five developmental components of a project can be distinguished:
Initiation, Planning, Execution, Control, and Closing (IPECC).
- Waterfall Project Management: The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance.
- Agile Project Management: Agile management or agile project management is an iterative method of determining requirements for engineering and information technology development projects in a highly flexible and interactive manner, for example agile software development. It requires empowered individuals from the relevant business, with supplier and customer input.There are also links to lean techniques, Kanban and Six Sigma. Agile techniques are best used in small-scale projects or on elements of a wider program of work, or on projects that are too complex for the customer to understand and specify before testing prototypes
* Courtesy, Wikipedia.