New book: Microsoft SharePoint 2010: Creating and Implementing Real-World Projects

We’re excited to announce that Jennifer Mason, Christian Buckley, Brian T. Jackett, and Wes Preston’s Microsoft SharePoint 2010: Creating and Implementing Real-World Projects (ISBN: 9780735662827; 438 pages) is now available for purchase!  

You can find the book’s chapter-level table of contents and Introduction to creating and implementing Microsoft SharePoint real-world projects in this previous post.

The approach the authors have taken in the book is to standardize each chapter's structure, which allows you to understand the what, why, and how of each solution quickly:

· Identifying the Business Problem: Explanation of the business problem to be solved

· Gathering Information: What are the requirements from the business side?

· Designing the Solution: How is the solution going to be implemented, and which SharePoint features are going to be used?

· Building the Solution: How the solution is created (using a lot of screenshots)

· Managing the Solution: What else can/should be done, but isn't part of the project's building process (driven by the individual company's requirements, such as managing permissions)?

· Reviewing the Platform: Can this solution be implemented in SharePoint Foundation, SharePoint Server Standard, SharePoint Server Enterprise, and Office 365 (SharePoint Online)?

In today’s post, please enjoy reading an excerpt from Chapter 1, “Building a Project Management Solution Within SharePoint.”

Chapter 1

Building a Project Management Solution Within SharePoint

Finding ways to better manage projects is a key concern for many different organizations. Projects are typically the heart of any company, and the success of how projects are managed determines the success of the company. Finding tools that enable you to better manage your projects can have a direct impact on the success of the organization.

Many great tools are available in the market that you can use to help manage projects, and some of them, like Microsoft Project, even integrate with Microsoft SharePoint. But not all organizations are ready to manage projects at the level required to successfully implement those solutions. Some organizations are looking for straightforward ways to better manage current processes and improve current communications. In this chapter, you will work through the process of creating a simple SharePoint solution for managing projects. You will start by reviewing the business problem, then you will work through the design phase, and finally you will implement the solution. Once you complete the implementation, you will look at the different steps you need to take in the future to manage the solution.

Have You Read the Book’s Introduction?

This book is organized in a way that allows you to find topics quickly. Each chapter is structured in the same way, allowing you to read about a particular business scenario, from the requirements to the solution. If you haven’t read the book’s introduction, you should do that before reading this chapter. This will help you understand the flow of the topics in chapters.

In this chapter you will take on the role of a business analyst building a solution that your organization will use to manage projects. This means that you are on the outside looking in to the ways that projects are managed in your organization. To get the most out of this chapter, you should try hard to look at the process from the outside and not from your current role on projects.

Identifying the Business Problem

For any solution you build in SharePoint, the place to start is to identify the business problem. You want to fully define and understand the issues that users face, as well as understand the overall goals of the organization. You want to look at the problem from all perspectives to ensure that you build a solution that will truly address the needs of the organization. After all, you could spend a lot of time building the perfect solution, but if no one uses it, then your time spent developing it has been wasted.

When it comes to project management, several common complaints exist within different organizations. In the next section you are going to look at several of the common issues that organizations try to address when they build a solution for project management. You will use these common complaints as the requirements for the solution you will build in the remainder of this chapter.

Important As you read about the issues that are identified, take some time to think about how they apply to your organization. Do you see the same issues? Can you identify additional issues that your organization faces that might not be discussed here?

Data, Data, and More Data

Many of us struggle with information overload. We have access to so much content that it is often hard to determine what is most important and relevant. Content comes in many shapes and formats and can be defined as the information and data that is accessed while we perform our jobs. We access content online, in documents, in the form of personal meetings, and even more in the form of email. We often work with content in various phases and often save copies of the content at each phase. Saving different versions is important because you need to understand how the content progressed from draft to final, but an issue comes up later in the same project when you have to go back and reference the data. Which version is the latest version? Who last made updates? When users were working on the project, it was easy to keep up with the chain of control, but three months later it can be hard to remember.

In addition, having many versions of the content, users have a lot of places to store them. They typically have access to several shared drives, a few personal drives, various SharePoint sites, a local hard drive, and, of course, email storage. Storing content in so many different locations can easily create a large web of disorganized content. While one user or one group might have a very detailed, structured way to store content, what happens when the organization realigns and users move to different groups or departments? What happens to the content then?

The following list identifies specific content management issues you will address in the SharePoint solution that you build in this chapter.

· Clearly identified locations to access project data.

· Ability to manage multiple versions of the same content.

For each additional topic discussed in this section, a new list of issues will be presented. These will then be used in the design section of the chapter as checkpoints to ensure that the solution proposed addresses the issues discussed.

It’s All in Our Minds

The next issue to explore involves the amount of process information that is contained within our resources. Spend a few minutes thinking about the people who work at your organization. Think about the people who have been there the longest. Now think about what would be lost if they left the organization? How much data would they take with them when they walked out the door? The data I am referring to is not physical documentation or files but an understanding of how the organization does business. Longtime employees understand the ins and the outs, and they understand how to get things done, and without them your organization will likely suffer a loss of productivity and efficiency. An organization’s resources are vital to its operations, and your organization will always rely on the minds of its resources, but there are definitely some mechanisms you can put in place to help ensure that practices are recorded and knowledge is retained. This way you are relying on a defined process and not the resources themselves. Having a structure like this in place will provide an easier way to switch out employees and to mentor new employees when they are brought onboard.

But here is where it gets tricky. While there are many standard processes, there are just as many unique processes for each organization. The following list describes some of the general processes that can be put in place, but to really make the most out of this solution, you will want to spend some time thinking about various processes that are unique to your organization and how your organization manages projects. There may be some additional processes that you will want to incorporate into your solution as you build it.

· Clearly identified process for determining where to store project data.

· Clearly identified process for managing different versions of project data.

· Clearly identified approval processes for project data.

· Clearly identified matrix for identifying who has access to project data.

I Don’t Have Time to Learn New Products

The final area to discuss is usability. I am not sure I could count the number of times I have heard from users about the difficulty they have learning and using new systems. Phrases like “Just when I started to learn to do it this way, they changed it” or “Why do all the new ways have to be so hard? This isn’t broken, so why fix it” are very common sentiments among users. I am sure that as you read this, you can relate to these statements as well as add others you have heard from your users. While these complaints are not specific to project management, they should definitely be taken into consideration while you develop your solution. The following list summarizes some of the common pain points that you will address in the solution.

· The solution must be intuitive and easy to use without in-depth training.

· The solution should allow users to navigate easily to different areas.

· The solution should integrate with tools and applications that are familiar and known by the user base.

Summarizing the Business Problem

In this section, three different areas of common business problems surrounding projects have been discussed. In summary, the following areas were identified as key points of consideration:

· Location of data

· Process for interacting with data

· Providing easy and intuitive solutions for users to work with data

Now that you have the data that identifies current pain points, it is time to start gathering some more information. So far, only a very high-level description of common issues and pain points has been identified. The next step in the process is to look deeper into each of the issues and clearly determine specific requirements. You might be tempted to skip over this next section and get right to the meat of things, but I assure you that you won’t want to miss the next few sections. Sure, you could take what you have learned so far and build a solution that satisfied the requirements at hand, but how effective would that solution be? Do you even fully understand the requirements at this point? Now is the time to drill down to that next level and really start to gather those requirements. This is where you spend time talking with different users to learn about what they are currently doing and develop an understanding of their pain points. The high-level issues identified earlier will serve as our starting point for the requirements gathering phase.

Gathering Information

During this step of building the project management solution, you are going to look in more detail at the specific requirements of the system. You will start by evaluating each group of users who will use the system to get a good understanding of what they will use the system for. As you meet with users and look at their needs, you will be able to identify the specific requirements that need to be included in the solution.

System Users

Our solution is going to be built based on the requirements of three types of users. Each group will interact with the solution differently, and to ensure that the solution is as effective and usable as possible, it is important to understand the specific needs of each user group.

Keep in Mind!

Remember as you read through this section that your organization might operate differently and might use different terms to describe its users. If that is the case, then once you review this section, spend some time evaluating the differences within your organization. Once you understand the differences, you should be able to adapt the proposed solution to meet your specific requirements. You should be using this book as a template to get you started, so expect to learn from this book and then adapt what you learn to your specific needs.

Project Committee

The project committee, in our example, is a group of users who are directly responsible for the strategic direction of projects within the organization. They provide oversight, direction, and approval for projects and are responsible for understanding how projects relate to the direction of the organization. They approve the start of all new projects and provide strategic direction for the completion of projects. While project managers work directly with the organization throughout the project process, they are also responsible for communicating status to this oversight committee.

In terms of our solution, the project committee would require the following level of functionality:

· Ability to access a real-time summary for all projects, which includes the following items:

· Scope

· Budget

· Schedule

· Ability to review, as needed, the following items for a specific project:

· Project tasks

· Project calendar

· Project issues

· Project documentation

Project Managers

In our example, project managers are directly responsible for the day-to-day management of any given project, based on the scope, budget, and timeline. Depending on the scope of the project, a project manager might be responsible for only a single project or for multiple projects. Project managers are responsible for assigning and directing resources, as well as for reporting on project status to the various stakeholders.

In terms of our solution, project managers require the following level of functionality:

· Ability to get real-time status on any of the project elements, including the following items:

· Project tasks

· Project calendar

· Project issues

· Project documentation

· Ability to easily report on the current project status to the project stakeholders.

· Ability to easily communicate with various project resources on project issues and tasks.

Project Resources

In our example, project resources are the people directly responsible for completing project tasks. They work together as a team and rely on each other to complete the project. Most resources will be assigned to specific project tasks, but in general the project is considered a team effort and will require a level of input from everyone as tasks are completed

In terms of our solution, project resources require the following level of functionality:

· Ability to get real-time status on any of the project elements, including the following items:

· Project tasks

· Project calendar

· Project issues

· Project documentation

· Ability to easily interact with other project resources on any project components.

· Ability to create additional project tasks for project team members.

· Ability to easily communicate with various project resources on project issues and tasks.

· Ability to easily update project manager on project tasks and assignments

Different Users Working Together

So far, we have outlined three different types of users who will be accessing our solution, and we have identified the primary requirements that each type has for the solution. If we mapped out the relationship of users, it would look similar to the illustration shown here.

In this diagram, you can see a relationship between the three user groups. Each group works together in a slightly different way but is still part of a larger solution. As you look at building this solution, it is important that you understand the requirements of each of the user groups and how they are incorporated into the solution as a whole. Any solution that you build needs to address the requirements of all three unique types of users and still provide one consistent solution. The best way to determine how to achieve this goal is to spend some time identifying how the different users interact with each other. The following illustrations show the relationship between the different users.

These diagrams provide a high-level overview of how the different roles are related to each other. This information will be used to help design a solution that best facilitates this relationship. Understanding how the solution’s users are related helps ensure that our solution includes these relationships in the overall design.