You’ve heard the term “business agility”, I’m sure. And I’m sure you have a general sense of what it means… responding to the pace of business change, being innovative and creative, responding to competition and other business challenges…
Well, as part of business agility, I’m one who believes that the need to be agile applies very much to business project management as well. In the recent series of articles that I published by Dr. Aaron Shenhar, he argued for the need for a “new adaptive framework” in project management, and he’s talking about the same thing. Hal Macomber is also talking about he same thing in his blog, Reforming Project Management and the work he does with Lean Project Consulting.
So, it’s time to stop associating agile with a particular method of software development and begin thinking about how to be more agile, responsive, and adaptive in our approach to managing projects. And I’m speaking of all types of projects, not just software development.
In my new ebook on principles of project success, which will be released soon, I write about many agile principles even though I had not starting using the “agile” label to describe those principles. But I recently came across a great article entitled “What is Agile, Really?” by Kent McDonald. In reading it, I realized that agile is now very applicable to project management generally – without resorting to the terminology and methods of Scrum. And, more than that, the agile PM principles I believe in strongly are very much aligned with the thinking of others, such as expressed in Kent’s article.
In his article, McDonald emphasizes seven principles:
- Collaborate
- Iterate
- Serve the Team
- Consider Context
- Practice Excellence
- Reflect and Adapt
- Deliver Value
Kent’s article is well written and makes some excellent points about how agile principles can and should be applied to project management today in order to be successful. In his article, he explains and expands on each of the seven principles. In the paragraphs that follow, I will give my interpretation of those same principles.
In my writings, I emphasize a number of similar principles but I often use different terms for them. For example, instead of “collaborate”, I may emphasize the importance of building “cohesive” teams. And when I expand on that concept, one aspect that I include is collaboration – i.e., the actions of project teams undertaking creative development tasks collectively rather than as individuals in order to capitalize on the synergy and creativity that comes from teams working in a cohesive way.
“Iterate” is about the need of the team to learn in the course of the project — and this can occur during both planning and execution. In fact, not accounting for the need to learn — during understanding the requirements of what is to be produced and during actual development of the product or solution — is a probable (and common) cause of project failure.
“Serve the Team” is all about the fact that the project manager must be the facilitator of the team rather than the manager. To be truly successful, the team must plan and execute the project, and the project manager must facilitate the project by facilitating the team.
“Consider Context” is about the fact that we can no longer talk about best practices that always work. Best practices must be taken in context because different techniques may be best in different situations, and practices/techniques must be adapted to the specific context.
“Practice Excellence” is all about producing business results that make a real difference by delivering real value to the business. The team that is focusing on delivering real business value – if they truly understand the goal and the purpose of the project – should not settle for mediocre (partial) results and instead, should be self-driven to deliver full results and maximum value.
“Reflect and Adapt” is about paying attention to what is working or not working and adapting appropriately. In lean or agile approaches, this often described in terms of “continuous improvement” througout the project. Lessons learned at the end of the project are too little, too late.
“Deliver Value” is very similar to Practice Excellence, and I tend to combine these two principles. But in agile methods, there is an important emphasis on 1) doing only those things in the project that really add value, and 2) doing the most important and valuable things first. In iterations of development, it often makes great sense to defer anything that produces less value to a later iteration or to a later release of the product. Related to this is the need for the team to fully understand the requirements of the business/customer organization and to agree on activities that are most important (i.e., valuable) throughout the course of the project.
Project success tip: Begin learning about agile or adaptive principles and how to apply them to your projects. Such principles are driven by the need to deliver successful projects by adapting to continuous business change.
{ 1 trackback }
{ 2 comments… read them below or add one }
These are just general good management principles; they’re not even ‘exclusive’ to project management. Looks to me that ‘agile’ is reinventing the wheel, and claiming it for itself.
Except for ‘iterate’ for which you really have to consider the context first, everybody should do this constantly.
You know, I can’t disagree with you – they are just good management principles. But I don’t think these are principles that are very widely recognized or understood or applied outside of organizations that are promoting or using agile or lean methods of management. It may well be that these principles are much more broadly accepted than I know, particularly where PM is highly disciplined and mature – such as in large aerospace, defense, and perhaps environmental engineering projects. But in most companies that I am familiar with, they are not yet embracing these principles day to day.