4 Expert Insights

"While my experience in working relationship one-on-one is excellent, it becomes really difficult to manage conflicting priorities when the size of the team pushes 4 or so members." Yes, welcome to the world of herding cats -- and IT cats are the hardest to herd!

So let me suggest that you consider the level of support you NEED from each person on your key issues by using the following  continuum:

I need them to LET it happen » » » » » I need them to HELP it happen » » » » » I need them to MAKE it happen.

Then, using the same continuum, consider the level of support you CURRENTLY HAVE from each person on those key issues.

Less confident/practiced IT project managers tend to spend most of their time with the people who are already giving them as much, if not more, support than they need for a given issue and not enough time with the people from whom they need more support than they currently have.

You can substantively increase your impact and influence, without having to engage your executive sponsors in the minutiae, by focusing your attention on those who's support you currently NEED > CURRENTLY HAVE. Then, the conversations with your executive sponsors can focus, instead, on more meaningful updates and progress reports and maximizing executive-level support and visibility for the initiatives under your charge.

I'm happy to talk through some ways the make this happen for you, if you'd like.

Consensus is great if you can afford the time to get it.

Getting consensus doesn’t always mean convincing everyone to go with your idea. It might mean compromise.
It does mean making sure everybody feels their input has been heard and that the merits of their plan or objections to your plan have been understood. At some point, delaying the decision in order to get consensus causes excessive problems (cost, revenue, or customer service for example) and you need to make the decision & execute without getting consensus. (If you do that too often, you may be accused of crying wolf.) In that case, it’s important to clearly let everybody know their input has been heard, a decision has been made, and it is time to execute. I work with several companies who have a value called “Disagree & Commit.” They want disagreement before a decision is made to insure they get the input required to make the best decision. Once a decision has been made, they say disagreeing time is over and it’s time to commit to the decision.
Knowing when to call for the decision rather than continue to have dialog to get consensus is an art. Doing it too soon can fail to get the support & alignment needed for successful execution. Doing it too late can cause you to miss the window of opportunity.

A. no consensus is not a practical goal
B. don't try to 'drive' consensus with peers. They won't appreciate it, since they are at your level not 'below' you.
C. if you're seeking a more collaborative environment then lead by questions. Ask them in a group setting how to solve the challenges you're facing. Be the question guy, not the answer guy.  When they work together to solve the problem of how to function better as an ad hoc team, then you will have accomplished several things. The first is your problem is solved and didn't have to be solved by you. The second thing is you will already have built a foundation for working together which will translate further down the road. The third is that any solution the group collectively comes up with will be organically congruent with the group which makes it easier to sustain.
D. this doesn't have to take much time at all.

Frankly, I believe that getting consensus and a common understanding of the project and the goal is extremely important to the success of your team.  Best of all, it doesn't take 'that' much time.  My experience when called upon to work with a team such as you describe is that taking this time on the front end is a time saver in the long run.  The consensus I refer to is bringing about the following:
1. A shared understanding of the vision you are working to achieve
2. the reasons that those on the team have been asked  to be on the team.  i.e. what is the skill(s) that each one brings to that table and why the project requires that capability
3. the shared understanding as to why each voice represented is absolutely necessary to hit the desired mark

I have encountered several reasons for resistance that may be a part of the group.  Most often there is an element of ignorance as to why this or that person is there when "I know the answers he/she would provide".  Launching the team effort by bringing all together and educating builds more respect for the team and the project.

If you have questions pertaining to this please don't hesitate to contact me