Surviving The Project Age – An Agile Framework Part 1

Part 1: The Project Age and the case for Agility

Perfection of means and confusion of goals seem — in my opinion — to characterize our age.

Albert Einstein

As announced in my last blog entry, this is Part 1 of a 5-part series laying out the elements of an Agile project management framework. It will discuss the context of realising projects in today’s turbulent environment, as well as why Agility has become a must for most projects. By doing so, readers not familiar with Agile will have a better understanding of what the word “Agile” really means and what it implies for organizations and people managing projects in 2011.

Back in 2001, Hugues Bouchard, (1) a fellow project management professional, and I wrote a working paper welcoming people to what we called the “Project Age”, our 21st century. This working paper was later used as a starting point in the development of the 1^st edition of PMI’s “The Standard for Portfolio Management”. Back then, this is what we were seeing:

Our times are characterized by:

• Worldwide competitive pressures
• The need to differentiate oneself in a global market
• The requirement to meet high quality international norms and processes to be accepted in new markets and be more competitive
• Shorter and shorter product life cycles
• Faster new product development imperatives

Today’s organizations are forced to invest more and more of their resources in strategic projects in a race to keep the upper hand over competitors and increase their value, be it for their owners, their shareholders, their customers, their employees or society as a whole.

In the new economy sectors (biotech, telecom, IT, e-business, etc.), “mixed” organizations, executing as much activities or more activities on the project side than on the traditional/operational functional side of their businesses, are now being more and more involved in the development of project offices, program management systems, portfolio management and “gating” processes, strategic project management organizational structures and the like.

Even more traditional manufacturing organizations are forced, by global competition and time-to-market pressures for new products, to invest in strategic projects to keep their edge. While doing so, they have to reconcile a strong functional culture with the peculiar needs of delivering through unique, “one-time only” projects. In this situation, these organizations are also developing their versions of project portfolio management systems, “gating” processes, project support offices, sometimes in an atmosphere of great unease. This is particularly true of those organizations who still have to maintain a strong functional culture while, at the same time, committing more and more time and resources to project initiatives. (2)

Do you recognize your business environment? I believe that these words still define correctly our turbulent times. This turbulence has even increased many times in certain cases. Projects and recurring operations are so entwined together nowadays, that both functional order and the chaos of change coexist in most working situations.

One of my clients recently told me that:

“There are so many projects in our organization that it is a challenge everyday to both realize those projects and do our operational work properly. If we compare our current operations to the action of driving a car, those projects make us feel as if we have to change the car engine while still proceeding at full speed with our car ride”

All these projects still cause much confusion in organisations, most of them having yet to put in place a proper corporate project portfolio management system; that is, from my observations and experiences, the reality of the vast majority of the organizations I came across. Basically, I found the following project environment in those organisations:

• Upper managers do not agree on the number of projects taking place in their organisation, estimates often differing by a factor of 10
• Year after year, most managers complain that they have too many projects to realise (they are understaffed)
• The syndrome of «the Project of the Day» is ever present, new urgent matters taking over current ones
• Resources are spent on projects that have little or no value for the organisation
• A lot of efforts are spent on starting projects that end up never being completed

Amidst all this confusion, this multi-project environment has also created a new kind of project management reality that of the part-time project manager working with a part-time project team.

What I am going to say now is not the result of a formal study (which will be done in the near future), but rather a generally conservative measure of the “Project Age” dynamics, based on informal surveys. Again and again in the organisations I worked for as an external project management coach and in the workshops I have given to hundreds of project team members from all kinds of organisations, I have received the following answers when I inquired about their project-related circumstances:

• About only 1 person out of 15 (7%) works full time as a project manager
• Out of those who work full time as a project manager, only 1 out of 10 works on only 1 project at a given time (so 1 out of 150 people, less than 0,7%, manage projects work as a full time project manager on a single project)
• 149 people out of 150 (99,3%) work on many projects at the same time, only 10 of them doing only project work.
• The remaining 140 people (94%) work both on recurring operations in a traditional functional role and on many projects at the same time
• More than 75% of the people surveyed work on more that 5 projects at the same time, 20% admitting to work simultaneously on an unbelievable 10+ projects simultaneously (while doing recurrent work at the same time)
• The vast majority of those projects are multi-functional, meaning that a large part of the project team does not come from the same functional department as the project manager, hence do not report to the same functional boss
• The vast majority of people working both on projects and recurring operations have performance evaluations, on which their promotions, salary raises and bonuses depend, that do not evaluate their performances on projects and their contributions to project results (…so, what’s in those projects for them?).
• 8 persons out of 10 (80%) say that the priorities given to the projects they work on are unclear and are continuously changing for reasons unexplained to them.

….Consequently, in this added confusion of priorities and unclear management goals, the vast majority of the people surveyed admitted that, unless there is “urgent” work to do, as required by their hierarchical boss, they decide on their own which project they are going to address on a given day… and the basis of their decision is “what pleases or interests them most, on a strictly personal level”.

So what does that say about the case for Agility, and what kind of Agility are we talking about?

As I see and experience it, current organizational project environments have nothing to do with the paradigm of a world of projects run by professional project managers with dedicated teams. At best, we are talking about organisations that largely run projects in “weak matrix” mode (no full time project managers on most projects). For those organisations “being a project manager” is not a formal position on an organisation chart, but rather a role, an extra hat worn by people who have others things to do and manage than projects. Those people work in an ever changing project environment, where priorities are redefined continuously, often for legitimate but badly communicated reasons. Such an environment requires a lot of flexibility from project teams to adapt rapidly to new situations, which is basically what Agility means.

In a business context, Agility means “the capability of rapidly and efficiently adapting to changes” (3). However, in the multi-project context depicted above, Agility represents a bigger challenge than putting together processes where humans “physically” move together towards a common goal. We are talking here about humans “psychologically” moving together, aligned by a common vision, while servicing different individual interests achieved through many individual, yet coherent and congruent goals. Short to achieve that, as said Albert Einstein, no physical means will ever compensate for the confusion of goals pulling all of the project team members and whole organisations apart.

Agility is not only a must to move through the chaos of the Project Age, it has to be Agility achieved by mobilizing all stakeholders to act individually, but “as one mind” moved by a common vision, freely adhered too. All efforts of an Agile project management process have to be concentrated in achieving this alignment of individual minds and individual goals. Project stakeholders have to share a common vision and move towards a common outcome, a “individually” desired project outcome, while working on all their other required simultaneous operational and project tasks.

How can we design an Agile framework doing just that? I will offer an answer to this in my next blog entry: “Part 2- 8 principles of successful Agile projects”. I will present 8 elements that have to be put in place to succeed at agile project management.

Don’t forget to leave your comments below.

---