Home » Change Management » A Successful Manager But Never A Successful Project?

In Does Anyone Care If Your Project Is On Time? I point out that some successful managers, line managers – not just project managers, may have never experienced a successful project. A few days after I originally wrote this article, I came across an on-line discussion by some senior managers that just illustrated this surprising situation so well.

It started out by one manager saying he had not had an unsuccessful project in ten years. The second individual, someone who had risen to a VP position and above, expressed great skepticism over such a claim. The skeptic went as far as to suggest the individual with 10 years of success may be a liar.

Skeptical that projects can be consistently successfulHere are a few excerpts from the clearly successful but skeptical senior manager:

Indications of success: “Over the last 25 years I’ve held most all positions in the IT and Service-delivery industry: programmer to analyst to PM to director to VP to Partner.”

Indications of skepticism: “I’m finding it hard to accept the guy above who stated his company has never had a failed project in ten years! Truly astonishing! I’d say he’s lying but I don’t know for sure and I’d hate to come across as accusatory. But let’s say it is true, in that case all I can say is that he and/or his company are not taking enough measured business development risks to evolve the company.”

Don’t get me wrong. I don’t know if this particular person has this history or not. It is only that his comments match well the typical things I’ve heard said in the course of major projects.

These kind of senior managers are often skeptical of anyone who talks about delivering projects on time and with quality. In their mind, it just doesn’t really happen. It is always all talk, and then the project comes in late and over budget. Typically, in the places these senior managers experienced their rise, many projects were not successful and the ones that were being called “successful” used dubious definitions of success, on time, and quality. These now senior managers have every reason to be skeptical.

I’ve also had several bosses who had said similar things to me when I kept meeting my deadlines. This was in organizations where typically projects did not meet their milestones. I was told that I must not be trying very hard nor taking enough risks. I asked one boss how often I should miss my milestones. He hesitated, and then said “never.”

These kind of senior managers can be difficult to have as sponsors or stakeholders. As strange as it sounds, I believe it is partly because, deep down, they don’t want a project to be too successful. Why not? Because they are expert at managing and thriving in an environment where things don’t go well.

Huh? Thriving in an environment where things don’t go well?

Yes.

The skills of the existing senior managers, the ones who have survived so far, are based upon working well in bad situations. In fact, they may like bad situations. It is good for them. Didn’t they get to where they are now because of them? Keep in mind that they might not see it this way.

Here are two real world examples, both of which I experienced directly. They illustrate how some managers learn to thrive on failure and where too much project success actually causes them problems.

Running all over putting out emergenciesThe Fire Fighter

He was a great problem solver. If there was a problem he would jump in and go after it full force. He was known to show up and take over meetings with a list of actions folks needed to take. He “saved” the organization on numerous occasions. He was a great guy both as a worker and as a person. We had full confidence that things were well in hand, as good as anyone could do it, when he was on top of it. He loved what he did.

I messed him up. Big time. You see, I took the Information Technology (IT) department and got them out of jumping from crisis to crisis. That is not quite right. I got them to take charge and proactively run things rather than working from crisis to crisis. Instead of constant crisis, we now had an IT plan agreed on by all our customers. We had an approved budget that covered five years. We had a process, driven by the IT plan embedded in a database, that was spitting out the incremental actions required on a day to day basis. It was humming along nicely. We just somehow forgot to inform “Fire Fighter.”

We were in a meeting with our stakeholders to apprise them on our progress and to get their feedback. Suddenly, no kidding, Fire Fighter breaks into the room and breathlessly outlines a major security problem with our classified network upgrade. He had already contacted our higher headquarters to alert them that action was going to be needed. He had just gotten off the phone with the budget folks and found some incremental funds to cover the shortfall. He had contacted the organization who had the specialized and rare security hardware and gotten them to allocate some emergency spares to meet our need. Everyone around the room tuned in to the emergency and were ready to do their part. They had done this many times before.

The problem was, there was no emergency. We had already planned for the equipment and budgeted for it. It was already on order and would arrive on time (because we ordered it on time). This we outlined to the group. Fire Fighter just kind of deflated. Everyone around the table relaxed.

Outside the meeting, Fire Fighter came up to me looking a bit sheepish. After a moment he said very simply: “I don’t know how to help when things are planned like this. What do I do?” Now, he was not an IT guy. He was our organization’s Security Chief. He just did a lot more than security. I told him the rest of the organization had plenty of challenges that will continue to need his special attention. He also agreed, in the future, to first give me a call before declaring an IT emergency.

Fire Fighter thrived on the emergency. The organization had rewarded and regularly promoted him for his efforts. He needed emergencies.


Thriving on finding and fixing buggy softwareThriving On Defective Software

After two years, we had not only cleaned up the backlog of software defects but had delivered just about all the new software enhancements that had been requested by our customers. Everyone should be happy, yes? Well, not really. I couldn’t quite put my finger on what was still wrong. Relations between departments (e.g., development, configuration management, test, administration and customer management) remained a bit rocky. Sure, while we were making changes people will often be unhappy but once things are working well everyone should be content again.

Chance would have it that my boss needed me to go and review a major contract effort that was not going well. I would be out of the office for several weeks and generally out of touch with my software development team. Things had been going along fine so I didn’t see much risk with this. After several weeks I returned to what looked like utter chaos.

Everyone was running around. We had this defect and that problem and they all needed to be fixed now.  Ad hoc meetings were being called hourly. Everyone was pumped up and moving. The test team was excited — they had found the issues. The configuration management team was excited — they were waiting to rush the changes into a product build. Heck, my boss was excited, and it was his organization (my organization) that was the source of the defects!

Groan. Obviously I had done a pretty lousy job. I’m gone for a few weeks and everything falls apart. I had been feeling pretty good about what we had accomplished. Obviously it was not near good enough.

Or was it?

It seems that we did indeed have a few software problems. Not many, but they were clearly visible and reproducible by many people. My investigation showed that my developers had gone a bit light on the process while I was gone. It seemed that the other departments, and possibly my boss, had encouraged them to deliver some software “real fast.” What was remarkable to me, however, was everyone working so happily together as things got bad.

I came to understand that this organization had thrived, for years, on buggy software. Finding a software defect, by anyone, was a badge of honor. I even noticed that many non-development people spoke of it as “their” software when it had fixes in it of problems they had reported.

My boss later admitted that he liked it better when no one could find defects. However, it was clear he had been having a blast running my team and dealing with all the issues. This organization was expert at the process of finding and fixing defects. They worked together best when there were numerous defects to be found. It was boring, or so it seemed to many, when we delivered quality software.

Compare with Successful Projects Are Boring

Some managers, even very senior managers, may never have experienced consistently delivering projects on time and with quality. This may in-turn make it hard for them to support project initiatives in an appropriate way. Having this insight, that successful senior managers may have little practical experience with successful projects, can help us tailor how we communicate initiatives with our senior management team.

How experienced is your organization and management with successful projects?

Thank you for sharing!

23 thoughts on “A Successful Manager But Never A Successful Project?

  1. Pingback: Don’t Be A Man
  2. Bruce Benson says:

    Brett,

    Disgruntled by success? They sometimes are when the success is in spite of them:
    http://pmtoolsthatwork.com/leap-to-exceptional-shorter-than-we-think/

    Victim of your success: Agreed. My solution:
    http://pmtoolsthatwork.com/successful-projects-are-boring/

    Regards,

    Bruce

  3. Brett Ossman says:

    I haven’t seen that management is disgruntled by success, more that it is ignored or you are, because they are putting out fires everywhere else.

    You are almost a victim of your success, because you are not on the radar. Problems are on the radar.

  4. Survivor says:

    Great article!
    I used to believe senior managers were supposed to go play golf on Wednesday afternoons, since their people and processes where humming along nicely. There was no crises. Where did I lost the plot?

    1. Bruce Benson says:

      Survivor,

      Aah, the days where senior management is suppose to work at a strategic arms length and stay out of the day to day activities is long gone. I’ve had VPs in a Fortune 50 company give me the status of individual software defects (and they had upwards to 2000 software engineers working for them!). This was to show that they were “engaged” with the work being done. It would have been better if they worked on a strategy that helped us avoid making promises we couldn’t keep.

      I think it is telling that folks like Warren Buffet do not have their days taken up by meetings (the same was true for the head person at Vanguard Investments if I recall correctly). I knew senior Air Force officers who would play golf together – during the day – regularly, because that is when they would talk big issues and strategy. My commander would ask us what issues we thought he should bring up to the general – not at the staff meeting, but during Golf!

      I suspect we need more senior managers playing golf. It would be a good measure of how well they were running the company.

      Thanks

      Bruce

Comments are closed.