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 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.
Here 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.
1. The 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 and have actions in place and 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 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 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 appraise 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 is, there was no emergency. We had already planned for the equipment, budgeted it, and it was already on order and would arrive on-time (because we ordered it early). 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 problems 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.
2. Thriving 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 are 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 needed to be fixed. Ad hoc meetings were being called hourly, but 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 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, but 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 seems 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.
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 when we delivered on-time with quality.
Managers, even very senior managers, may possibly 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 you tailor how you communicate with your senior management team.
Filed Under Change Management, Communication | Leave a Comment
Tagged With Change Management, Communication, Project Management, Project Management Tools
Comments
Leave a Reply
