Voices on Project Management

> Back to Voices Home

The Gentle Art of Managing Agile

| | Comments (9) | TrackBacks (0)
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....

 

Bookmark and Share

 

The views expressed within the PMI Voices on Project Management blog are contributed from external sources and do not necessarily reflect the views and opinions of PMI.

0 TrackBacks

Listed below are links to blogs that reference this entry: The Gentle Art of Managing Agile.

TrackBack URL for this entry: http://blogs.pmi.org/mt-tb.cgi/214

Leave a comment

All comments are reviewed by our moderators, and will not appear on this blog unless they have been approved. Comments that do not relate directly to the blog entry's contents, are commercial in nature, contain objectionable or inappropriate material, or otherwise violate our User Agreement or Privacy Policy, will not be approved. For general inquiries not related to this blog, please contact Customer Service. Please read the Comments -- Question and Answers.

9 Comments

A good article. I always have this doubt whether Agile & low-level scheduling go together.

For e.g., in a typical MPP, we have all the low-level tasks defined and scheduled. If I'm managing the projects the Agile way, I find it difficult to track & monitor the project and maintain this MPP.

I would appreciate if you could provide an insight on this, maybe with a separate article. Thank you.

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.

I was working as the PM for the SW development company in the Sales Enablement Organizations (Presales, Professional Services), responsible to support Sales operations in the Pre-sales, Delivery (Implementation) and Post-Implementation phases in providing technical and project management expertise in delivering projects to the customer, initiated to develop and deliver components of automation for business processes in the enterprise IT environment.
Our standard Project Management Methodology, used to manage regular delivery (implementation) projects, was the proprietary project management methodology supporting SDLC, with much resemblance to the classical “waterfall” approach. The reason behind this was often in the customer request to use the project management methodology compatible with their SW developemnt and deployment methodology, used for all production implementations in their environment and the customer reluctance to, under normal circumstances, accept any deviation from their standards. As lessons learned pointed out, for implementations of complex EITM solutions, including extensive programming efforts in customizing the solution using standard API’s, this methodology did not provide the ideal framework to ensure the project success. In case of changes in design specifications later on in the project, it was quite inflexible, inefficient and costly. The recognized shortfall of the “waterfall” approach is the lack the flexibility in accommodating change requests regarding change of requirements later on in the project. That lack of flexibility was particular obstacle for project categories including trials, POC’s (Prove of Concepts), pilots and rescue projects (CIP’s). These projects all have in common similar profile regarding risks (high), visibility to the CA and customer management (high), financial impact on failure (high – in case of trials and POC’s the value of the lost potential business and in case of rescue projects the value of the future business), initial understanding of the scope (low) and time available to gain (regain) stakeholders confidence and trust (short).
Main characteristics of these projects is a recognition that, during an engagement, customers can change their minds about what they want and need, together with the appearance of previously unanticipated and unpredicted challenges, all having major impact on project constraints. This situation could not be easily addressed in a traditional predictive or planned manner (following SDLC “waterfall” approach) and managing like projects required adopting a fresh and empirical approach:
• accepting that the problem cannot be fully understood or defined before the start of the project
• focusing instead on maximizing the team's ability to deliver quickly
• responding to emerging requirements by decomposing the project deliverables in smaller parts
• enabling iterative and incremental approach

Rescue projects are probably the most complex category of project engagements. These projects were initiated when the regular delivery projects failed. Some recent statistics, according to recent Standish Group study (in US, assuming no difference for the rest of the world), points out that 23% of SW projects fail to deliver any working SW at all and for projects that do deliver software (the outstanding 77% of all projects), 45% are over budget, 63% over schedule and when they are done they deliver only 67% of originally planned functionality. Based on the industry track record, the SW projects estimated to take 12 months to complete and cost about $1Million can be reasonably expected to take closer to 20 months and cost $1.5 Million delivering only about 2/3 of the requirements.

The big question is why IT projects fail and what kind of project management framework would increase the likelihood of success? I believe the answer is obvious when we answer the question why the SW solutions are developed in the first place. In most cases, the objective is not to craft some algorithm, it is to satisfy some business need, and because of that the first and the most important PM governance objective is to manage the project by aligning the project and business objectives. For most projects delivering EITM solutions for automation of some business process, there is no requirement to achieve 100% accuracy in delivering solutions by implementing 100% of initial requirements, unlike implementation of real time banking or accounting solutions, where 100% accuracy is the first and most important project objective.
That means that, in all area of business automation or EITM deployment, where 100% delivery of requirements is not the prime project objective, it is O.K to make solution not perfect
(it cost too much to be perfect), but functionally acceptable compromise between engineering natural drive to perfection and required and sufficient business functionality. To be able to deliver on those objectives, the project management framework must support that objective. What developers lack, from my broad experience as a developer and a PM, is the business understanding that we have to deliver the best possible solution to the business problem using limited resources to accomplish this goal. That is the reason why developers have to understand the business processes they are trying to automate to make purposeful, appropriate, business-conscious technical decisions so that a business sponsor (one always exists, the one who is paying our salary) can get the most out of limited resources. From my personal experience as a developer and a PM, the agile framework is one such framework which can overcome that gap, and because of that, it was the natural choice to use it, in the management of rescue efforts in salvaging failed EITM projects. When our cavalry was called in to rescue a project, the project was usually in the critical phase. The blame was surfacing in communications with the customer project sponsor, and the relationship with the customer reached all time low. The options left on table either included the arbitration regarding deliverables (what would have negative impact not only on the relationship with that customer and potential future business with them, it would have negative impact on the whole business in the region) or bite the bullet and sponsor the rescue effort, which will reestablish the confidence in our (vendor’s) ability to deliver. That was the reason why the agile framework, including the customer as a partner to the project team with its incremental approach in delivering functional solution components, was an ideal candidate for the management of the rescue projects, making sure that problems are not going to be covered under the carpet and that steady stream of deliverables will reestablish the customer confidence in the our ability to deliver. At the same time, the project steady progress had a positive impact on the project team, which was already working in the hostile environment and under the extreme pressure to deliver where others failed. It is my experience that the PM on these projects should have not only PM experience in managing projects but as well deep technical understanding of the solution and that he/she had already earned the respect of the usually small team of technical specialists, tasked to deliver the solution. In that situation there is a role to play for the seasoned PM:
• to create a development plan selecting requirements for the iteration (iteration scope) with the team, taking into account the outcome of the previous iteration and priority of requirements
• acts as a buffer between the team and any distracting influences, focusing the team on the current prototype, not allowing any change of the focus or the scope for the iteration cycle
• removing impediments to the ability of the team to deliver iteration goals, if necessary by escalation to the project sponsors (both the vendor and the customer)
• be the owner of the escalation process to the project sponsor and/or vendor’s development and technical support distributed teams, coordinating join development and test activities
• owning Risk Mitigation, Monitoring and Management (risk analysis) at every stage
• frequently informing project stakeholders of the project progress and providing advance warning for the potential project slippage and deviations ahead of time
• facilitating daily open and honest communication and cooperation among the team members


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

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll

Categories