Project Management

Agility and Project Leadership

by
A contrarian and provocative blog that goes beyond the traditional over-hyped dogma of "Agile", so as to obtain true agility and project leadership through a process of philosophical reflection.

About this Blog

RSS

Recent Posts

Has Scrum outlived its usefulness? Should Scrum just go away?

The rise of Agile’s SAFe is like a bad episode of the movie Groundhog Day

Marcel Proust’s recursive novel: Why the concept of iteration in Agile is shortsighted

Forecast for 2015: The beginning of the end of Agile?

Google considered the best US company to work for due to HR agility

Categories

Date

PMBOK v5 Draft - More Agile integration

linkedin twitter facebook Request to reuse this  

The PMBOK v5 Guide Exposure Draft was made available to the public on February 17, 2012 and is available for public review and comments/recommendations by PMI members.  What this means is that you have an opportunity to provide your feedback on the draft before it goes to final publication.

Here are some of the major changes I’ve seen:
  • They took out Chapter 3 (The Standard for Project Management) and placed it in the appendix since it is now an ANSI standard
  • The communications content that used to be part of Chapter 11 is now a new Chapter 13 titled “Stakeholder Engagement” which adds a new, 10th knowledge area called “Project Stakeholder Management”
  • The word “Plan” has been added to the knowledge areas in the Planning Process Group for items such as Scope, Schedule, Cost, and Stakeholder management much like it was in previous editions
  • There are now 47 processes in the 5th edition PMBOK Guide exposure draft as well as 614 input, tools and techniques and outputs which is about 15-20% more than the previous edition
The interesting sections for me were the continued addition of Agile terms and practices.  Take this section on the “Adaptive Life Cycles”, section 2.4.2.4:
 
Adaptive life cycles (also known as change-driven or agile methods) are intended to facilitate change and require a high degree of ongoing stakeholder involvement. Adaptive methods are also iterative and incremental, but differ in that iterations are very rapid (usually 2 to 4 weeks in length) and are fixed in time and resources. Adaptive projects generally perform all processes in each iteration, although early iterations may concentrate on planning activities.
 
Sound very Scrumish and from this we can see why stakeholder management was spawned off as a separate knowledge area that is included in all the process groups except closing since “to facilitate change and require a high degree of ongoing stakeholder involvement”.  Much as is advocated in Agile/Scrum is the need for constant customer engagement and feedback and this is now reflected in the draft version of the 5th edition PMBOK.
 
Rolling Wave Planning is more aligned with Agile in section 6.2.2.2:
 
Rolling wave planning is an iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a more general level. It is a form of progressive elaboration. Therefore, work can exist at various levels of detail depending on where it is in the project life cycle.
 
For example, agile project management, originating in software development, uses iterative planning as a progression of rolling wave planning. The agile project team utilizes CPM scheduling for each development cycle (iteration). Agile project management focuses on shorter development cycles and tangible results for each iteration; the focus is on creating value instead of completing activities.
 
And in Section 6.7 regarding Control Schedule:
 
If an agile approach is utilized, control schedule is concerned with:
Determining the current status of the project schedule by comparing the total amount of work delivered and accepted against predictions of work completed for the time elapsed,
Conducting retrospective reviews (scheduled lessons learned reviews) for correcting processes and improving, if required,
Reprioritizing the remaining work plan (backlog),
Determining the rate of delivery (velocity) and acceptance of work per iteration (agreed work cycle duration, typically two weeks or one month),
Determining that the project schedule has changed, and
Managing the actual changes as they occur.
  • Determining the current status of the project schedule by comparing the total amount of work delivered and accepted against predictions of work completed for the time elapsed,
  • Conducting retrospective reviews (scheduled lessons learned reviews) for correcting processes and improving, if required,
  • Reprioritizing the remaining work plan (backlog),
  • Determining the rate of delivery (velocity) and acceptance of work per iteration (agreed work cycle duration, typically two weeks or one month),
  • Determining that the project schedule has changed, and
  • Managing the actual changes as they occur.
 
Mike Griffiths of the PM blog “Leading Answers” who worked on the Agile sections of the PMBOK states it pretty well when he says “never have I worked so hard, to write so little, about agile”, since as can be seen from the sections above, the draft PMBOK is articulating Agile practices, but is trying very hard not to be perceived as advocating Agile as Agile is generally practiced and known.
 
In my view, I can actually understand this rationale.  Though I have seen studies that indicate that the majority if project managers who are studying the PMBOK for the PMP are in the IT industry, there are still many who are not and as a body of knowledge for general project management best practices, they need to be as agnostic as possible.
 
In any event, for those interested and with current PMI membership status I recommend you check it out.
In any event, for those interested and with current PMI membership status I recommend you check it out.The PMBOK v5 Guide Exposure Draft was made available for review on February 17, 2012  and is available for public review and comments/recommendations by members.  What this means is that you have an opportunity to provide your feedback on the draft before it goes to final publication.
 
Here are some of the major changes I’ve seen:
They took out Chapter 3 (The Standard for Project Management) and placed it in the appendix since it is now an ANSI standard
The communications content that used to be part of Chapter 11 is now a new Chapter 13 titled “Stakeholder Engagement” which adds a new, 10th knowledge area called “Project Stakeholder Management”
The word “Plan” has been added to the knowledge areas in the Planning Process Group for items such as Scope, Schedule, Cost, and Stakeholder management much like it was in previous editions
There are now 47 processes in the 5th edition PMBOK Guide exposure draft as well as 614 input, tools and techniques and outputs which is about 15-20% more than the previous edition
 
 
The interesting sections for me were the continued addition of Agile terms and practices.  Take this section on the “Adaptive Life Cycles”, section 2.4.2.4:
 
Adaptive life cycles (also known as change-driven or agile methods) are intended to facilitate change and require a high degree of ongoing stakeholder involvement. Adaptive methods are also iterative and incremental, but differ in that iterations are very rapid (usually 2 to 4 weeks in length) and are fixed in time and resources. Adaptive projects generally perform all processes in each iteration, although early iterations may concentrate on planning activities.
 
Sound very Scrumish and from this we can see why stakeholder management was spawned off as a separate knowledge area that is included in all the process groups except closing since “to facilitate change and require a high degree of ongoing stakeholder involvement”.  Much as is advocated in Agile/Scrum is the need for constant customer engagement and feedback and this is now reflected in the draft version of the 5th edition PMBOK.
 
Rolling Wave Planning is more aligned with Agile in section 6.2.2.2:
 
Rolling wave planning is an iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a more general level. It is a form of progressive elaboration. Therefore, work can exist at various levels of detail depending on where it is in the project life cycle.
 
For example, agile project management, originating in software development, uses iterative planning as a progression of rolling wave planning. The agile project team utilizes CPM scheduling for each development cycle (iteration). Agile project management focuses on shorter development cycles and tangible results for each iteration; the focus is on creating value instead of completing activities.
 
And in Section 6.7 regarding Control Schedule:
 
If an agile approach is utilized, control schedule is concerned with:
Determining the current status of the project schedule by comparing the total amount of work delivered and accepted against predictions of work completed for the time elapsed,
Conducting retrospective reviews (scheduled lessons learned reviews) for correcting processes and improving, if required,
Reprioritizing the remaining work plan (backlog),
Determining the rate of delivery (velocity) and acceptance of work per iteration (agreed work cycle duration, typically two weeks or one month),
Determining that the project schedule has changed, and
Managing the actual changes as they occur.
 
 
Mike Griffiths of the PM blog “Leading Answers” who worked on the Agile sections of the PMBOK states is pretty well when he says “never have I worked so hard, to write so little, about agile”, since as can be seen from the sections above, the draft PMBOK is articulating Agile practices, but is trying very hard not to be perceived as advocating Agile as Agile is generally practiced and known.
 
In my view, I can actually understand this rationale.  Though I have seen studies that indicate that the majority if project managers who are studying the PMBOK for the PMP are in the IT industry, there are still many who are not and as a body of knowledge for general project management best practices, they need to be as agnostic as possible.
 
In any event, for those interested and with current PMI membership status I recommend you check it out.
Posted on: February 22, 2012 10:59 PM | Permalink | Comments (0)

Being a Lean-er Startup

linkedin twitter facebook Request to reuse this  

Here'a a video by author Eric Ries on being a lean-er startup:

 

 

This movement seems to be catching on quite well, and interestingly, much like the early days of project management that was done informally and with very little structure that now has many methods and best practices associated with it, Mr. Ries is arguing that launching and managing a startup can be put on a more systematic and scientific basis with methods and best practices from Lean and other business processes.

Of course as anyone who has been involved with managing projects or with startup business ventures would know, that it is much as art as it is science, but I do applaud his efforts to put setting up a startup which is typically associated with chaos on a more firmer foundation.

It is very similar to an idea I have about reconciling the best PM practices with startup business ventures.

You can buy the book on Amazon:

Posted on: February 06, 2012 11:10 PM | Permalink | Comments (1)

The Cult of Agile

linkedin twitter facebook Request to reuse this  

Wikipedia defines a cult as "a new religious movement or other group whose beliefs or practices are considered abnormal or bizarre".  Images of Charles Manson or Jim Jones comes to mind with brainwashed individuals engaged in bizarre rituals and following their crazed leaders without question to murder or commit mass suicide.  So it may seem harsh for me to title this post as the "cult of Agile", but when I see blog post such as this one titled "Project Management: A Malady" or "Are Project Managers Living a Lie?" where in their over zealous efforts to promote Agile, they blast traditional project management, I can't help but to feel as though they are speaking as if from a cult.  As Tobian Mayer of Agile Anarchy posts:

Contrary to popular myth, Project Management is not a job, a profession or a career path. It is an illness, a disorder characterized by delusion, specifically a desire to control people and outcomes, and a belief that the future can be accurately predicted if only everyone did what they were supposed to do. Sufferers in the advanced stages of this illness resort to resentment, blame, and fear, and can often be seen pouring over spreadsheets and charts, pulling their hair out in dismay, or pounding their desk... Just as the alcoholic frequents bars and other drinking holes, seeking validation of his or her resentments towards the world, so the Project Manager attends PMI and other certification courses to be reminded, I am right!... Happily, there is a cure. It is a program of recovery called Agile, but because the nature of the program is a complete reassessment of one’s life and career, few are able to engage, seeking, as always a quick-fix solution.


Though I realize that much of this is a tongue-and-cheek jibe at traditional project management, I have seen such rhetoric hurled at traditional project management to advance Agile methods.

In general, I don't think it will help promote Agile in a constructive way, especially amongst those millions of project managers who are tasked with projects that are not always conducive to Agile methods or for those who would like to adopt and incorporate the practices into their day-to-day work.  It could turn them off to the practices, which would be the real loss since there are many benefits to using them.

Any seasoned project management professional (though the quote above and some within the community argue whether a PM is a true professional such as an accountant or lawyer, I believe we are professionals in the general sense) would know that there is no one size fits all to managing projects, but rather the ability to have a broad and deep understanding of the best practices in his/her industry and to apply the best one to their individual projects.
For me its like a sliding scale:  On one end you have pure Agile and on the other your have pure traditional project management.  And depending on your project, team, stakeholders, expectations, and organizational structure, you would see where your project fits within the scale and apply the best practices to make your project succeed.

In the end, all that matters is whether your project was done on time, within budget/scope and most importantly, to customer satisfaction.  No one will care whether you did Agile, traditional or voodoo magic.

Posted on: January 30, 2012 10:44 PM | Permalink | Comments (2)

When whole overseas industries become more Agile

linkedin twitter facebook Request to reuse this  

This very interesting article from the NY Times talks about how and why the US lost out to China for the manufacturing of the iPhone.  Though most would think it is cost that drives companies like Apple to transfer their manufacturing overseas, the article points out that it was only one of several major factors:

It isn’t just that workers are cheaper abroad. Rather, Apple’s executives believe the vast scale of overseas factories as well as the flexibility, diligence and industrial skills of foreign workers have so outpaced their American counterparts that “Made in the U.S.A.” is no longer a viable option for most Apple products.

The article goes on to talk about the incredible Agility of Chinese companies like Foxconn in China, where "Apple’s executives had estimated that about 8,700 industrial engineers were needed to oversee and guide the 200,000 assembly-line workers eventually involved in manufacturing iPhones. The company’s analysts had forecast it would take as long as nine months to find that many qualified engineers in the United States... In China, it took 15 days".

Furthermore, companies in China have many skilled workers who have highly specialized technical skills that are above most manufacturing level labor, but not necessarily at the level of a formal engineering degree at the university that just cannot be matched in the US.  They are also able to mobilize them very quickly with no issue both for the employer and employee, for the most part, to work 12 hour shifts, 6 days a week.

We can dispute in this country whether that work level will be sustanable and if it's worth the loss of personal life with family and friends that will take its eventual toll, but in my opinion I have no doubt much of this comes down to people in countries like China who are just more hungrier for financial success than we are in the US and Europe.  Whether this is good or bad in itself is missing the point that China other countries are and will continue to outpace us in manufacturing which is a catalyst for creating middle class jobs.

What this entails for those of us in the project management field, is that as we all know, the world is getting flatter, faster and more projectized for as the article points out,

The pace of innovation, say executives from a variety of industries, has been quickened by businessmen like Mr. Jobs. G.M. went as long as half a decade between major automobile redesigns. Apple, by comparison, has released five iPhones in four years, doubling the devices’ speed and memory while dropping the price that some consumers pay.

Your now going to have to deal with whole industries in other countries that are more agile, flexible and speedier with respect to how they dispatch and deploy their workforce, engineer their business processes, and manage their portfolio of projects.

We are in for some interesting times indeed.

 
In China, it took 15 days.
 
In China, it took 15 days.
Posted on: January 23, 2012 12:40 AM | Permalink | Comments (1)

Ernest Shackleton: Case study of an extreme Agile project leader

linkedin twitter facebook Request to reuse this  

As part of my holiday ritual, I put aside a few books to read just for pleasure that I don't often get a chance to do when bombarded with my usual busy schedule of work and other commitments.  These books can be of any variety and often are not directly pertinent to project management or other business related topics.  But one book I did read was actually one of the most pertinent books on managing projects I've come across and was completely captivating and engaging to boot.  The book was titled "Endurance: Shackleton's Incredible Voyage" by Alfred Lansing:

 

 

One of this site's very esteemed blogger, Ty Kiisel,  wrote about it last year and very pertinently focused on the team collaboration and cooperation that pulled those men though such a treturous and perilous situation of survivial, that has to be one of the greatest, if not the greatest real life stories of survival ever told.

In August 1914, Shackleton and his crew set sail on the Endurance for the South Atlantic. In October 1915, still half a continent away from their objective, the ship was trapped, then crushed in the ice. Twelve hundred miles away from land, drifting on ice packs, Shackleton and his men survived the next five months on a diet of dogs, penguins and seals. When the ship eventually sank they were forced to escape by lifeboat. Shackleton then travelled another 850 miles in an open boat across the stormiest ocean in the world to reach help. Every single man got home safely. 

Though the story is known, Lansing's book grips you at every moment and just when you think Shackleton and his crew cleared one life ending disaster, another one crops up as they are constantly battling for their lives with decreasing odds of their survival.  The wind, the dampness, the bitter cold and the long months of darkness in the winter seem like more than any man should be able to stand. They slept in wet sleeping bags in sub-freezing temperature; ate unappetizing foods; and still managed to keep their hopes alive.

While reading the book, I had to constantly remind myself that this was not fiction but events that actually happned even when the situation and the ability of Shackleton and his crew to overcome them seemed even beyond what any fiction could come up with.

I leave it up to you to read this fantastic book for the rest of the harrowing, yet optimistic tale, but as I mentioned I came out of reading this book with some rather enlightening project management lessons in leadership, being agile, adaptive and flexible when faced with life critical situations, and knowing how to manage your teams and trust in them.

  • Protecting your team - Schackleton exemplied the kind of leader who understand putting his team first. When he found his men wavering and surcoming to the elements, starving and near death, he pushed extremely hard when he had to, but also knew when to trust his team.  He also had the kind of emotional intelligence we talk about these days in that when he choose his crew, he looked deep into their pschology and charactersitics and situated them to ensure they would succeed with each other to survive. When one crew member responded best to flattery, for example, Shackleton flattered him. Another responded best when reminded of the legal agreement he had signed when becoming a crew member, and Shackleton underscored this agreement to him whenever necessary.
  • Agile and adaptive tactics for maximum flexibility - Though we like to expouse how change is the new norm these days, in Shackleton's situation, unpredictable change was the absolute rule, not the exception and being agile and adaptive was a matter of life or death.  Once Shackleton realized that the Endurance was trapped in the ice, he resolved – and, despite his bitter disappointment, communicated matter-of-factly to his men – that their goal had changed from crossing Antarctica to wintering over on the ice.  Twice, he tries to trek toward the sea, his men dragging a supply-laden lifeboat across soft ice and snow. Twice, he abandons the effort after their progress falls far short of his estimates. Again and again, he sets a course that must be altered based on the change in situation - just as good leaders must do.
  • Equality and cross-functionality of teams - Shackleton established a loose hierarchy among his men, which allowed them to draw strength not just from him but from one another. All of the men -- including the scientists who were part of the crew -- were expected to perform mundane chores as well as take over each other's tasks when the other was too weak or ill to do it.  Shackleton shared hardships with his men, even when his position might have allowed him not to do so.  For example, after telling his men that they needed to leave behind personal articles to lighten their load, he took out the Bible personally given to him by Queen Alexandra and placed it on the snow. Then he walked away.

And though Shackleton is not labeled a project manager, he exihibited all the characteristics of a modern project manager in that he had to secure, manage and track the funding and budget for the project to reach Antartica, secure and manage his team, define the scope and requirements needed to achive the project goals, we as well as execute and control his project.

Of course his project failed, but to get his men home safely, he led them across ice, sea and land with all the tools he could muster. This combination of a commitment to a larger purpose while utilizing flexible and imaginative methods to achieve a goal is increasingly important in our tumultuous times and is a skill us project managers and leaders could all learn from and use to ensure success in our project goals.

Posted on: January 08, 2012 02:29 PM | Permalink | Comments (1)
ADVERTISEMENTS

People on dates shouldn't even be allowed out in public.

- Jerry Seinfeld

ADVERTISEMENT

Sponsors