Project Manager Meets The Steering Committee [Glen Gage]

Situation: You, the project manager, have just been called to represent your project at the next IT Steering Committee meeting, a meeting that includes the CEO and is held once every three months.

It can be daunting to be called before a group of 'C' levels, VPs and other executives when you aren't used to it. When you are used to it it's even worse because any naive thoughts you may have had of a group making reasoned business decisions based on open dialog and fact have long since evaporated. Steering Committees are some percentage true to their charters and the other percentage a hot bed of corporate politics. The percentages vary from company to company and within companies, from month to month.

Your first thoughts upon receiving the invitation were mixed--pride and fear. Good. Appropriate. The devil on your left shoulder whispered in your ear "Don't worry, it's no big deal. You know what's going on in the project, just relax and go to the meeting. They just want to tell you what a good job you're doing." The angel on your right shoulder whispered "This is a big deal. Get prepared, thoroughly prepared."

The first thing you did right when your manager told you your presence was expected at the next IT Steering Committee meeting was to ask why. When the answer was vague (your manager isn't on the committee) you did the second right thing, you arranged a few minutes with the project's sponsor (who is on the committee) to find out why and ask a number of other questions.

The answer to 'why' might range from "Project Managers are invited randomly so that they get the experience of executive level dialog and exposure to the management team. It is all a part of our employee development program" (not likely) to "This is a critical project and not everyone feels they have a handle on it." (whoops, is your communication plan not working?) to any number of reasons. The important thing is to find out why they want you there so that once you are there you can satisfy them.

I'll tell you now that you performed well because you listened to the angel on your right shoulder and because you knew in advance not only why you were invited, but what senior executives want in general.

What do they (Executives) want in general? They want the project finished and the benefits on which it was sold accruing. You and others may want the project for the project itself, after all its your job for the moment. They don't, it's a means to an end, full stop. What they want from you: competence, in control, working to achieve the benefits for the company promised by the project (vs. the details of the project.) Be aware that they look at project managers as commodities. One PM isn't working swap another in. It can't be that hard to learn MS Project, right? I don't think this way but most of them do.

Let's look back on your performance and see why it went well...

The sponsor told you you were invited because Sales was questioning the importance of the project, especially in light of the recent three month delay. You also found out where you were in the agenda, who else would be there, what they thought of the project, how to dress, how early to show up, the fact that it would be a good idea to have a few slides to show and a hand-out, and that your sponsor was a good guy and would support you. Then you were on your own.

You prepared your message and you visualized the end result. You practiced over and over in your mind driving to work. You did a dry run with your spouse. You prepared simple materials to hand out--bullet points and pictures, the detailed information planned for verbal delivery, detailed documentation written in case you had to distribute something. You made sure your project binder was up-to-date and indexed and you brought it to the meeting.

During the meeting you kept your cool and always appeared attentive and interested, but never cock-sure. You watched the body language.

Here is what happened:

You were introduced by the chair, the CIO. You had barely started when the VP of Sales interrupted. "These damn IT projects are like the pork and barrel Congress. Full of fat and low on delivery. For example, look at functions 12.1.4.5 and 12.1.4.6, if I can navigate this requirements spec properly! Where the hell did they come from?" You wanted to say "Then why did you sign off on the requirements document, you monkey?" but you didn't. Instead, you went to your project binder, found the data, and were able to say "Those functions were proposed by Mr. Bell A. Whistle at the user workshop held in Atlanta last month. The full group approved them as items with significant business benefit but not essential for version one. The development cost was estimated as low so they were included in the User Requirements Document for version 1." Then you stopped talking. Good, you answered his question. Everyone knows the Sales VP signed off and everyone knows he was represented at the workshop.

You continued with your presentation. The delay in your project was due to a change request from Sales that took several weeks to clarify, and this was your next topic. Your sponsor had coached you on how to phrase this part of your presentation. After your brought up the delay and why, the room went nuts--finger pointing, accusations, red faces. You did your job, you stayed out of it. As project manager you need to navigate politics, but it is not your job to resolve it, certainly not at the level you saw being played out before your eyes. You soaked it all in and kept an expression that communicated interest and professional concern. In fact the argument had little to do with your project.

When the dust settled you had an action item to modify the functionality of the software slightly and the direction that if the supplier gave you a hard time you should refer them to the sponsor. You began to finish your presentation but it was clear from the expressions in the room that the reason you'd been invited had been taken care of. You asked if there were any questions. There weren't. You thanked everyone and went back to work.

End note:

This little tale had a happy ending. Sometimes it doesn't, and sometimes there isn't anything you can do about it. In my tale there is an assumption that your project was approved because the steering committee 'power field' leaned toward supporting it. Sometimes, very rarely, but in my experience, projects are approved to discredit the sponsor. If that had been the case in my tale above you would still have survived because everyone (who counts) would know why your project was crushed, and everyone would respect the fact that you kept your cool and professionalism.

-------------------------------------------------------------------

Mr. Gage is an independent consultant with extensive international and cross-industry consulting and line management experience. Getting the highly unlikely done is the hallmark of his career.

Mr. Gage teaches a variety of project management classes in partnership with Fog City Consulting. These classes count toward Personal Development Units (PDUs) with the Project Management Institute (PMI). Links to these classes can be found on his web site https://sites.google.com/site/gageinnovation

I would love to hear from you. If you found an article interesting or not, please comment. Thanks in advance!

Contact information for Mr. Gage can be found on http://www.linkedin.com/in/glengage

Article Source: http://EzineArticles.com/?expert=Glen_Gage


More...

Transparency [Rino Jose]

We say we want transparency in decision-making, transparency within our organizations...but do we really mean it?

Transparency is a Sign of Efficiency

Transparency within organizations is a good thing. It means that teams and functions are communicating freely. It's a sign that decisions are being made with more information and more scrutiny. It indicates that the organization is executing efficiently.

When problems arise in transparent organizations, people can see them immediately and from different perspectives. The organization can respond quickly to unexpected events and save valuable time. Organizational goals can be modified, and the people can quickly realign their activities.

Why Aren't Organizations More Transparent?

There are three main reasons that keep organizations from being transparent. The first is that most organizations have unintentionally developed a "culture of opacity". You can see this when people say their information needs to be filtered and controlled because others can't understand it out of context. You can also see this when people don't trust their own teams to report information. Some organizationl roles exist simply to filter and throttle information.

A second reason is that it can take a lot of effort to be transparent. There may not be an easy way to communicate what's happening or why. People may not even be able to track all of the information that's being generated by their teams, creating a kind of opacity by default. Technology, however, has advanced to the point where this should no longer be an issue. There are tools that can reduce the effort of tracking and presenting information so it's less than negligible (i.e., they actually cut the effort of what you're doing today as they provide transparency for your team).

The third main reason is that...

Transparency Requires Trust

One of the things I said about breaking a "cycle of distrust" was that someone had to go first, to make the first gesture. Transparency is a perfect example of this. We can't say we want transparency within our organizations if we ourselves are not willing to reveal how we make our own decisions. Someone must take the first step.

Why is it so hard to do this? If we feel the need to hide something, we should question that. If it's because we don't trust others in the organization, we should question that, too. Get to the root of distrust and eliminate it. If it's beyond your authority, find someone with more clout. There are always people with influence that want the organization to run well. It's likely that they aren't able to see where the problems are. Build a window into your team so they can see for themselves.

(originally posted on Management Revolution)
_________________________________________
Rino Jose is the principal co-founder of Lakeway Technologies, a startup that develops web apps for automating engineering and project management. He has developed software and managed software teams professionally for over 15 years. As a manager and management consultant, he has led turnarounds for multiple engineering teams. Rino holds a B.S. from U.C. Berkeley and a Ph.D. from the University of Pennsylvania with cross-disciplinary focus between Engineering, Computer Science, and the Wharton Business School.
More...