I love this topics and I agree with many of the points that Pawel made. I would like to contribute the following:

Turning “Pro” to me means reaching the point in our careers when you can still feel successful, even when you end up delivering a failed project.

I believe this requires 3 things:

(1) Unlearning what we have been taught, since the beginning of our careers, as the definition of a successful project manager.
(2) Separating the definition of our success as individuals from that of our project’s outcome.
(3) Having the capacity to detach ourselves, as much as possible, from the outcome of the project (whether it is success or failure).

(1) We all grew up with the iron triangle. It has been drilled into our psyches from the day we took our first Project Management course. We have been taught that a successful project manager always brings projects on time, on budget, and on scope. This definition actually sets us up to fail, even when we succeed because as we know it is impossible for some projects to meet this definition of success. The good news is that the iron triangle is dead. PMI, after 50 years, has killed the iron triangle in its latest PMBOK edition. So we should too.

(2) We need to learn to separate the definition of our success as individuals from that of our project’s outcome. After many successes and failures, we eventually learn that there is a thousand reasons why a project can fail. And if we try hard, we can always find a way to link each and every reason to something we as project managers did or failed to do.

But blaming ourselves is actually not useful as it misdiagnoses the problem and ignores the fact that projects live and die in organizational ecosystems. And these ecosystems, more than the Project Manager’s actions or inactions, will determine which projects will success and which will fail.

Every day, we are tasked to lead…
• Projects that are started for the wrong reasons. They are never supposed to be started in the first place because they are not aligned with the organization’s strategy
• Projects that start out as a good idea but then the organization’s priorities change
• Projects that start out as a good idea and remain a priority but they represent a threat to a faction within the organization and they do everything they can to derail them.
• Projects that are a good idea, remain a priority, everyone supports them but the organization does not have the capacity to deliver them successfully. This could be due to lack of skill or high workload.

In most organization, the project manager does not have the luxury to say “No”.

I am not saying that as PMs we don’t have our own contributions to this ecosystem and to the outcome of project, but there are forces that impact the project that are far and beyond what we individually can control. I wrote in "Sometimes failure is an option" that “When projects fail, we need to take responsibility but only for our own contributions to the outcome. We should not shoulder the responsibilities of others or for conditions outside of our control.” (Rest of the article here: http://bit.ly/d8fJ5u)

We simply have to accept the fact that a percentage of our projects will fail and they should fail. And when they do, how we interpret and re-frame that failure will determine how quickly we will bounce back. If we are not careful, the stories we tell ourselves can start chipping away at our confidence in our capabilities, self-esteem, and overall mental and emotional health.

(3) Acquiring the capacity to detach ourselves, as much as possible, from the outcome of our projects will actually help us to be more successful. When we are so attached to the outcome of the project, there is a danger that our egos will get in the way. We can fall in love with our projects and fail to see all the dimensions of the situation. We can get suckered into pushing the wrong initiative and carrying someone else’s water. When our egos are in the way, we can start acting defensively and miss the opportunity to exercise true leadership and do the right thing. And doing the right thing sometimes means pulling the plug on a losing proposition. We have to be O.K with that.

Gosh, I thought we had put this issue to bed years ago!

There are two dimensions to project success: product success and project management success:
-- Boeing 777: successful in both dimensions
-- FBI Terrorist DB: unsuccessful in both dimensions
-- Sydney Opera House: poorly managed project that resulted in a successful product
-- FoxTrax: well-managed project that produced an unsuccessful product

Each dimension must be supported by documented and agreed success criteria that are maintained using good change control practices. PM is responsible for meeting PM success criteria and for ensuring that project decisions do not adversely affect the product success criteria.

More here: http://www.pmpartners.com/resources/defmeas_suc...

Duncan
William R. Duncan, Project Management Partners
Director of Certification for asapm
Primary author of the original version of “A Guide to the Project Management Body of Knowledge”

What you compare here is product success and project management success. Actually product (Sydney Opera) can be extremely successful but id doesn't mean project was considered as a success (I guess people cried over budget and time overruns). I can give you another example - there were 6 stadiums build from a scratch for Euro 2004. A tournament was huge success. Now, 6 years later it is discussed whether two of stadiums should be bulldozed because there are no teams which play there and would be able to fill the seats. Is it success or not? And how it relates to product (stadium itself), project (building a stadium) and project management (supervising building process)?

Anyway a discussion may not be new but there are still people who see strong bond between those two, so I wouldn't say the answer is clear.

Agreeing to Bill's comment.

Our airport (DIA) was a budget buster and schedule disaster. 10 years later no one cares. It broke even 3 years after opening and has been a huge revenue generator for Denver ever since.

This whole notion of defining success or failure in the absence of the stakeholders units of measures is pretty much a waste of time.

Hence the complete non-value for reports like Standish. The jury is still out on 787, general light rail in most cities, and energy independence of solar, wind, and now our current focus - algae based syn fuel sources for coal fired power plant augmentation - via DOE's ARRA funds.

My point exactly. Product success and project management success are INDEPENDENT variables. You cannot evaluate one based on the other. You can be successful in one dimension without being successful in the other. I do believe that well-managed projects are more likely to produce successful products (the Opera House is mostly an aberration), but the PM has to be aware of what product success is, and has to do everything possible to ensure product success.

Interesting post, and the answer is dependent on the culture of the organization. Personally, I believe team building and company atmosphere are more important than a couple of days on the calendar. Of course, there are times when financial penalties come with contracted dates, so those do take precedence.
Overall, it comes down to the tone set by executive management. I've worked in companies where deadlines are the only dates that matter. Others promote employee culture and development. I personally choose the latter.

Bill,

this depends on the launch date - launch of the spacecraft, "go live" of the ERP system, launch of the product roll out.

A couple of days MUST be in the schedule margin. In fact the amount of needed schedule margin MUST be known by the project and tracked to assure some notion of "on time" is possible. In the absence of this of course the project is going to be late.

A deadline without margin = failure. Those execs you worked for set you up for failure before you even started.

If you prompt employee culture and development in the absence of "delivering on or before a planned date, with an agreed on level of confidence," you're creating the environment for failure on the other side of the table - the failure to deliver the promised value to the stakeholders.

Now they may be ill informed and poorly managed stakeholders, but they are the stakeholders all the same.

Its a very interesting discussion Pawel. When we look at the project management books we learn that a project is only successful if its delivered in full scope, time and cost, a day or dollar makes it unsuccesful. Authors see it as a binary thing either successful or unsuccessful, but I personally feel a projects result can be somewhere in between.

If a project has taken more days its ok to say that its not 100% successful but if it delivers something to the company it cant be pronouced as 100% failure as well.

I would say that we need to calculate projects success and project managers effectiveness by determining how much of the objective has been achieved. If its completed on time and cost but doesnot give its intended benefits the company has all the right to humiliate the project manager.

Laura,

Success must be measured in units meaningful to the stakeholder.
This is why reports like Standish are nonsense. There is no standard measure of success. It is equally nonsense to talk about project success in the absence of a specific domain and specific units of measure. Because there is no shared basis of discussion.

What may appear as failure in one domain, for the same project in another would be success. The units of measure can rarely be normalized. Only in the PM classroom ndo such things have any value.

Remember Yogi Berra's quote (famous US baseball player and coach) - "In theory there is no difference between theory and practice. In Practice there is."

The point I haven't discussed in the post, and now I see I should have done it, is how project management relates to benefits company gains as project outcome. Is it project manager's responsibility to define goals which benefit the company? If not, why should they be blamed for wrong project goals?

Anyway I fully agree there isn't such thing as 100% success or 100% failure. In extreme example few bucks (literally) of budget overrun won't be a problem for anyone. $1000 can be a problem in small projects, $100k in bigger ones etc. It all depends on a background, but the more issues you bring to the table (i.e. time and budget overruns, lack of project benefits) the less successful and the more failed the project will be considered.

The question is: how does it relate to success or failure of project managers themselves? And I believe that is a very individual question and we can hardly can find any rule we could use as an answer.

I don't believe it's the project manager's responsibility to create business strategy; it IS his or her job to stay within it, and to remind sponsors if they stray outside of their company's objectives because the project could fail to give the customer what it really wants because the company doesn't have the resources to comply with its expectations.

I see it as a process. At the beginning some goal is born in the head of one of stakeholders. Then it is processed by project manager. Then it is transferred into design document or feature or something. Then it is developed, verified and deployed. On each of these stages there can be communication failure i.e. project manager who doesn't really understand what stakeholder is really talking about or why this or that is one of the main project goals. Then the issue should probably be addressed to project manager.

However the problem as I see it here is different. If the goal in the first place (in the stakeholder's head) is flawed PM won't help no matter how hard she tries.

This part of the process is really out of PMs control. The rest is, or should be, more or less controlled so if the problem source appears during later stages of the process it is, to some point, problem of project manager.

Pawel,

This position is highly domain specific.

The misbehaviors of IT projects is simply breathtaking at times. Having the customer cut the schedule in half and not adjust the deliverables is anecdotal but would be strictly forbidden in any defense, energy, construction, or other contractually based project.

I know it happens in internal IT projects, but it is complete nonsense.

Would I sacrifice good atmosphere and team chemistry just to finish a couple of projects more on time? Explain to the public that everyone on the Orion Manned Space flight program is "happy and self actualized" but we're late and over budget, with the publics money.

To borrow a quote from Lance Armstrong

The pain of the project's difficulties are finite, the taste of failure lasts a life time.

Glen,

I have a few questions. Take one of these highly-formalized projects you're familiar with. Possibly the one which makes it really hard to cut features out (e.g. one of these flight systems you work on). I guess some of these projects are late. Is this always PM's fault? Or project team's fault? Have you ever worked on one of these project where at the end of the day it appeared it was underestimated in the first place or because of lack of knowledge you had wrong goals or client insisted on some features/deadlines which were added nothing but unnecessary work to the project?

Note: I don't try to convince you here to anything, I just try to learn how you assess these situations in your world.

A discussion about achieving project success at cost of ruining atmosphere we had before. The only thing I'd add this is not black or white kind of situation. Would you ruin one's private life (i.e. requesting him to work overtime while you know he has serious problems in his private life) in sake of making project a success? Would you burn half of the team out (and let them go soon after) in a single project if that was what it took to complete on time?

Yes, these questions don't have universal and definite answers. It all depends. If the project was going to save mankind no one would think about them for a second. But for another IT project?

And yes, these questions are on the same axis as those about making workplace less miserable or helping people to grow.

Pawel,

The projects we work have features cut and added nearly every rolling wave (iteration). Many are R&D projects or at least "experiments." So the formality is mostly are cost and schedule.

There is no need to place the projects we work on the extreme. Building aircraft, power plants, or installing world wide communication systems is not "saving mankind."

As well they are most times late and over budget - it's simply the nature of projects.

I would answer the question "Would you sacrifice good atmosphere and team chemistry just to finish a couple of projects more on time?" If that is the Only choice - YES. projects are finite. No successful project, it's irrelevant how good your team was - it got canceled. That's just as extreme a position as if I had answered NO to the question.

Now we need some units of measure here - missing in many discussions of almost anything.

What does it mean to have good atmosphere? Every one is "happy," we provide really cool ping pong tables for the developers. Or the majority of the team shares in the outcome of the project and works appropriately toward that goal and is rewarding accordingly.

In the end why do you consider it a black or white choice? Seems like you're setting up a red herring here. Why can't the project manager and the team hold each accountable for a shared outcome - Kotter's definition of a team. Doing this does not mean every is happy.

Project work requires many trade offs, but the project is "king" in any successful project world. Otherwise the PM's career as a PM will be short lived. Projects are not self actualizing processes, they are ventures that hopefully return value to the investor - be it the government or the bowling league president for the wed site.

I will conjecture this is one of the core problems with internal IT projects - having worked those types of project for several decades. There is no "team" in the sense of Kotter - "A group of individuals who hold each other mutually accountable for a shared outcome." rarely is there a shared outcome, and rarely do people hold each other mutually accountable.

The domain in which we work - mission critical, be it power generation to manned space flight - the mutually accountable attribute is the starting point.

The shared goal changes all the time. If it didn't change, the work effort would be called PRODUCTION. And even then goals change - just look to Toyota

I am far from trying to make everyone in the world happy. I believe every manager, project manager included, has to play asshole from time to time. And yes, it is a trade-off game - let people play table football half a day and they will be happier but I bet productivity won't skyrocket.

Having said that I've seen people burned out simply because no one really care whether they still catch up and at what cost. The project was the king. In the long run organization lost since it was pretty hard to replace these people.

The problem here is you can't really measure atmosphere or happiness. Yes, they try to do these fancy surveys. "I'm happy 7 out of 10." What the hell does it mean? And if you can't measure it you must use your knowledge/experience/gut feeling/whatever and make your own, well-weighted call each time. That's how I look at it.

Very interesting post Pawel, thank you! I'm interested to see what comments others have on this topic.

I wanted to point out that the definition of project success should be in terms of value delivered to the key stakeholders including the customer and end users.

If your schedule gets cut in half, and you make it on time and budget, did the functionality and quality of the product become so compromised that the end user fails to adopt it? Or worse, they are forced to adopt it but it's actually a step backwards from their previous situation.

I know I've seen some "successful" projects that failed to deliver any value and even took value away, especially in call center environments.

In these cases, it's our responsibility as project managers to be painfully clear to all of the key stakeholders if we feel the ROI of the project has been significantly compromised, or if we see that the end result will actually not be beneficial to the organization.

This is an interesting aspect of the problem. If PM delivers what they were asked to (i.e. according to specs) but the project doesn't bring value to stakeholders is that still failure of PM or it rather should be addressed to stakeholders?

I mean how should PM know whether requirements they get are the right ones? Is it project manager's responsibility to verify whether stakeholders provide proper priorities?

In other words have you worked on a project when you knew the outcome would be a failure but stakeholders insisted on keeping the course? And how have you acted then?

I guess this discussion leads to the way we see the role of project management in general. Personally I see PM as an executor of others' goals. This means the key responsibility I see is for execution, not for goals themselves.

Anyway I don't claim this is one and only approach. Depending on a team role of PM may vary much.

I think it's a shared responsibility, but as a PM I try to focus on my responsibility. Our project environments differ; in mine the PM is very much responsible for the goals and broader picture; not just execution.

I know that some shops have a structure where requirements are developed separately and then thrown over the fence to a project team.

I wouldn't last long in such an environment, because it's too important to me that the project team and manager be responsible for delivering value. The "project" is secondary.

If we had crappy requirements, I view it as my fault for not communicating effectively with the customer and key stakeholders. We should have done a better job eliciting quality requirements.

Ideally, the PM should have an eye on what value is being delivered to the organization. As a PM I have raised red flags before to say to the sponsor "you know, this project is not going to be able to deliver the business value we originally intended. We should kill it." - and back that up with data.

It doesn't mean they always listen to me. I have completed "successful" projects before that delivered no value and just accrued costs. These were "pet projects" sponsored by executives and I told them to their face that the project had no chance of improving anything.

If they look you in the eye and say they don't care, sometimes you just have to march like a good soldier to keep your job. It's really tough to stay motivated when you know your efforts will yield jack squat though.

It wasn't long before I moved on to greener pastures.

I guess it does matter how we define "crappy" and "quality" requirements. I can think of a number of projects where project manager just couldn't assess business value of any specific requirement. The only thing which she could have done was verifying whether the requirement makes sense in general and whether it is coherent with others.

This way you can define a "quality" requirement (makes sense and is coherent with the rest) which at the same time is "crappy" (doesn't bring any business value).

Besides small projects where project managers often fulfill a couple of other role, responsibility for business side of the project goes to product management (Product Owner, product manager, business owner, you name it).

If you as a project manager fail to communicate effectively with stakeholders it is your fault. But if stakeholder fails to define valuable goal at the beginning, good communication won't help. The goal will be clearly communicated, will make sense and business-wise will still be crappy.

Yeah, it goes back to what role the PM is allowed to have in specific environments, and also what the individual PM asserts their role to be.

Even in large projects though, the lead PM, chief engineer, lead scientist, etc. can and should have the responsibility of convincing the customer/key stakeholders to do what's in their own best interest.

As a PM, I want to understand what positive impacts the project will have. Knowledge of that inspires the team (and me) and shows that they aren't just writing code for the sake of it. Tying it to value is powerful, especially when you can talk about how they are helping other people or taking part in something bigger than themselves.

As a PM I want to have as broad picture as possible. This helps my on many fronts. Assessing risks, motivating team or communication with stakeholders are just a few examples from the top of my head.

And I often speak up when I believe business goals are wrong, but I don't try to keep my position in this discussion by all means. I understand there are people (salespeople, marketing folks, product managers, client representatives) who know far better then PM what are the business goals of the project. I understand there may be, and often there are, hidden goals which no one ever articulates loudly. I just accept the fact project manager isn't the most knowledgeable person in this area.

I agree PM should try to learn as much as possible about business background because it definitely helps. I just don't think it is project management responsibility when project launches with flawed business goals.

Pawel,

No business goal is WRONG. The business goals may be inappropriate. This is where the disconnect starts. The PM has no better understanding of the business goals than the business people.

The PM's role is to bring to light the validity of those goals for clarification and verification. If the business leaders say that's their goal, who are you to disagree. It's their money - and billions have been wasted in commercial domains because of this. But in the end it's still their money.

Call it as you wish but inconsistent, inappropriate or contradictory project goals are wrong. If the project goal is to land a man on the moon next week the goal is wrong.

I agree PM role is to validate goals, but don't forbid them to challenge goals, especially when they know much of a business background. After all business people can sustain their position since they are decision-makers.

The point where I strongly disagree is that business people spend their own money. They don't. Starting with governments which spend our money and ending with every big corporation where decisions are made by middle management, not co-owners or shareholders. And I don't fool myself all these people try to choose the best option for the organization they work at.

When you come with money-saving project and all you hear is "That's not in my bonus schema" you're disillusioned. Of course if you had any illusion in the first place.