Nội dung

www.it-ebooks.info For your convenience Apress has placed some of the front matter material after the index. Please use the Bookmarks and Contents at a Glance links to access them. www.it-ebooks.info Contents at a Glance Contents..................................................................................................................vii Foreword ................................................................................................................ xv About the Authors.................................................................................................. xvi About the Technical Reviewer .............................................................................. xvii Acknowledgments ............................................................................................... xviii Introduction ........................................................................................................... xix ■ Chapter 1: Preparing for Successful Outcomes ...................................................1 ■ Chapter 2: Introduction to Mind Mapping..........................................................21 ■ Chapter 3: The Magic of Metadata .....................................................................49 ■ Chapter 4: Site Navigation and Structure ..........................................................75 ■ Chapter 5: Wireframing for SharePoint..............................................................93 ■ Chapter 6: Complexity, Wickedness, and Dialogue Mapping...........................113 ■ Chapter 7: Business Process Mapping ............................................................127 ■ Chapter 8: The Art of Creating Business Process Solutions ............................143 ■ Chapter 9: Success with Search ......................................................................165 ■ Chapter 10: Governance, Adoption, and Training ............................................189 ■ Chapter 11: Practicing and Testing in the Cloud .............................................209 ■ Chapter 12: Conclusion: Putting It All Together...............................................225 Index.....................................................................................................................237 v www.it-ebooks.info Introduction Practical SharePoint 2010 Information Architecture is not just for people whose job title is “information architect.” It is also for business analysts, project managers, IT managers, or business managers who have been tasked with delivering a SharePoint 2010 solution. If you are thinking of reading this, I want to make sure you have picked the right book for the right reasons. This is ultimately a practical book based on what I have learned in the practice of delivering successful SharePoint projects. This book is not going to be a deep dive into the theories of taxonomy and ontology. If you are a library science graduate, you will not find anything here to stretch your understanding of those subjects. It is also not a deep look into user experience and usability. Finally, it is not meant to be a reference book, with hundreds of SharePoint facts and features you can look up. What I am hoping is that you will find this to be more of a handbook: One that you can read fairly quickly that is full of practices you can learn rapidly and then apply to your next project. I did not include a ton of SharePoint screenshots here, because this book is less focused on detailed SharePoint features than it is on preparing the way for a great SharePoint deployment. The reason I wrote this book is that over the past five years, I have discovered a small collection of tools and techniques that are quite easy to learn and have made a huge difference in the way I was able to communicate with my stakeholders. I have found that these tools can make a major difference to the chances a delivering a successful project. The methods and software I describe are all centered on the concept of using visual abstractions that can be employed interactively during meetings and workshops with stakeholders. I have especially focused on tools that work well in these types of interactive sessions. It is true that if you plug your computer into a projector, almost any software could be used interactively; you could just project a Word document on the screen as you take notes, but that would not be as powerful as the mind mapping, wireframing, and process mapping tools explained in this book. The products I use amplify shared understanding through their use. As I will explain, getting to a shared understanding is the most important factor in getting to a successful result. I have used these tools and techniques on projects that employ SharePoint for public-facing web sites, for team collaboration, for application development and integration, and for corporate portals, but my experience is that they are most directly applicable to the development of corporate portals that include a web-content management tier for sharing information widely throughout the organization and a collaboration tier that facilitates teams who work together on a day-to-day basis. I have been speaking about these tools and techniques for the past four years at conferences around the world, and I often hear from attendees who tell me that they have applied what I have shown them and found it to be incredibly helpful for them. I hope you will find what you learn here useful for your projects. Point of View of the Author I am writing this book from the point of view of someone responsible for SharePoint projects at a high level. I am a consultant who uses the titles business analyst (BA) and information architect (IA; more on that in a minute). I am involved in projects from the beginning to the end, helping to define what the stakeholders’ goals are and what the scope and budget for the project should be. I am intimately xix www.it-ebooks.info ■ INTRODUCTION involved in designing the site structure, navigation, and taxonomy. I work closely with the project manager, the architect who leads the development and deployment effort, and the infrastructure architect who specifies the hardware and installs and configures SharePoint. I am involved in the branding process, working with the designer to ensure that the design complements the goals and vision for the project. I provide oversight to the teams who do training, governance planning, and communications planning. I then consider it my responsibility to be the representative of the customer during development, deployment, and migration, to ensure that the original vision I helped to define is what gets delivered to the customer. My point of view for this book is of a person doing the job I have just described. I am assuming that you own all or part of this process, and the tools I describe and techniques I explain are meant to help you accomplish all of this successfully. Naming the Players In this book, I will variously use the terms customer, stakeholder, team member, and user. When I say customer, I am referring to the people you are building the solution for. It can be an external client if you are a consultant, or it could be your company as a whole or another department within your organization. When you are working on a SharePoint project, the people you work most closely with to design and implement the solution are the SharePoint team, and they may include people from within the customer team as well as team members from other departments or a consulting firm. Another type of customer is the end user (or better, information worker or knowledge worker) who does not necessarily have a say in what was developed. All these groups from users through senior executives together make up the stakeholders in the overall project and the delivered solution. What Is an Information Architect? What is my actual job? I don't have a great name for it, and neither does anyone else. I sometimes used to call myself a business analyst. One definition of that job, from the International Institute of Business Analysis (www.iiba.org) is: A business analyst works as a liaison among stakeholders to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements, and recommends solutions that enable the organization to achieve its goals. Okay, that does cover quite a lot of what I do, but my job is a bit more specific than that because I work specifically on SharePoint projects. Also, I do more than “recommend” solutions; I design and build stuff as well. But I'm also not entirely happy with the definition of information architecture from the Information Architecture Institute (iainstitute.org), who defines information architecture as: 1. The structural design of shared information environments. 2. The art and science of organizing and labeling web sites, intranets, online communities, and software to support usability and findability. 3. An emerging community of practice focused on bringing principles of design and architecture to the digital landscape. Well, I do a bunch of that, but it's more too. I hesitate with this title partly because it seems that most jobs that I see for IAs are more focused on the design aspects, meaning the artistic use of color, font, and layout, which, to me, leans more in the direction of usability and user experience design. xx www.it-ebooks.info ■ INTRODUCTION So, with all that, I'm not really sure exactly what an information architect is, but I had to pick a title, so 70 percent of the time I say I am an information architect and about 30 percent of the time I say I am a business analyst. This is my definition of what I do as an IA: I work with stakeholders to understand their business and the issues they are having concerning information creation, sharing, processing, and management. We work together to achieve a shared understanding of the problems we are going to try to solve and then we collaborate on navigation, content taxonomies, and workflows that facilitate information sharing and findability. I know this sounds pretty pretentious, but I decided to call this book Practical SharePoint 2010 Information Architecture because it covers the work of an IA as I have just defined it. Why Is SharePoint So Hard? You wouldn't start building a house without a blueprint. But what would you do if you're not really clear on the concept of what a “house” is? The blueprint only makes sense to someone who understands what it represents. What may surprise you is that a lot of people are sold on the concept of SharePoint as a relatively low-cost, easy to implement solution that will solve a bunch of business problems with very little work. The actual truth is that most organizations who agree to buy SharePoint don’t really know what it is. Part of the problem is that no one can sum up in one sentence what SharePoint is or what it does. Many have tried, but SharePoint is unlike other Microsoft server products like Exchange (e-mail) or SQLServer (database), or IIS (web). These products can be thought of as if they were picture puzzles: They are not easy to put together, but you know ahead of time what the result will look like when you’re done, and you have a pretty good template to guide you. SharePoint is more like a huge set of Lego blocks with no instructions: If you open a container of Lego and ask “What do I do with this?” the only answer is “What do you want to do with it?” Lego lets your imagination run free; it can be used to build almost anything. For some people that freedom is liberating, for others it can be frightening. SharePoint is a platform with a broad and powerful set of tools that requires careful planning, architecture, implementation, and maintenance to make it useful to a business. The past ten years of SharePoint implementation have often been of the “Ready, Fire! Aim” variety, resulting in implementations that don't deliver the magical results that were expected. In the past few years, we have started to see a groundswell of new writing and presentations about governance and other concepts, many of which have become buzzwords, that attempt to address these issues. The reason for this rapid “buzzwordification” of SharePoint planning and governance concepts is that a lot of people see the potential for the SharePoint platform, but they don't want to invest the resources (time and money) required to get the full value. What they are really looking for are shortcuts via a collection of so-called best practices that will do the job for them. The problem with SharePoint is that in addition to it being an inherently powerful and complicated system, the people who buy it and implement it often don’t have a clear picture of the business problems they are trying to solve. You can’t just dump the Lego container out on the floor, stick a random bunch of pieces together, and say “Wow; that looks great.” This book will show you how you can apply visual tools that will help you to clarify the scoping and planning, as well as build the structures and processes you will need to implement your SharePoint projects. Planning your SharePoint deployment is a complex, multistep process involving multiple groups of stakeholders. In many cases, the stakeholders are not exactly sure what SharePoint does or how it works, so you, as the information architect (or business analyst, or project manager), must help them articulate their pain points and design a solution that will meet their needs. Because of this lack of clarity between the business that needs a solution and the team that is building that solution, there are many places where poor communication can make the project less successful than it otherwise could have been or, in the worst case, a total failure. I recognized this to be a problem during my early years of SharePoint consulting, so I made it part of my job to find solutions to the communication problem. I have been lucky enough to find some really great tools that have literally xxi www.it-ebooks.info ■ INTRODUCTION changed my life as an information architect. These tools are easy to learn and use and make a huge difference in the likelihood of success for a SharePoint project. More recently, I have come to understand more about why these tools work so well. How Can We Make It Easier? Whenever you are dealing with a complex problem that has a lot of social complexity issues (e.g., political factors, diverging goals, differences in levels of understanding), you cannot hope for success unless you get a shared commitment to the goal by at least most of the stakeholders. Without a shared commitment, the project will be pushed off course, mired in endless bickering, or just die through lack of drive to invest the time and energy required to see it through to the end. Before you can get to a shared commitment, you must achieve shared understanding. There is no way someone can commit to a project that is going to take up valuable time and energy without a clear understanding of its goals. At a more detailed level, getting signoff for a navigational structure or a content taxonomy requires an understanding of what is being designed and, as importantly, trust that the team building the solution understands the problem deeply and well. Working with diverse teams who have diverse motivations, the information architect has to combine enthusiasm, storytelling, and some psychology to help everyone see the carrots (benefits) and sticks (results of project failure) that await them. As Sue Hanley states, you need to be able to answer the "What's in it for me?" question. What Is In This Book? In this section I will briefly describe what is presented in each chapter of this book. Chapter 1: Planning for Successful Outcomes This chapter builds the basis for the key personal skills you will need to cultivate to be successful as an IA or a BA: confidence, humor, and honesty among them. We then talk about how to run successful workshops and how to use them to build your own understanding of the issues within the organization that SharePoint could be applied to. We then cover the concept of building road maps for planning your project phases. Chapter 2: Introduction to Mind Mapping This is the first tool I discovered that led me on the path I am now on. I will show you how quickly you can learn mind mapping as a technique for visualization that will instantly make your meetings more compelling, useful, efficient, and fun. Chapter 3: The Magic of Metadata Having a clear understanding of metadata and being able to explain it clearly to your project stakeholders are essential for success. This chapter begins by explaining the metadata concepts and then build on them to an understanding of taxonomy, content types, and exploration of the “f-word” (that’s “folders”). We talk about how to gather the metadata you will need for your project and how to build interactive taxonomy maps using mind mapping tools. Chapter 4: Site Navigation and Structure One of the most political elements of building a SharePoint site is getting agreement on the site navigation. There are multiple competing interests who want their area to be highlighted or who don’t xxii www.it-ebooks.info ■ INTRODUCTION understand why just replicating the organization chart won’t work. We again use mind mapping to work interactively with the stakeholders to solve this efficiently. We talk about card sorting techniques to validate the structures, and talk about the differences between portal areas and collaboration areas. Chapter 5: Wireframing for SharePoint Wireframing was never something I enjoyed doing until I discovered a tool called Balsamiq, which had just the right mix of simplicity and power. This chapter will cover the approach I take to wireframing and demonstrate how to use Balsamiq. I also talk about Microsoft Visio for wireframing as well as usability testing and content strategy. Chapter 6: Complexity, Wickedness, and Dialogue Mapping Getting to a shared understanding of what it is you are actually going to accomplish with your SharePoint project is probably the single biggest factor that will govern your project’s success or failure. This chapter will introduce the IBIS grammar for mapping, as well as the compendium software used to build these types of maps. I will show you real-world examples of how I have used these maps to rapidly achieve agreement about project goals and scope. Chapter 7: Business Process Mapping Business information is not just static, it flows. So just discussing the structures for storing information leaves out a big part of the story. The mapping of information flows as part of business processes is an important part of planning for SharePoint because of the workflow capabilities that it brings. This chapter covers the use of Microsoft Visio and BizAgi software for modeling business processes. Chapter 8: The Art of Creating Business Process Solutions In Chapter 7 we covered tools for mapping business processes. In this chapter, Sarah Haase writes about how to actually build solutions that implement business processes and—very crucially—talks about how to measure the return on investment (ROI) for these types of solutions. The ROI calculation is one that will matter to anyone who needs to prove the bottom-line value of any investment you have made. Chapter 9: Success with Search In this chapter, Michal Pisarek writes about how important good search is to the success of your SharePoint project. He talks about establishing search requirements and then how to take advantage of SharePoint search features such as facets, best bets, and reporting to ensure that your users get the best search results possible. Chapter 10: Governance, Adoption, and Training Governance, adoption, and training are concepts that are deeply intertwined. After your SharePoint site is delivered, it is these elements that will determine if you have built a viable, long-term solution or something that will either die from lack of use or become chaotic and unmanageable. Chapter 11: Practice and Testing in the Cloud Our work often requires us to test new concepts and potential solutions. Because SharePoint is so large, we can’t know all of the parts of it, and when our colleagues or customers ask us whether something is possible, we need to have access to an environment that gives us free rein to test out ideas. This chapter xxiii www.it-ebooks.info ■ INTRODUCTION will compare the services I have used for this purpose: CloudShare, Microsoft Office 365, and Amazon’s Elastic Compute Cloud. Chapter 12: Conclusion: Putting It All Together I conclude by taking you through the lifecycle of a SharePoint project, put together everything you’ve learned throughout the book, and emphasize the key tools and when and how you would apply them. xxiv www.it-ebooks.info CHAPTER 1 ■■■ Preparing for Successful Outcomes Everything should be made as simple as possible, but no simpler. Attributed to Albert Einstein SharePoint projects are notorious for their difficulty. The seeds for a successful project are sown in the early days of the project, when you, as the project consultant, have to rapidly integrate yourself into an organization, build trust with your client stakeholders, and gather the essential information you will need to be able to deliver a successful solution. You are doing more than just listening and learning in this phase: You are educating your clients and often shaking them to their core by forcing them to rethink their approach to technology solution implementation. You push toward simplicity and maintain your focus on business outcomes rather than simply gathering lists of requirements. You do this knowing that the simpler solution is much more likely to be successful, and that it will be the foundation upon which more complex and sophisticated solutions may be built. The Soft Side of Successful Projects Around the turn of the 15th century, Niccolò Machiavelli would have said something like the following about SharePoint projects: It must be considered that there is nothing more difficult to carry out nor more doubtful of success nor more dangerous to handle than to initiate a new SharePoint project; for the project team has enemies in all those who profit by the old portal, and only lukewarm defenders in all those who would profit by the new portal; this lukewarmness arising partly from the incredulity of mankind who does not truly believe in anything new until they actually have experience of it. Okay, so he wouldn’t have been specifically talking about SharePoint, but it certainly rings true today. In my experience, pretty much everyone hates the current intranet portal: They can’t find stuff and they don’t know if they can't find it because it’s not there or because it’s hidden. And once they do find it, it’s hard to tell if the material is still valid. Even so, there’s a lot of resistance to the new portal project because cynical disbelievers don’t trust the team to get it right this time either. As good old Niccolò says, they do not “truly believe in anything new until they actually have experience of it.” It is into this environment that you are about to enter when you take on a SharePoint project. You are going to have to navigate your team off the path of hope (which always proves to be a false route), over the rise of optimistic excitement, and through the valley of despair. It’s a steep climb at the end to 1 www.it-ebooks.info