Author: Claude Emond

The 10 Key Project Management Success Factors… Minus Nine

WOW! So many people coming to my blog this month! Looking for the elusive recipe, aren’t you? I’ll give it to you, but before, let me settle scores with ‘Listmania’, a type of illness that prevents project managers and other stakeholders from thinking straight.
I noticed while looking at my blog entries that the ones with numbers in the title, promising ‘lists’ of questions, answers, laws, principles, success factors, failure factors, etc… were the most read. I also noticed it was the same for my co-bloggers here. So the list of the three most read blog entries on Projecttimes.com is as follows:

10 Ways to Use Requirements to Melt an Executive’s Brain        2752

Twenty Ideas du jour for the Practicing Project Manager             1616

Project Risk Management in 12 Questions                                862

So, what does it say about us as project managers? It says that we like quick fixes. It says that we like recipes. It says that we might have lost our capacity to think straight and that we rely on others to tell us what to do on OUR projects.

I am very untrusting of any list that has not been subjected to proper cause and effect analysis, and most of the lists that one can find have not been given the ‘Ishikawa’ treatment. So what is offered are lists of items that are rarely mutually exclusive. Consequently, we might end up working very hard on things that are symptoms or effects rather than root causes, which means working for nothing.

For many years, I have presented in my workshops the 10 Project Success Factors list from the Chaos Report (www.projectsmart.co.uk/docs/chaosreport.pdf) as the best thing that ever hit the world since the invention of the wheel. Here it is for those who came here driven by the title of this blog entry:

The 10 Project Success Factors

(Chaos Report, version 1995….for they changed over the years, as any list of factors like that will)

  1. User Involvement -15.9%
  2. Executive Management Support -13.9%
  3. Clear Statement of Requirements -13.0%
  4. Proper Planning – 9.6%
  5. Realistic Expectations – 8.2%
  6. Smaller Project Milestones -7.7%
  7. Competent Staff -7.2%
  8. Ownership – 5.3%
  9. Clear Vision & Objectives – 2.9%
  10. Hard-Working, Focused Staff – 2.4%

The % at the end of each item shows the percent of persons (out of 365 respondents based on their collective experience on more than 8000 IT projects) who listed this item as a success factor. According to this list, the No 1 factor is User Involvement …so let’s act on it ‘Pareto style’.

What’s wrong with this approach is that it assumes that there is no causal relationship between these elements, which is a false assumption. As I look now at it ‘Ishikawa style’, the No.1 is No. 9 in the list: Clear Vision and Objectives….and, really, it is the No.1 of all lists claiming to uncover the key success factors of project management. Here how it really works. If we do not have No. 9 (‘clear’ meaning that all stakeholders see, understand and share the same vision and the same objectives), it will be impossible to:

  • respectively or simultaneously get 3, 8, 2, 1 and 7;
  • agree on 5, 4 and 6; and
  • have 10 and succeed

So, I would suggest that project managers and other stakeholders forget about all those lists for now and concentrate on the one single ingredient common to the success of all projects: clear and shared common vision and objectives. This is the one project success factor ‘list’ that is universal and that I propose to follow. The remaining items are contextual and will vary from one project to another, so be prepared to do some analysis on your project to make it a success.

No list will ever give you the recipe for success if no one is working on the same project. So start there and build, together with the other stakeholders, the list of things that you ought to do on THIS project to meet your common vision and objectives.

Don’t forget to leave your comments below.

An Agile Framework – Part 3- Four Agile Project Management Techniques.

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

Albert Einstein

This blog entry is Part 3 of a 5-part series laying out the elements of an Agile framework. It presents 4 techniques generally included in Agile methodologies, and discusses which of the 8 principles presented in Part 2 are usually implemented through them. I will try to explain why some of those techniques do not work sometimes, as well as why it is paramount to apply all of the 8 principles of Agile for Agile techniques to really succeed.

4 Agile project management techniques and why they sometimes fail

There are many techniques associated with what we call today Agile project management. I singled out 4 of those techniques that seem to be used in most projects, namely:

  1. Dynamic planning, also referred to as “rolling wave planning” [1]
  2. Timeboxing [2]
  3. Scrum [3]
  4. Deliverables evolution curves, usually known as “burndown or burnup charts”, “velocity charts” or “percent of promises completed curves”, “PPC curves” for short [4]

The purpose here is not to explain the exact mechanics of those techniques, but rather relate the way those techniques are usually applied with respect to the 8 principles of Agile covered in Part 2. For more information on each of those techniques, you can read the documents referred to in the footnotes.

Claude_Emond_Table_1

Table 1, above, is a summary of my own observations on how many organizations use those 4 techniques. The techniques are often used quite blindly like “recipes”, often with very rigid parameters to respect. I was amazed to have an argument on very specific parameters with the person responsible for the implementation of Agile (for this person, meaning implementing “Timeboxing” and “Scrum”) in a very large organisation where most projects are IT related. I was preparing a conference for them on Agile project management; I intended to give some examples for “Timeboxing” periods and for the duration of a “Scrum”. I was asked to send my presentation material beforehand for validation; I was then told that according to their guidelines a “Timebox” should not be longer than 15 days and that a “Scrum” had to last 10 minutes… and asked to modify my presentation accordingly. I understood then that their implementation of those techniques had nothing to do with the 8 principles of Agile, but rather, sadly, with the search for a universal recipe to solve their need for organizational agility. Best practices promoted by recipes are the antithesis of agility.

The observations summarized in Table 1 need to be scientifically challenged by proper surveys. I believe, however, that they are representative of many implementations of Agile techniques. Many organizations try to perpetuate a work environment valuing “control” (for most the status quo) rather than to adapt to a very turbulent and changing work environment through new values like “collaboration”, “team work” and “collective accountability”. By doing so, they defeat the purpose of the Agile approach they are trying to implement. They fight to keep the status quo, while Agile tells them to accept change and manage it.

The “Theory of Constraints” and the rationale for integrating the missing Agile Principles to current implementations of Agile methodologies

“Timeboxing” and “Scrum”, at least as named, are Agile techniques that originate from the world of Software development. “Dynamic planning” and “Tracking deliverables/tangible promises” with “PPC curves” are associated to both the software development world and the world of Lean Construction Management, as promoted by the Lean Construction Institute. However, making sure those promises are done by the individuals delivering them is linked to the “Last Planner”™ principle [5], a principle not generally espoused and presented by software development specialists writing books on Agile. Lean construction project management also promotes, as a must, “integrated project teams” [6].

The 8 principles of Agile I promote are a mix between principles applied in Agile software development projects and those applied in Lean construction projects. Beside the “Last Planner” and the “Integrated Team” principles, there is another element we can find in Lean construction management books and articles, that is not often discussed in Agile software development literature. This element explains:

  • why the “Last Planner” and the “Integrated Team” principles are essential; and
  • why we need to include 2 more principles to succeed in our projects, the “Capability” and the “Desirability” principles.

I am talking here about integrating Goldratt’s “Theory of Constraints” in managing projects. Lean construction proposes managing around the constraint and elevating it as required [7].

In my series “Velocity” [8], I proposed that all projects are about making change. I proposed that the constraint, in any endeavour involving change, had to do with human resources, not with material or economic resources. I identified this constraint as the “capacity and will” to change, which justifies the need to include all stakeholders and ensure that they can and want to implement change. In this context, Goldratt’s “Theory of Constraints” is the approach that calls for the application of the 4 principles often missing in Agile techniques implemented in most software development projects. There is no doubt that, by adhering to Goldratt’s constraint management approach, software development projects will become really agile and get better results. I believe that, by applying the 8 principles of Agile, projects in any venue will be more satisfying for all stakeholders concerned and thus more successful.

Those 8 principles are congruent with a whole set of beliefs and values, that we could call an “Agile philosophy”. Part 4 of this series, my next blog entry, will present the 4 values and 6 beliefs that are the foundations of this “Agile philosophy”, values and beliefs that call for all of the 8 principles of Agile to make projects really work.

 Don’t forget to leave your comments below.


[1]  “Last Planner” is a Trademark of the Lean Construction Institute (www.leanconstruction.org)

 [2]  For an discussion of “integrated project teams” see my blog entry at http://www.projecttimes.com/claude-emond/the-rules-of-lean-project-management-part-3.html

[3]  A presentation of the Theory of Constraints is included in my blog entry http://www.projecttimes.com/claude-emond/velocity-part-3-five-basic-steps-to-effective-constraint-management.html and its references

[4] See my blog entries on http://www.projecttimes.com/claude-emond with “Velocity” in the title

[5] You will find more information on what is “Rolling wave planning” and how it works in my blog entry http://www.projecttimes.com/claude-emond/the-rules-of-lean-project-management-part-5.html and its references

[6] You will find more information on what is «Timeboxing» and how it works in the Wikipedia article http://en.wikipedia.org/wiki/Timeboxing and its references

[7] You will find more information on what is «Scrum» and how it works in the Wikipedia article http://en.wikipedia.org/wiki/Scrum_(development) and its references

[8] You will find more information on what are «Deliverables evolution curves» and how they work in my blog entry http://www.projecttimes.com/claude-emond/the-rules-of-lean-project-management-part-2.html , its references as well as in the following article: http://strategicppm.wordpress.com/2010/11/25/the-value-of-burndown-charts/

An Agile Framework Part 2 – 8 Principles of Successful Agile Projects

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

This blog entry contents Part 2 of a 5-part series laying out the elements of an Agile framework. It presents 8 elements that have to be put into place to succeed at Agile project management.

In Part 1, I described the prevailing organisational context of our current turbulent business environment, then used this as my basis to explain what the word “Agile” really means, and what it implies for organizations and people managing projects in 2011. My conclusion was that Agility is a must to move through the chaos of the Project Age. However the Agility to be achieved implies mobilizing all project stakeholders to act individually, but “as one mind” moved by a common vision, freely adhered too. This can only be done by putting into place an Agile framework aiming at aligning individual minds and individual goals to share a common vision and move towards a common outcome for any given project… all that while evolving in a very complex “multitask working environment”. This Agility is achievable not through alignment of actions only but, first and foremost, through alignment of individual interests; without this alignment of individual interests, alignment of actions is just not achievable.

Managing a project is like rafting on turbulent waters, together in one boat, towards an approximate destination

To help participants in my workshops understand the nature of projects, I use the analogy of a collective journey, very comparable to the journey of a family travelling together on a boat towards a collectively desired vacation destination; if it is not collectively desired, neither the journey, nor the destination will be pleasurable. Each family member has agreed personally to get into this boat and to do their share for both the success of this journey and arrival to the desired destination.

To simulate better our current turbulent business environment, the boat I talk about cannot be the usual long boat that is often used to illustrate “teamwork” in motivational posters. In such “poster” vision of teamwork, the turbulent environment in which organizations  evolve nowadays is surely not very well represented by the calm water on which the long boat travels. The notion of teamwork alluded to in this poster has also nothing to do with real organisational life; all the team members (except the project manager who decide of the rhythm of the rowing…and does not do his/her part of the rowing) row in unison at the command of their leader. We can also see that the rowers have their back to the desired destination; apparently, in such a team, team members do not need to know where they are going; they just have to row as they are told to.

The image of “teamwork” represented by this long boat could not be farther from reality in a project environment. I propose instead, as a “boat analogy” for teamwork, the image of rafters rowing together (among other things) on very turbulent waters. In order to make such a journey a success, people who are in the raft:

  • have agreed to be part of this “project” (they have many other things they could do instead in their multitask working environment, maybe things more pleasurable if not less risky)…they share a common purpose because they have something in return;
  • understand exactly what is expected from them (which part of the raft they are responsible for) and have the skills to do so… they have clear roles and responsibilities, as well as the knowledge and skills to carry them out, and they feel INDIVIDUALLY responsible for their actions;
  • are quite autonomous in their action, as they must not wait for an order to take action when they see a rock or a big wave coming towards their part of the raft… they know where they fit globally, but they plan locally their own actions;
  • take seriously their role in the raft, as they know that if they fail, they will sink with the boat… they feel personally responsible for what they have to do;
  • understand that they must help each other, because if one of them does not succeed to alleviate an obstacle, everyone will sink… there is a sense of interdependency (an attribute of any TRUE team) and, as a team, they feel COLLECTIVELY accountable for the success of the journey; and finally
  • understand that both the itinerary as well as the final destination will have to be revised along the way… they will be agile and adapt to new circumstances to ensure both a pleasant journey and a desirable outcome.

Those conditions of success are the same as those reflected in the 8 principles of the Agile framework I propose below. Those principles are not new and are discussed in whole or in part in many of the books on Agile/Lean project management that have been written; however, they have not necessarily been presented as principles that MUST be applied to achieve project success consistently.

In order to achieve the required alignment of individual interests, the Agile framework that has to be put into place has to reach at least two goals:

  • get project stakeholders to feel INDIVIDUALLY responsible for the work they have to contribute to the project, while knowing they are part of a team of interdependent individuals feeling COLLECTIVELY accountable for the success of both the project outcome and the journey towards its destination;
  • create conditions and mechanisms to ensure that everyone of the project stakeholders see, understand and want the same journey and the same outcome, thus have the same perception of what is going on and of what is changing, as the project and its environment evolve through time.

5 of the 8 principles aim at building individual responsibility and collective accountability, while the other 3 aim at creating an environment where project evolution is tracked and shared collectively

5 principles to build individual responsibility and collective accountability

Most of the following 5 principles have been presented in some of my previous blog entries in Project Times. While I will give a brief description of each of them here, I will refer to previous blog entries for further details, whenever they exist. For those not discussed in previous material, I will give more details in my future blog entries if required, right after I finish my 5-part series on this Agile framework.

In order to build individual responsibility and collective accountability, the following 5 principles have to be applied to project work:

  1. The “Last Planner® Principle [1]. The person who has to execute the work is also the person who will plan it. Often, the most important Last Planner is the end-user of the project final deliverables, yet we fail to properly include this stakeholder on the project team. [2]
  1. The “Capability Principle[3]. Everyone working on a project must have sufficient
  • information about the project to be able to share the project vision and feel interconnected with other team members, as being a very important part of a very important whole;
  • knowledge and skills to deliver what is expected from him/her;
  • material resources and relevant support to deliver what is expected; as well as
  • time to apply the level of effort required to deliver successfully.

If those conditions are not met, this person will not readily accept responsibility to deliver what is expected; he/she can even refuse to do it directly or through stalling the work.

  1. The “Desirability Principle“. Individual interests won’t be aligned with the project:
  • if the fact of working on a given project does not result in some kind of reward for the person who does the work (the “What’s in it for me?”); and
  • if this reward is not proportional to the effort to be consented to deliver the work (the “Is-it worth it?”).

So, if the individual interests of a team member are not taken care of, this person is likely to work on something else more rewarding than on your project.

I have not specifically covered this principle in a previous blog entry, although I have alluded to it many times already in my ongoing series on “Velocity”. This principle appears quite self-evident to me, particularly in a “multitask working environment”. I might expand on it later. Meanwhile, I refer you to web entries on Vroom Expectancy Theory of Motivation; there’s a lot to learn from Dr. Vroom in order to build a real project team.

  1. The “Tracking Small Individual Promises Principle[4]. Project deliverables are divided in small “observable” promises, over very short time periods: for example, once a week and broken into deliverables having an effort level of 80 or less man-hours. Those promises are those of each individual team member, not those made for them by their bosses or the project manager.
  1. The “Integrated Team Principle[5]. You have to expand the “traditional” project team to include and integrate all significant stakeholders as part of this team as early as possible. Among others, this is a mean of recognizing the interdependency that connects all project stakeholders and of developing COLLECTIVE accountability.

3 principles to create and maintain a «shared» project environment

As for the principles discussed above, I will give a brief description of each of the 3 principles that support the creation and maintenance of a “shared” project environment, and I will refer to previous blog entries for further details, whenever they exist.

What one should try to achieve through the use of these principles is to align perceptions. I believe that one of the main causes of project failure is that project stakeholders do not have the same perceptions of what a given project is about, of what is its current status, as well of how it has changed and is evolving. Managing a project means managing perceptions; failing to do so is a major mistake and will result in project failure.[6] In order to put into place a “shared” project environment, the following 3 principles have to be applied to project work:

  1. The “Proximity Principle“.[7] The project client, the sponsor, the suppliers, the contractors, the project specialists, the end-users are not only part of the integrated project team; they receive continuous feedback about what is going on. Every project change is communicated and feedback on it is sought to ensure a common understanding. No single stakeholder should be kept out of the loop.
  1. The “No Surprises Principle“. This principle is a supporting principle to ensure that we have real proximity (supports the “Proximity Principle”). Ultimately this principle is used to eliminate as much as possible surprises to any stakeholder when project changes take place. The longer the time between the change event and its disclosure, the bigger the sense of surprise… and the bigger the feeling of having been kept in the dark and out of the loop. By eliminating “big surprise” effects, stakeholders will be more into an “adaptation” mode to normal frequent project changes (the fabric of being agile) than into a «resistance» mode towards changes that they did not see coming.
  1. The “Accelerated Benefits Principle“. The faster you can get benefits out of the project – which means DURING the project journey, not only at the end of the project – the better it is. After all, we are in turbulent waters and not sure where we will end up, so why not reap benefits while we can. If fact, if there is one principle that is always associated with Agile Project Management, this is this one, as illustrated by the purpose of the timeboxing and scrum techniques that are the foundations of most Agile methodologies. Clear, observable benefits, tangible project deliverables along the way are one of the most effective ways to ensure stakeholders see the same project evolution, since sharing a concrete deliverable and its meaning is easier than sharing ideas and intangible benefits.

I must add that the benefits we are talking about here are not only the ones measured in terms of the official project outcomes, they also are benefits associated with meeting the individual interests of the team members; failure to deliver such benefits will work against the «Desirability Principle» and will put both the project journey and its destination in jeopardy.

So those are the 8 principles underlying an effective Agile framework, as I see them:

  • The Last Planner Principle
  • The Capability Principle
  • The Desirability Principle
  • The Tracking Small Individual Promises Principle
  • The Integrated Team Principle
  • The Proximity Principle
  • The No Surprises Principle
  • The Accelerated Benefits Principle

In my next blog, I will present the 4 most used Agile project management techniques. I will cover their use in relation with the 8 principles discussed today. I will explain how we can improve both the effectiveness and efficiency of those techniques through applying all 8 principles to them.

Don’t forget to leave your comments below.


[1] The expression “Last Planner” is a registered Trademark of the Lean Construction Institute:  www.leanconstruction.org

[2] For more details on the Last Planner Principle and how it works, you can read my blog entry: The Rules of Lean Project Management as I see them. http://www.projecttimes.com/claude-emond/the-rules-of-lean-project-management-as-i-see-them.html

[3] For more details one the Capability Principle and how it works, you can read my blog entry: Vroom and the Capability Principle. http://www.projecttimes.com/claude-emond/vroom-and-the-capability-principle.html

[4] For more details on the Tracking Small Individual Promises Principle and how it works, you can read my blog entry: The Rules of Lean Project Management: Part 2.  http://www.projecttimes.com/claude-emond/the-rules-of-lean-project-management-part-2.html

[5] For more details on the Integrated Team Principle and how it works, you can read my blog entry: The Rules of Lean Project Management: Part 3. http://www.projecttimes.com/claude-emond/the-rules-of-lean-project-management-part-3.html

[6] For more on managing perceptions, you can read my blog entry: Not Managing Perceptions- The 10th Waste of Project Management. http://www.projecttimes.com/claude-emond/not-managing-perceptions-the-10th-waste-of-project-management.html

[7] For more details on the Proximity Principle and how it works, you can read my blog entry: The Proximity Principle: Continuous End-User Involvement and Project Success. http://www.projecttimes.com/claude-emond/the-proximity-principle-continuous-end-user-involvement-and-project-success.html

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 1st 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.


 

(1) Hugues Bouchard’s profile on Linkedin : http://www.linkedin.com/profile/view?id=57639824

(2) Meet STAN, TED and HAL – Introducing the three main classes of processes used by successful «Project Age» organizations. https://www.projecttimes.com/wp-content/uploads/attachments/PAVM.pdf

Surviving the Project Age

An «Agile Framework»!

I have been asked lately to explain the main principles to follow to ensure that Agility is achieved in projects. The requests came from two different sources:

  • a French Engineering school (http://www.cesi.fr/) that is designing a simulation game using Agile project management principles and tools; and
  • the director of the PMO of a large banking institution, who invited me to give a conference to 130+ IT project managers on the prerequisites necessary to successfully apply Agile techniques (namely, Timeboxing and Scrum) to their projects.

I have already written many entries in this blog about Lean and Agile (which I consider as pursuing the same intent), namely a series on the rules of Lean Project Management. I mixed many things in those entries, talking indiscriminately about principles, values, beliefs, techniques and tools. I had to do better to address what was requested from me. I ended up with material discussing:

  • a set of Agile principles; then
  • the impact of those principles on tools and techniques mainly associated with the Agile/Lean approach; and finally,
  • those principles as originating from a set of values and beliefs that I called the «Agile Philosophy»

I did that by mixing and integrating concepts, principles, techniques and tools that were coming from many types of projects, namely Lean Construction, Agile Software Development and New Product Development projects. Based on the comments and reactions I got from people I met while answering to the two requests, it seems that what I presented was quite a new contribution. It is only then that I understood that what I was talking about was not written as such anywhere. I also understood that it seemed to answer satisfactorily to many questions that people had about Lean/Agile. I was told it offered a very simple «Agile Framework» to understand and successfully achieve agility not only in projects, but in most organizational activities. So, I decided that it was time for me to document more formally what I had presented and to share this with a larger audience; and I wish to first do that in Project Times.

I will start, with my next blog entry, a new mini-series presenting this «Agile Framework». It will include 5 parts:

  • Part 1-The Project Age and the case for Agility. This will discuss the context of realising projects in today’s turbulent environment and why Agility has become a must for most projects.
  • Part 2- 8 principles of successful Agile projects. This will present 8 elements that have to be put in place to succeed at agile project management.
  • Part 3- 4 Agile project management techniques. This will present 4 techniques generally included in Agile methodologies, and which of the 8 principles are implemented through them
  • Part 4- 4 values and 6 beliefs of Agile. This will present and revisit the set of values and beliefs found in the Agile Manifesto and the Declaration of Interdependence, the cornerstones of the «Agile Philosophy», and what such a philosophy, if adopted, means for project management, organisations and Society as a whole.
  • Part 5- The Agile Organisation: A case study. This will present the characteristics of the Agile Organisation using a real life example: one of my client organisations that adopted the «Agile Philosophy».

Stay tuned!      

Don’t forget to leave your comments below.