What is Agile Project Management Methodology?
There is lots of talk about an emerging approach to project management called “Agile Project Management Methodology.” Understandably, some may confuse this with managing an AGILE software development effort as part of an organization’s SDLC (Systems Development LifeCycle). All caps will be used to identify the software development methodology). Recently, PMI (Project Management Institute) began offering a “PMI-ACP Certification” (Agile Certified Practitioner). Project Methodology Main Page.
I talked with several practicing senior-level technology, business, and various industry project managers regarding their understanding of “Agile Project Management Methodology.” Each of these experienced managers had a different interpretation of what this might mean but none had actually implemented this specific approach within their firms. However, one organization was in the early stage of adopting an Agile Methodology Playbook.
The consensus was that Agile Project Management Methodology grew from the desire to produce results (deliverables) faster and reduce bureaucracy and burdensome “administrivia.” The respondents also believed that if a project was primarily a business process reengineering effort (i.e., how do we eliminate duplicate work efforts within an operations team?), it probably would not be using Agile Project Management Methodology. Time will tell if this proves to be correct.
A quick overview of AGILE software development is in order here. It is an iterative application development effort where requirements and solutions evolve through collaboration among developers, business owners, stakeholders, project sponsors, and end users (clients). This methodology was developed almost fifteen years ago as an alternative to the heavyweight, document-driven software development processes such as waterfall (application development progress flows from one stage to another, incorporating feedback). Within AGILE, a well-known software methodology is Scrum. It identifies “sprints” to produce smaller deliverables (deliver software “early and often”). Changing requirements are expected and there is close, daily cooperation and communication between business people and developers. Team members are co-located team members when it’s possible.
Most organizations have their own specific project methodology and if AGILE is part of their SDLC, it most likely has been customized to meet the needs of that organization.
While AGILE has been successful in many instances, it presents challenges for very large implementations and in large organizations where a centralized IT team supports multiple business enterprises. Technology teams typically have a good understanding of what AGILE means. But business users, project sponsors, and stakeholders may not be as clear. So detailed planning and excellent communication are key to ensure agreement as to exactly what functionality will be delivered “early and often”, as well as the quality of that deliverable (i.e., what bugs will be fixed when, and how will they be retested?)
Additional challenges arise when an AGILE development approach, which may fall under Agile Project Management Methodology, is supported at the corporate level. This is particularly true when you’re implementing a new vendor-based software solution. Individual enterprises may need to continue following a waterfall development approach when they have older legacy systems with multiple integration points. This situation creates frustrations, conflicts, and costly regression testing.
Any methodology should be viewed as the framework within which a project manager executes solid project management skills. They tailor the methodology to the specific organization and actively manage process interactions (i.e., scope change will affect cost and require trade-offs). Managing in an “agile” way has always been a core competency of successful project managers. Adopting an Agile Project Management Methodology should not be interpreted as a way to do an end-run around controls. Nor is it a license to take short-cuts through the critical processes of project management, (initiating, planning, executing, monitoring and controlling). Instead, it should be viewed as an opportunity to consider a new and, hopefully, improved way of achieving success.
It is still not entirely clear if managing an AGILE software development effort automatically qualifies as adopting an “Agile Project Management Methodology” approach. Perhaps there is now a broader meaning to this project management approach which may or may not involve AGILE software development. It may just infer producing results faster. Hopefully this will be made clearer over time. It will be interesting to track this Agile Project Management Methodology and to note how it is improving overall project management execution and delivery. It must be evaluated from the perspective of the project team, project sponsors, stakeholders, and end users.
At the beginning of your 4pm course, when you and Dick talk to design your program and what you want to learn, you will select case studies that fit the kind of projects you want to manage. Chose you course and then select the which specialty case study from business, or marketing, or construction, or healthcare, or consulting. That way your case studies and project plans, schedules and presentations will fit your desired specialty.