A Guide to the Project Management Body of Knowledge (PMBOK® Guide)--Fourth Edition has nine technical knowledge areas plus the overall integration processes.
By aligning these processes to the Agile delivery methodology, effective project management will enhance the probability of success. But you must recognize the processes are applied differently.
Some of the areas that need an Agile approach include:
Project Scope Management
Traditional project management expects scope management to define the output. The final outputs in an Agile project should be defined in terms of achieved capabilities--how the capability will be achieved will be discovered along the journey.
Change control will be more challenging, as is configuration management. The overall project needs a really good systems architect to keep each iteration or sprint focused on contributing to the big picture.
Project Time Management
In an Agile project, scheduling and workflow become closely aligned. The overall system architecture optimizes the sequence modules needed to be built in to allow progressive testing and implementation of capability.
This defines the schedule. Scheduling should be at a much higher level; each sprint is likely to be a single activity of one to two weeks' duration.
Project Cost Management
Agile projects should be based on either a cost-reimbursable system, or the client accepts scope is a variable based on achieving the maximum improvement possible for a pre-set budget. This is a totally different philosophy to traditional project governance.
Project Quality Management
This is probably easier under Agile. Quality is continually assessed by the involvement of the client and the iterative release of modules to production.
Project Communications Management
The level of trust needed to run an Agile project is much higher than a traditional project. Effective communications in all directions are essential.
Project Procurement Management
Agile works in a collaborative partnering space. In the engineering world these are called alliance contracts. Traditional contracts do not support Agile delivery methods very effectively.
More later....
By aligning these processes to the Agile delivery methodology, effective project management will enhance the probability of success. But you must recognize the processes are applied differently.
Some of the areas that need an Agile approach include:
Project Scope Management
Traditional project management expects scope management to define the output. The final outputs in an Agile project should be defined in terms of achieved capabilities--how the capability will be achieved will be discovered along the journey.
Change control will be more challenging, as is configuration management. The overall project needs a really good systems architect to keep each iteration or sprint focused on contributing to the big picture.
Project Time Management
In an Agile project, scheduling and workflow become closely aligned. The overall system architecture optimizes the sequence modules needed to be built in to allow progressive testing and implementation of capability.
This defines the schedule. Scheduling should be at a much higher level; each sprint is likely to be a single activity of one to two weeks' duration.
Project Cost Management
Agile projects should be based on either a cost-reimbursable system, or the client accepts scope is a variable based on achieving the maximum improvement possible for a pre-set budget. This is a totally different philosophy to traditional project governance.
Project Quality Management
This is probably easier under Agile. Quality is continually assessed by the involvement of the client and the iterative release of modules to production.
Project Communications Management
The level of trust needed to run an Agile project is much higher than a traditional project. Effective communications in all directions are essential.
Project Procurement Management
Agile works in a collaborative partnering space. In the engineering world these are called alliance contracts. Traditional contracts do not support Agile delivery methods very effectively.
More later....
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.
I have been a PM for various company internal R&D (IRAD) projects and have been asked to use EVMS to track progress.
The nature of R&D is a learning and evolving experience where tasking and scope can change on a weekly basis. I'm familiar with Agile techniques used in software development and believe Agile Project Management may be the best approach for R&D projects that may involve trade studies or even prototype development and demonstration. I would like to set weekly milestones with tasking that leads to monthly presentations or demonstrations. However, planning for 12 months makes it a challenge to determine funding.
Does anyone out there have experience using Agile for managing R&D projects?
I have been in contact with agile project management since 2007. Among others important findings, my research results provided a better understanding of the definition of Agile Project Management which can be classified as an "approach", or "philosophy", as an example of "Lean Thinking". Its applicability transcends different types of projects, and it depends on its intensity of adoption, project environment, project team competences, and organizational characteristics. Project managers can combine best project management practices with Agile approach within every nine knowledge areas as described in the PMBoK guide, as discussed by Linda Bourne.
Many questions still remains in the field when dealing with agile techniques, specially in companies that are facing complex and innovative product development projects that involve software and hardware. The literature regarding Agile needs more practical applications and use cases to provide a clear understanding on how proper apply this approach in different project environments.
Agile Project Management is based on a set of principles and practices that have the purpose of simplify the process of managing projects. Flexibility, simplicity, iterative delivery-driven product, self-management and self-discipline are some of the premises pursued by Agile project teams. The Agile approach clearly focus on team performance development by enhancing the leadership and self-management capability.
The term "Agile Project Management" was coined in the software development area. Some methodologies have emerged based on Agile principles, e.g. SCRUM, XP and others. However, these "Agile principles" must be well investigated when applied to other areas, specially on innovative product development projects. Good examples of this project environment are Technology-based companies that have been constantly struggling with challenges and difficulties on how properly create, implement and improve project management methodologies.
It would have been better if PMBOK added Project Value Management since Agile is all about delivering business/customer value. From my experience in last couple of years working on Agile projects, the scope is typically unlimited, meaning business clients add work to backlog all the time (continuous requirement) as they work with the development team to prioritize. The development team would deliver the features with most value first and so realizing return faster than that with the typical waterfall approach.
On the same token, I understand that PMBOK is truly a "body of knowledge" and serves wide variety of industries. Agile adoption is predominantly in the IT industry and so applying many principles to let's say construction industry would be a impractical. In short there is obviously a need to generalize many of the Agile principles to suit projects in different industries.
--
DISCLAIMER:
The views expressed here are mine and do not reflect the official opinion of my employer or the organization through which the Internet was accessed.
I agree on the concept of " Art " mentioned in the title.I like to view agile as a set of tool for doing things, rather than a seperate project management methodology.Perhaps, it's more defined and crystalized in software development, but when it comes to other types of projects, Agile is another technique to deliver and deal with project progress.
I don't see any problem in using both traditional, or shall I say, conventional project management standards, along with agile tools and techniques, on certain areas of the project, and in certain times, as appropriate, to manage the project. In such cases, a project artist, more than a project manager,is the one who can succeffully and creatively manage and produce deliverables of high value, both for the customer, and the project team.
It seems to me that Agile methodology and the PMBOK methodology should be all contained in one PMBOK handbook as one and the same. There is no use of offering these as separate or one better than the other, because where is the time for working on two different methododlogies in a Project where time is always in short supply, when so many elements of the project have to meet time and budget constraints!! Projects are not 'academics' but actual work to be completed on time and within budgets!
In the current context of cost reduction and control, the agile methodology, the good systems architect should only allow changes which are well within the budget and contributes signifiantly to the capabilities to be achieved & adheres to timeline.
Iterative changes should be a function of an excellent technical discovery/proven module available (from contractor/tech provider) or value engg, and should not bend on experimentation, learning & validation reliance
Clear cut responsibities across design groups - across modules and geographies are also key in this methodology