Skip to main content

Author: Claude Emond

What Does

Written by Claude Emond on . Posted in Articles. 4 Comments on What Does

In the last entry in her blog “Managing Product Development” , best-selling author Johanna Rothman talks about her reaction to a project manager she met, who was saying that he was “managing” seven projects simultaneously. Her reaction was that this project manager really did not manage anything; he was being kept busy doing damage control and wishing for the best for these projects. Johanna states that this project manager’s bosses just delude themselves into thinking that those projects can be managed …and also that this project manager is part of the problem, if he is not advising his bosses otherwise.

Project management is often seen as a way to increase productivity in the face of personnel reduction in organizations, mostly associated nowadays with my fellow baby-boomers taking permanent vacation. The final result is that you end up meeting, as I did, a person who works on 34 projects at the same time; a complete aberration.

I do not say that a project manager cannot manage many projects simultaneously, but there is surely a limit to splitting oneself in mind-pieces. I just feel that the overall misunderstanding of what is really a project and of what it really means to manage such an endeavour, as well as the belief you can run projects like operations by standardizing everything, causes these crazy situations.

Recurring operations deal with certainty and maintaining stability in production processes, where cause and effect relationships are very well understood. In these situations, it is easy to change anything into a transaction. Managing operations is predictable “transactional” management, where automatic behaviours are quite efficient and welcome.

However, running projects on the automatic mode, like recurring operations, can be disastrous. Projects deal with uncertainty and promoting change through an evolving process, in which cause and effect relationships are often uncovered along the way, and where you are subjected to many surprises and many divergent perceptions of what is really happening. So transactions and filling out forms won’t solve everything. You need to “converse” your way through; you have to create and manage relationships. Managing projects is hardworking and mindful “relational” management, so your effectiveness is not limited by the number of forms you can complete, but rather by the number of people you can deal with at the same time.

As a former military officer, I learned that my maximum span of direct control was around nine people. Projects are delivered through teams and most authors on the subject today say that a high-performing team cannot be more than 10 to 12 people. So how many projects can a project manager really manage simultaneously? Assuming you can delegate a lot of management/ coordination/ facilitation stuff, and that you have direct relationships with two to three people in any given project, what do you think is the right answer? Certainly not seven, and even less 34!

You can believe whatever you want about “super-project-managers.” What I see in my practice is, that once organizations reach a decent level of maturity in project management, they significantly reduce the number of projects assigned to a single project manager… because they understand what it really means to manage projects.

i http://jrothman.com/blog/mpd/2008/03/how-many-projects-are-you-managing.html

Vroom and the Capability Principle

Written by Claude Emond on . Posted in Articles. 5 Comments on Vroom and the Capability Principle

From Sharing the Project Vision to Successfully Delivering Projects

I still meet many project managers who just state that sharing a project vision (if ever there is one) is a waste of time and that the project team should just concentrate on what they are asked (told ?) to do. This always reminds me of my first project management courses, more than 30 years ago (dinosaurs were still alive), when I was told that: “the more information people have about a project, the more veto power we are giving them…so it is important to keep information sharing to the strict minimum, using as a strict yardstick of information distribution “direct-task-oriented need-to-know information.”

I am appalled to see that this primitive belief still endures today, since it shows so little understanding of how human minds and hearts really work. I am also appalled that, each time I ask about Vroom’s Expectancy Theory of Motivation i (dating back from the early 1960s) and it’s significance to project management audiences (including many PMPs), I find out that it is still mostly unheard of or, when it is known, it rings no bell about the relationship between sharing a project vision and mobilizing project teams to ensure project success. This is very unfortunate since Vroom’s simple theory:

  • Holds the explanation to most “resistance to change” situations (the 9th waste of bad project management, identified by Bodek ii)
  • Shows, subsequently, the inescapable way to individual motivation and subsequent team mobilisation
  • Tells you, consequently, how you can deliver your projects faster
  • Gives you the ultimate behaviour-influence recipe for fast, mostly resistance-free, successful project delivery

What Vroom reveals to us is what I call the “Capability Principle,” which I describe as follows:
“A person will do something only if that person is convinced that he/she is capable of accomplishing what is asked from her/him.”

So when one is asked to do a task or to accept a new situation (a “change” in project management jargon), one must first answer a firm YES to the question “Can I do this/can I function in this new situation?” before even considering the usual existential pros and cons of the WIIFM iii type. Unless one understands fully where one’s project tasks and own ultimate fate fit in a project plan and in the subsequent vision this project serves, one cannot answer a firm YES to this question. The answer will be: “I do not know enough about this stuff, I am in no position of knowing if I am really CAPABLE of doing this or stand this….so I’ll wait and see and won’t accept personal responsibility or accountability for any of this”. So the project manager, who does not clarify nor share the whole picture of a project and its underlying vision, will end up either doing this other person’s work or telling this person exactly HOW to do everything; and, in so doing, this project manager won’t we able to share accountability with the project team.

You think that sharing a project vision is a waste of time? Well, the “Capability Principle” will prove you wrong. You will experience, first-hand, massive resistance to change and unshared accountability on your projects. And you will end up being the only one, all alone, caring for this project, the perfect scapegoat for a disaster in the making?

i http://www.valuebasedmanagement.net/methods_vroom_expectancy_theory.html
ii http://www.reformingprojectmanagement.com/2007/10/09/841/
iii What’s in it for me ?

The Proximity Principle: Continuous End-User Involvement and Project Success

Written by Claude Emond on . Posted in Articles. 6 Comments on The Proximity Principle: Continuous End-User Involvement and Project Success

In my previous blog entry, I mentioned the importance of managing perceptions. I also wrote that not doing so was the main cause of why only one project out of three was considered successful by major stakeholders, according to the Standish Group’s Chaos Report 1.

So, if we have to manage perceptions, where and how should we start doing that? The Chaos Report gives us pretty good leads on that, so, I am still amazed to find in my project management workshops that not even one participant out of 100 knows about the Chaos Report, its contents and conclusions (based, by the way, on data and observations on thousands of projects).

The report identifies the involvement of end-users as number one in its top ten list of key project success factors. Yet many project managers and their sponsors still shy away from this obvious tip. On too many projects still, project managers meet, at the start of the project, some so-called representatives of these ultimate project customers to discuss rapidly THEIR operational requirements. They will not be in touch with end-users again until much later in the project, only to find a very uninformed, displeased, and distressed party in full “resistance-to-change” gear. There is then a lot of damage control to do to regain end-user trust and ensure that they will commit to materializing project benefits from the deliverables “imposed” on them.

End-users involvement must be more than that. Successful project managers have long realized that, in this changing world of ours, customers/end-users also change their mind along the way and must also understand that conditions in the project environment change for all sort of uncontrollable reasons. Both project managers and their ultimate customers must be ‘in sync’, preferably in a continuous manner, in order for the former to satisfy the latter.

Ensure with your sponsor that you get proper end-user representatives on board and keep them involved in your project as it evolves. I call that the Proximity Principle and its functioning is quite well explained by Scott Ambler in his landmark article: Agility for Executives 2. Do that and you will automatically get high quality deliverables (and highly satisfied end-users perceiving the same deliverables as you), while keeping the risks of not meeting requirements as low as possible. Do this also with all other major stakeholders and you will effectively manage perceptions and deliver successful projects over and over again.

1 www.projectsmart.co.uk/docs/chaos-report.pdf
2 http://www.ddj.com/architect/184415034?cid=Ambysoft

Not Managing Perceptions: The 10th Waste of Project Management

Written by Claude Emond on . Posted in Articles. 3 Comments on Not Managing Perceptions: The 10th Waste of Project Management

“Project Quality Management must address the management of the project and the product of the project”

(p.180, PMBOK, 3rd edition)

In an earlier blog entry, I presented the Nine Wastes of Mismanaged Projects, according to Lean Project Management gurus (Howell, Macomber, Koskela, Bobek). I said then that I saw a 10th waste adversely affecting project success: Not Managing Perceptions. Today, I will briefly explain why I believe that not managing perceptions is a major project waste, and why it has to be taken care of for our projects to be successful.

The sentence from the PMBOK quoted above is one of the most important messages on successful project management. It means that project quality, a strong indicator of project success, does not only depend on the physical characteristics of project deliverables, it also depends on HOW they were delivered. It means that a project is not only a destination, it is also a journey. It means that in matters of quality, BOTH the journey and the destination are important.

The success of a journey is really a matter of perceptions. Perception can be defined as “ an individual’s interpretation of the world and of one’s experiences, this interpretation being coloured by that person’s model of the world and past experiences.” Obviously, unless they are shared, discussed and somewhat managed, individual perceptions of what’s going on during a project will be very different. Perceptions of why we do the project, of what is important, of how well things are going, of project completeness and success, etc. will all differ. The project management community already wonders how to manage risks in the face of individual risk perceptions. But perceptions differ not only with respect to risk issues; they differ with respect to every single project issue. And all project communications can also be plagued by this important factor, or waste, since what is communicated is not the message transmitted but, rather, the message perceived.

If the perceptions of individual project stakeholders are not confronted with facts and, if these facts are not then discussed, shared and interpreted collectively, it is close to impossible to agree, among other things, on the same perception of the project journey or on the same perception of what project termination means. Hence, the stakeholders cannot agree on project quality and ultimately on project success.

In North America, according to the Standish Group1, only one out of three projects (29%) are considered to be successful by the stakeholders; individual perceptions of project success are just not aligned. Meanwhile, on the other side of the Atlantic, Britain’s Constructing Excellence program2 concludes that, of the projects subjected to the project management approach proposed, 85% are successful; this approach focuses on ensuring better integration of all stakeholders by putting together extended project teams. Are these European projects more successful because they produce better deliverables (the product or the destination of a project)? I don’t believe so! I believe this is because the Constructing Excellence program ensures that project managers also take care of the quality of the management of their projects (the journey); they get all their stakeholders together, they share, they discuss and, ultimately…. they manage perceptions.

1www.projectsmart.co.uk/docs/chaos-report.pdf
2www.constructingexcellence.org.uk/

The true why of project management

Written by Claude Emond on . Posted in Articles. 3 Comments on The true why of project management

The true “WHY” of project management: it is not about delivering on time, on cost and on specification!

I was a member of the Core Leadership Team responsible for the development of the PMI new standards released in the spring of 2006: The Standard for Portfolio Management and The Standard for Program Management. Actually, as one of the main co-authors of the portfolio standard, I had not spent much time looking at the Program standard. I was, however, receiving occasional emails on the Program Management standard development. I remember seeing an email trail including heated arguments about stating or not stating that projects had to do with generating benefits. PMI’s official position at the time was naturally coherent with the latest PMBOK version! The final word on these arguments was to include in the Program Management standard an artificial distinction between managing projects and programs, stating that (extracted from what I call the infamous Table 1.1, page 8 of the Standard for Program Management):

  • In projects, success is measured by budget, on time and products delivered to specification.
  • In programs, success is measured by Return on Investment (ROI), new capabilities, and benefit delivery

I realized what was written, too far into the development process. It was too late then to show indignation (mea culpa!). Too bad since, in my opinion, this “disctinction” is not only in the blatant contradiction of PMBOK’s own definitions of:

  • project quality – quality is about meeting requirements, not about meeting specifications; and of
  • project success – meeting or exceeding project stakeholders’ needs and expectations

It also perpetuates bad project management practices. No wonder we can’t get clear ROI from project management when we deliver stuff for the sake of stuff, while our main focus is to respect time and budget constraints. No wonder programs do not deliver expected benefits, when we don’t bother to track the benefits materialisation potential of the project deliverables associated with these programs.

Projects are not only about “What, When and How Much”. They are, first and above all, about meeting “Why” questions, about meeting expectations. And expectations are not well represented by ill-defined specifications, but rather by generating benefits for stakeholders. Last spring, during a project management workshop, where I discussed at length the real purpose of projects, one project manager told me that, after close to 30 years working on projects, he was realising for the first time that projects had to answer why questions before answering what, when and how much questions. What a revelation for him! What a shame for project management best practices!

Answering WHY questions is for me THE major issue in projects. Many project personnel would gain a lot of useful insight in this matter by reading Product Centric Project Management: The Missing Link to Business Results a very interesting article by Curt Raschke, PhD, PMP that appears in the last issue of the e-zine PM World Today (https://www.projecttimes.com/wp-content/uploads/attachments/Raschke-10-07.pdf). What he calls Product-Centric Project Management, I call Benefits-based Project Delivery, but we are really telling project managers the same thing: “Next time you start or take over a project, make sure you have a project charter. You ought to have one; if not, write one and get it approved by your stakeholders and make sure that that it includes in its first sentence: This is WHY we are undertaking this project. And make sure this WHY does not state a solution but rather the benefits anticipated from this project.

If you don’t do that, you will not only be wasting your efforts on this project, you will waste your stakeholders’ time and money and fail to meet their expectations. Do that and you will promote good project management and achieve project success by improving your customers’ ability to materialise benefits faster and more economically. And THIS is the true” WHY” of project management.

This is what I say! And you? What do you say?