Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile
Limitations of Agile PM
As a veteran PM, I am glad to learn more and acquire new skills. I have been studying and doing all that I can to keep up with new processes and techniques. So I have certainly been paying close attention to all the Agile methodologies. Certainly, I can see the advantages to Agile development. Of course, it will only work in the IT world. This is not surprising because it is after all an IT methodology. However, there are more PM's in other industries than there are the IT world. In fact compared to other industries, IT is a newcomer to PM methodologies. So, as methodologies like Agile become more prevalent in the IT world, we run the danger of losing sight of the fact that project management has a much larger world than IT. I am aware that Gantthead is focused on the IT world, but we can still learn from other industries that have been doing PM far longer than the IT world. Many of the projects I work on have other business components that must align with the IT development.

I get concerned that many business organizations do not recognize how much of their work outside of the IT department are really projects or how many IT projects have dependencies on the business projects. These projects need the PM process we all seem to be ready to chuck in favor the new methodologies. We must take care that our PM methodologies align with entire project.

It is also seems to me that Agile development requires a level of committment from the business (users, SME's) to which few organizations are willing to commit. That is a weakness of the methodology with which functional based organizatizations are reluctant to address. It may be less an an issue in a projectized based organization, but most organizations still ascribe to the former.
Sort By:
Page: 1 2 next>
You raise a few interesting points:
a. Agile limited just to IT projects
b. Organizations not recognizing that some of the work outside IT should be managed as projects
c. IT projects having dependencies on business projects
d. Agile commitment requirements perceived as a weakness

Agile methodology is an iterative approach meant to deliver value in predetermined periods of time (runs). As such, it does not pertain to all IT projects and it is not limited to just IT initiatives. It does seem to work best where a product can be delivered to its customers having its grade enhanced by recurrent releases.
Sure, a software application example comes to mind, where more and more functionality is provided by these releases. But so a park can be opened to the public having more and more enhancements released periodically.
So Agile might be used in projects with little or no IT connection.
Like any methodology, it cannot be blindly applied to all projects, as there are drawbacks to this iterative approach.
Same, like any other methodology it does need to consider the organization environmental factors, so it might not provide value everywhere. However, it should not just be discarded because, like all methodologies, it can be adapted to some project scenarios.

The fact that an organization might see project management as an IT only framework is a problem that can and should be solved. There are fundamental benefits of implementing a project management framework in the enterprise that should make the buy in process simple.

The fact that IT projects have dependencies on business projects should not be a surprise anymore… IT, after all is a business enabler. Many business projects will have an IT component and very few projects have absolutely no business impact. How to manage this is again, dependent on the organization culture, attitude towards risk, etc.
Systems development is just a way to control IT development activities, but not a way to "run a project". Iterative, agile, waterfall.....doesn't matter. Still need a project charter, scope, schedule, quality, risk, communications plans and other related project management artifacts. So, to your point, the conversation about agile vs. waterfall is fine, but doesn't imply a specific project management methodology.

Agile external to IT is more often classified as "Lean". The agile and lean principles can apply to any project. While the details of some of the agile methodologies (XP, Scrum, et al), the principles of doing "just enough", customer involvement, etc. are right in the wheel-house of project management.

From a PMI perspective, this aligns with rolling wave planning, phases within projects and the idea of Progressive Elaboration.
Harlan, I couldn't agree more with the spirit and intent of your post. I hope we hear and learn from others.

I have employed the principles and aesthetics of agile management to many types of knowledge work well outside of the trappings of IT.

In addition, we've extended the reach of agile in IT by introducing lean concepts that make agile more rigorous and provide better organizational communication.

Agile, in the end, is not an IT-based set of methodologies, but small-team based methodologies.

The issues you are describing are issues that require an interface between organization-wide management systems and team-based management systems.

There are interfaces we can utilize to ease this tension.
Nice comments. I could not agree more with James. Agile is not restricted to IT projects. Agile is more intended to be used in projects with some characteristics such as small team and Small to medium scope and time to delivery the project.

Also on the comments was told the fact that Agile is more (or less) than a methodology, it can be used as good practises that can be used in a lot of kind of projects. You can use some Scrum principles (as standing meeting) or TDD (test driven development) in several cases, not only in IT projects (would not be cool to test every product or service from the begining?).

But Harlan is tottaly right asserting the fact that Agile aproach is being developed on IT cases, so the methodology is not getting improved to be used on others industries.
Just to make sure we are all on the same page here, agile (as articulated in the Agile Manifesto) is a philosophy based on 4 themes and supported by 12 principles. These themes are practiced as a methodology through the use of Scrum, eXtreme Programming, Lean software development, etc. Agile, as a philosophy, follows much of the practices of Lean manufacturing outlined by Toyota’s practice of TPS, which they have used for more than 40 years now.

Looking further at the use of agile philosophies outside of IT, have a review of the February 2009 article in the Harvard Business Review by Gary Hamel titled “Moon Shot for Management”. This article outlines a conference held in May of 2008 where management leaders came together to look at making management more “human” (the list of attendees is pretty impressive). The outcome of this conference was articulated in 3 themes and supported with 25 principles that seem to align well with agile philosophies. I believe we are only seeing the beginning of where this is all heading.

One final note, I believe it doesn’t matter what method you use; if the business is not invested in the project, it will likely fail.
Robin says "I believe it doesn’t matter what method you use; if the business is not invested in the project, it will likely fail. "

While I don't disagree, it strikes me that we have singularly lousy common definitions of "business" "invested" "project" and "fail."

The mark of any good process is facilitating common understanding of terms like these. So, I believe the relationship is highly symbiotic.

Good to see some counter-point about the use of Agile in non-IT domain.

Focusing in on Harlan's complaint that Agile requires an unusual amount of "commitment", perhaps he is really meaning "interaction". All project sponsors are at least somewhat committed to their projects, or else they wouldn't invest the money. The key characteristic of successful projects is collaborative communication. James uses the word "symbiotic", which is an excellent description of the kind of communication Agile management tries to encourage. Too often, sponsors throw a project over the fence to a contractor, and expect all their expectations to be met, without being bother with any interruptions ("what do mean I have to define acceptance criteria? Isn't that what I'm paying YOU to do").

Whatever you call it, Agile/Lean/Theory-of-Constraints, successful PMs encourage the right kind of interaction to get the job done.
Hear Hear, Jesse.

Far too often I've seen the commitment of the corporation expressed in terms of dollars to fund a project - but not in the communication and culture necessary to actually make the project successful.

Dollars do not equal commitment.

Interaction, however, certainly does.

Feature sets for most projects change significantly during the course of the project. Therefore, we can safely say that at project inception all we have is an idea about what we are about to do. This is true when building a house, remodeling a bathroom, landscaping the yard, or making software.

The natural meandering of craft means you can't just launch and leave.

Page: 1 2 next>  

Please login or join to reply

Content ID:

"That rainbow song's no good. Take it out."

- MGM Executive Memo after first showing of The Wizard of Oz