Creating Shared Vision, Part II

So - after a long period of doing other things - family vacation, training, multiple work trips, diving with sharks in Belize (it was so cool!), I finally decided that this is the afternoon I would sit down and finish this thought. If you haven't read the first part of this post - go read that first. This is the second half, where we get down to conclusions.

To review the challenge: how can 20 or 30 people of disparate and highly specialized disciplines quickly develop common vision and understanding on complex projects that no-one fully understands, and that aren't repeated?

1. Top-down "command and control" [often] doesn't work, because frequently if the leadership has the vision for what the final outcome will be (and they don't always), they almost always lack the deep technical expertise to deploy/build each part. IT projects are often very, very complicated and technical.
2. Bottom-up is too slow, because each person approaches the problem from a completely different viewpoint, because of their different areas of responsibility, and it's not possible for everyone to learn everything. . . . . and this is where the endless meetings come in.
3. Organic learning effects don't work, because most IT projects are one-offs, where that project with those technologies and team members will probably never happen again (I'm primarily talking about infrastructure projects, here).

So. .. . . how can IT groups quickly agree on the why, what, and how? (PMO can figure out the when, usually)

I think the answer is to find a reference model outside the organization. Unless you are Google, chances are someone else has done a similar project before. Better yet - find someone who has done a similar project many, many times, and who has deep expertise in each domain, but also sufficient scope to not only be able to explain each part, but also how they all go together.

Let's go back to the theoretical group trying to consolidate many smaller IT departments (part 1). 

• Security has their concerns, and doesn't understand the other pieces
• The virtualization, storage, and networking folks have pet peeves and issues they want to ensure get addressed.
• The VP often knows what's wrong with the current, and maybe what needs to be done to fix it, but may not be able to articulate a feasible technical solution that can accomplish that.
• The finance folks are worried, and I have to admit they often have reason to be.
• The VP of X is annoyed because project Y is being postponed until after this one.

What if (and I'm just totally spit-balling here!), we were able to take each of these groups, and expose them to deep-domain expertise in their field, and each department came back 8 hours later with an overview of the larger project and goals, and actionable specifics around their part in it? What would that be worth in terms of saved time, stress, endless meetings, conflict, waste, and compromises resulting in sub-optimal outcomes? What would that be worth to YOU as a leader, to have a team that identifies itself as productive, and effective, rather than what IT often gets labeled with? 

That's one of the value propositions of a portfolio of solutions, and companies. Rather than having security figuring out how to integrate a disparate solution with a backup technology built by another vendor, and a highly specialized storage widget made for a completely independent use case - what if all these solutions were designed with each other in mind, and with a single vision? What if there were products (and expertise) in each category that all "snapped" together to accomplish the task? Essentially - what if you could task thousands and thousands of people to develop an integrated solution before you needed it?

That's what I love to see come out of a really well-run engagement with customers. Ideally, after an executive briefing (we often have a joint session, and then break-outs by discipline) their VPs are satisfied that the team understands not only where they want to end up, but also each piece of how they will get there. The individual disciplines have gotten to beat up on (it's OK) and ask questions of experts who understand how all the pieces fit together, but also speak the [security|storage|analytics|development] language, and understand the pain and criticality of the field.

Essentially, I believe an engagement with a vendor should be about only a few key things:

A. How are you going to help me compete for and keep my customers, and my job? (If you don't understand that YOU as an individual have customers, and don't believe that you need to compete for your customers, we need to talk. There is no such thing as a captive customer base anymore. Your competitors are gleefully extending the lead if you are standing still)

B. What is the vision your product(s) were developed around, and how complete is that vision?

C. How can you help me rapidly and quickly deliver on the answers to question #1? (hint: shared vision)

Because of my tenure and because I enjoy it, I often get called in to talk with people who are either:

Painfully aware of point A, and actively looking for an answer to point C, 

OR:

people who are unaware of point A, and believe the "new" and "best" thing for [storage|networking|analytics|development] is going to cure cancer and solve world hunger [at least for their department]. There will always be companies willing to agree ("it's transformational!"), and sell them that "thing." 

So - this is why I am resolved to always, always, always start with "what are we really trying to do to help you compete?"   Unless I forget, am having a bad day, or have been brought in half-way through. 

In which case. . . . . would you do everyone a favor, and ask us? 

"What is the EMC+Pivotal+VMware+RSA+VCE vision for helping me compete for my customers?"

(And - btw - give all your vendors/partners an opportunity to answer that question!)