A: A typical IT strategy does not require the CEO's hands-on involvement. However, an IT strategy, at the end of the day, truly serves only the corporate strategy.

Ultimately, there is really only one true strategic player in the organization: the CEO and his or her counterparts on the board. All the other officers of the corporation must use their respective departments to help the CEO execute the company's strategy. Most business units align their activities to the corporate strategy and similarly, IT must wrap its strategy around the business's.

Therefore, by all means, share your finding with the CEO to demonstrate that your department is supporting the corporate strategy. Most CEOs care about dominating a market or increasing sales and not necessarily whether or not you have a deployment plan for any product. So the last thing you really want is a non-technical person being very influential with an IT strategy that they don't understand.

A: It is because SharePoint is a platform. It can be difficult to define the functionality that has or could have been deployed to the business, so the milestones/endpoints are different than those for a typical application such as a CRM system.

Also for a SharePoint strategy to become a deployment reality, there are several dependent technologies that SharePoint relies on, which need to be in place and set up correctly for the initiatives to work. For example, user profile synchronization needs to be configured appropriately with Active Directory in order for the organization chart in My Sites to work.

An application is like Microsoft Word, a program that is very clearly defined for the single purpose of writing documentation. As stated many times in this book, SharePoint is a platform for web applications to be developed on.

This is why SharePoint can be difficult to define and describe to people. Another term you will hear is that it is the Swiss Army knife of Microsoft's web offerings, because the tool has many blades.

Microsoft will often explain SharePoint with the pin wheel, which is illustrated as follows:

Given SharePoint's broad functionality and its potential to be used by any employee in an organization, defining a strategy can be a challenge. This is unlike a Customer Relationship application where generally only the sales and marketing departments are involved and processes are already defined.

Another reason why defining a SharePoint strategy is unique is because employees may have had an experience with SharePoint at a previous job, and want to repeat this experience again. What they often do not realize is that their previous experience may have consisted of a customized SharePoint environment, or one augmented with third-party components. These employees end up surprised and disappointed when their expectations don't comply with the current deployment.

It is essential to educate the user community about SharePoint if you really want to leverage it's functionality. It is important to gauge the level of interest and time that business users have and are willing to spend on SharePoint awareness.

A: The biggest pitfall would be to neglect involvement of the business in forming an IT business strategy.

If IT attempts to create its own "strategy" centered on technology, there will be a problem. A division between IT and the rest of the organization will increase as most other business units have aligned their activities to the corporate strategy.

It's a bit like the used car salesman trying to peddle the high-margin two-seater sports car on the lot, despite the fact that the customer explicitly mentions a wife, three kids, and the 80-pound family dog. The salesperson may have a deep mastery of the technical and aesthetic attributes of the sports car, but his "strategy" is at odds with the customer, no matter how knowledgeable he is about the product or how it could be applied to the customer's problem.

As a technologist and business person, you can avoid these pitfalls by marrying technologies with the corporate strategy and keeping in mind that a successfully executed strategic objective is more important than the tools used to get there. Yes, this may mean that .NET development may have to wait. This mindset adds a healthy dose of pragmatism to IT and aligns IT with the rest of the organization and brings a results-oriented focus to IT.

Rather than cooking up ROI numbers, or attempting to assign a "business benefit" to the cost of sending a single e-mail, this mindset puts IT in the business strategy and produces or enables business results and can be seen as a true business partner.

Thus you can begin to see that business involvement is crucial for validation of goal, approach, and partnership during the development and go-live phases. Once the business is involved, you can set a path for success and most of the remaining pitfalls can be avoided with effective project management.

Planning pitfalls may include aspects such as failing to schedule well-defined project milestones. Specific to IT planning, having the right skill sets in place is critical. This is where experience and up-to-date training will pay dividends. Take time to identify gaps in knowledge or experience. As long as the void in skills is identified, you can plan around it with a combination of training and outsourcing. Otherwise, you risk embarking on a very expensive training exercise and possible project failure.

"Scope creep" is another common pitfall when dealing with IT projects. It's common to come up with additional ideas on how IT technology can be applied. The challenge will be to decide how to track and accommodate requests for changes in scope. As project budgets and timelines are established at the beginning of the project, it is important to incorporate a methodology on how to respond to scope changes up front as well.

Knowing how to say no or when to push back is a great trait to avoid this pitfall. Having too rich a functional goal mixed with a delivery timeline that is too ambitious will set you up for falling far short of expectations. By keeping business values top of your mind, you will be able to make the right trade-off in this area.

Another common pitfall with an IT strategy is failing to properly accommodate for dependencies. These dependencies vary from needed resources (hardware, personnel) to availability of system interaction (parallel IT projects, test data, migration windows of opportunity, and so on). As is the case with skill sets, take time at the commencement of the project and strategic milestones to check your dependencies and have a contingency plan where needed. Of course this does not help when a five-year strategy is at the mercy of the yearly budget review.

Adoption is also often overlooked while considering IT business strategy because it is easy for IT personnel to neglect adoption. This is because they will undoubtedly know more on how to use the system or application because they built it and they may fall in love with their own project while forgetting to put themselves in the shoes of the end user and business management. IT adoption can be aided with a mix of proper training, evangelizing, and desire to understand the business.

Lastly, it is important to remember that an IT business strategy is more of a journey than a destination. Just as business needs evolve, the technology that we can apply to aiding the business seems to evolve even quicker. With this in mind, your knowledge of the IT world should always be growing and your methodologies should constantly be refreshed.

A: In short, the strategy will help prioritize IT efforts to support the business requests. The key aspect of an IT strategy is to manage expectations of both the business and IT department so that both parties know what to expect and when.

In the first figure of the chapter, there is a clear roadmap of SharePoint deliverables for the business so budgets can be defined and resources allocated. The details of how this is done do not necessarily need to be agreed upon in the strategy meeting. In fact, given that the budget is not defined at the workshop, some initiatives may not be feasible.

By having an IT strategy for SharePoint, return on investment can be identified with some effort and initiatives being approved and prioritized.

Without a strategy, there is normally a passive approach to a SharePoint deployment, where initiatives are not coordinated among departments and low value processes are used with SharePoint, such as fancier and more expensive set of shared drives rather than a usable ECM system with findable information assets.

Research by AIIM stated that half of SharePoint implementations proceed without a clear business case (which shows lack of direction from the start); only 22 percent of the organizations provide users with any guidance on corporate classification and use of content types and columns; one third of the organizations have no plans as to how to use SharePoint, while one fourth of the organizations say IT is driving it with no input from information management professionals.