Summit 7 was founded on the principle that doing things right makes it easy to do the right thing. This begins with an honest appraisal of a client's situation and commitment to solve a problem or enable opportunity for them. Will we implement systems based on requirements we didn't gather? No.
At a minimum, we'll have a phase that reviews the clients' requirements for stakeholder and change leadership validation. Many times change leaders are overlooked in requirements gathering. See, at Summit 7 our discovery is our "magic sauce" and part of this is a proprietary method for identifying change leaders. We know how to ask non-technical questions to business folks and get very good technical requirements. This isn't easy and requires a mentorship process that happens with every consultant that on boards to Summit 7. Let me give you a real world example of how Summit 7 is different:
I was working with a new consultant that called me the night before a preliminary design review. He was concerned because he couldn't complete the requirements matrix - "..there is so much bickering between the multiple IT departments that I can't get good requirements." The customer was merging departments and folks were afraid they would lose their job if they gave up control. "…their HR department would give me any requirements because they want a different system altogether...same with legal. Legal said SharePoint won't handle their compliance needs". I was able to use this experience to show this consultant why we are different. I told him to "stand up and say exactly what you just told me!" – I’ve got your back.’ (we mean that, by the way…I tell every consultant that if we get fired for standing up and telling the truth, it’s on me and NOT them).
That design review went well - but, most of the requirements that we gathered were never seen because the bulk of the conversation revolved around the cultural and political issues preventing a successful implementation. And in case you are wondering, they are still a client today. At Summit 7, we solve problems. Rarely is technology the actual problem clients are faced with. It's antiquated process, non-existent processes, people, culture, and politics. We use a basic, yet proven, methodology for implementation that is non-negotiable:
1. Discovery and Requirements Review (lots of intellectual property in this phase - we are on version 5 of our discovery methodology)
2. Preliminary Design - high level design that addresses the stakeholder and change leaders’ requirements and expectations
3. Critical Design - fleshed out design that results in the go ahead to build the system
4. Optional, Testing and Review - If this involved uX, Branding, custom code, complex 3rd party integrations, then we'll perform a test phase to validate the system is working as designed
5. Operational Readiness - this is the fun part! Unlike many implementations I've seen and heard about, this the easy part. If we've done our job until now, very little happens here that was unforeseen. I'd love to chat more about this with any potential client - just drop me an email or give me a call.
We have decades of experience and depth in building business systems that work. We are well aware of the academic or "pure" methodologies and design philosophies that are taught in higher education and often practiced by our competition. We have seen the outcome of a business system that is perfectly implemented according to classic principals and academic rigidity - it rarely meets the leadership expectations and often fails. Why? Because people are involved! Some examples that immediately come to mind are culture and politics. I've heard folks talk about why these are important but rarely get to the meat of why they matter. Let me give you some real-world examples around compliance and culture:
Let's take Executive Number 1. His name will be "Sam". Sam is the EVP of Sales for a large manufacturing corporation. As part of a compliance and ECM engagement, he states he's all for improved technology and new processes to ensure the protection of intellectual property. He also understands the requirement to comply with SOX. However, during discovery he stated he doesn't want to disrupt the current sales workflows as they are very, very busy. As the system went in place, sales and supporting staff members more and more were using My Documents (on their local drive) and Outlook to do sales work. Why weren't they following the "new and improved" processes that ensured the safekeeping of data? Because the EVP didn't like the additional steps required to use SharePoint. So - he went back to Outlook. If he doesn't use the new processes, guess who will? Yes, that's right - essentially nobody. See, this is an example of why discovering who the change leaders are and getting their buy-in is so critical important. If you get the change leaders - you'll get the change. Use caution, however. People talk all the time about "executive stakeholders" and these are often not the same people as "change leaders". In fact, many change leaders aren't even management!!! They are the "winners" - you know who they are. They win - nearly every time. Get in their way with a piece of technology or cumbersome process and they'll side-step your intuitive. I guarantee it.
Now, let's take Executive Number 2. Her name is "Sally". Sally is the head of HR for an energy company and has been tasked with a new Employee Portal. She heard that Gartner said this is critical to large enterprises that want to be leaders in the industry. However, marketing wants to take the lead on all new Web sites for the company because they believe in the modern world it falls in their pervue. So, HR has the legacy knowledge of the institution, but marketing has the knowledge of modern multi-channel distribution and social computing. If you simply pursue HR requirements and build a system, you'll likely lose the support of marketing and much of their cutting edge knowledge and ability. You'll also likely lose support from users because they'll be chatting at the water cooler about how " the HR portal doesn't work like users want it to...it's so OLD feeling, so 1990s". If you directly pursue marketing for the portal you run a high risk of alienating the very person who needs your help - Sally. Only experience and vision can overcome this situation. You'll have to be the bridge between Sally and marketing. Find common ground and build some demos - and do it quickly! HR is largely concerned with content and processes, marketing is largely concerned with bling (I mean usability and branding ;-) ). There may be a lot less overlap than you think. Start out simple, get some mockups, don't do large presentations, and use your feet/video conference to get unofficial feedback all along the way.
Last, do you ever feel like your technology consultants' solution feels a little like Forrest Gump? You know - you're never exactly sure what you're going to get? Most consulting firms do have methodologies. However, rarely do they have both the sophistication and culture to support it. I'm not terribly afraid for my competition to see my methodology. (I've presented it hundreds of times now in public...). There are, honestly, few of them that could execute it anyway. It takes more than just a set of documents and artifacts to successfully implement an enterprise technology platform. It takes training, culture, experience, leadership, judgment, and a talented supporting cast. Successful projects begin with solid scoping/pre-sales activities. Our methodology begins with the first contact with the customer. If you get a proposal from a firm and it doesn’t look like exactly what you want – stop. Trust me, you rarely get what’s on the proposal from a lot of consulting firms – do you really believe you’ll get what’s not!?
That’s enough for now. I have to get back to creating presentations for SPTechCon and SharePoint Evolutions conference in London…check out these conferences. They are two of my favorites and I rarely miss the opportunity to speak at either.