The Bamboo Team Blog : Best Practices Conference, Best Practices, @bpconference

BPC: Best Practices in Leveraging Microsoft Project 2010 With SharePoint 2010 for Project Management

Katie Packard — Wed, 25 Aug 2010 16:25:00 GMT

What's the number one tool used to collaborate in projects? E-mail. The telephone is number two. Shame on us.

—Dux Raymond Sy

Echoing sentiments from his presentation yesterday, Dux Raymond Sy emphasized that communication and collaboration are key to successfully using Microsoft Project 2010 and SharePoint 2010 to create an effective project management information system (PMIS) in Best Practices in Leveraging Project 2010 With SharePoint 2010 for Project Management.

"I'm a big advocate of tools," he said, "but only if they make sense. Tools are tools; it's not fair to blame tools if your process sucks, if you suck."

So ask yourself, why do you suck? Why does your process suck? Why do your tools fail? According to Dux, you're probably lacking a good process. You need well-defined requirements, vision—and a clear, relevant project management (PM) process.

"Tools don't run projects," Dux noted. Responsible and accountable people use tools to make projects successful, not vice versa. "Get your priorities in order. Realize that Project and SharePoint are tools." So before you just dive right into Microsoft Project 2010 and SharePoint 2010, define your project and do the initial planning before you begin using these tools.

Establish an effective standard for PM processes. "Does every [project manager] manage projects the same way?" Dux asked. Of course not. "[You] need to implement a standard way of [managing projects and processes]. Think about what you're doing and what your world is."

So how can Microsoft Project 2010 help you with your PM processes? The key is understanding what Project 2010 is and does:

A project management tool that supports:
- Project schedule development and management (such as planning and tracking)
- Resource management
- Project reporting
Project 2010 assumes that users are already familiar with a PM process.

Ask yourself if Project 2010 is going to suit your needs. "A lot of people use Project to make the Gantt chart and color code it," Dux said. Then they print out the chart, post it in the board room, "and that's the end of it. They look at the same picture [week after week]. They're not using it for tracking. If that's all you want, forget Project; use Excel."

Once you've decided Project 2010 is what you need, and after you have the right people and processes in place, how do you take advantage of Project 2010 and SharePoint 2010 together and create a PMIS?

Again, Dux stressed the importance of understanding what your desired tool is supposed to do. A PMIS:

Is a standardized set of automated PM tools available within the organization and integrated into a system.
Contains real-time information that’s essential for initiating, planning, executing, controlling and closing a project.
Is used by the project management team to:
- Support the generation and maintenance of project artifacts
- Facilitate communication and feedback
- Monitor project activities
- Control project changes
- Analyze and forecast project performance

To get started, create a PMIS upon project initiation. As soon as the project is defined, create a SharePoint site to serve as the PMIS. Dux suggests working with your IT department to create relevant templates for your PM needs. This provides value because you're using what you're already familiar with—out-of-the-box SharePoint—but now you have specific content related to what you need to do your job effectively.

Begin project planning by developing the initial work breakdown structure (WBS) before you start to use Project 2010. "You gotta do your homework to find out what's needed to make this project a reality," Dux stated. "You're not even concerned with the schedule yet."

Once the WBS is created, open Project 2010 to create a project plan. Fill in your tasks and identify your estimates; create your network diagram and build your dependencies.

Use the Work column along with the Duration column to better track your project, Dux advised, and take advantage of Project 2010's new feature: the Task Mode, which lets you choose whether you want to manually schedule your project or let Project 2010 automatically do it for you.

Use SharePoint 2010 to facilitate team and project collaboration. Use the calendar in SharePoint to create recurring events and integrate them with your Microsoft Outlook calendar—something users are already familiar with, Dux pointed out. Use SharePoint's discussion board to step away from e-mail. These features help you manage multiple ongoing projects and save you time since you only have to enter in data in one place. They also make SharePoint a PMIS: it's a centralized location that everyone has access to. It's easy to search, and everything is documented.

A typical project manager tracks schedule, budget and change, Dux said. Project tracking entails monitoring, analyzing and correcting. "That's why project management can't be a part-time job or an afterthought," he said. "[Project managers] have to monitor what's going on."

Project 2010 and SharePoint 2010 work together to help project managers stay on top of their projects, especially with Project 2010's ability to sync project task lists with SharePoint 2010. This means that:

Project resources can enter updates in SharePoint.
Project managers can sync updates with Project 2010.
Custom field information can be used to generate reports.

Sync your task list to SharePoint, making sure Finish Variance is displayed in order to calculate the difference between the baseline finish and the actual finish. "This is valuable for your status," Dux noted. "You can take that data and put it in a dashboard."

Use SharePoint to display information from the project task list by creating dashboards with out-of-the-box web parts and chart templates, Dux suggested. Use the dashboard for reporting to save yourself time and to automate several processes using out-of-the-box SharePoint features such as alerts.

Create workflows and change request forms with the help of your IT department, templates and out-of-the-box SharePoint workflows, Dux said, to create a truly useful, effective PMIS with SharePoint 2010 and Project 2010.

For more on the Best Practices Conference, check out the agenda or follow the #bpc10 hashtag on Twitter. For more on Dux, visit his Web site, or follow him on Twitter.

Check out our full coverage of the Best Practices Conference 2010:

BPC: How to Best Gather Requirements for SharePoint Projects

Katie Packard — Tue, 24 Aug 2010 21:05:00 GMT

SharePoint is like water. It can be anything and something and nothing. People want to box it one way, and other people want to box it another way, which is fine, except that nobody's on the same page.

—Dux Raymond Sy

Why do requirements and SharePoint implementations fail? According to Dux Raymond Sy, the answer is lack of relevant communication.

Speaking at the Best Practices Conference today on How to Best Gather Requirements for SharePoint Projects, Dux emphasized that communication is key in order for requirements to succeed.

"Why are requirements so difficult? They're not sissy work," he asked. The trick, he said, is understanding the word: Requirements are something wanted or needed. They're capabilities that are needed to solve a problem. They are formally written and documented; they identify constraints on a system, service, product or process. They are capabilities that are needed to solve a problem.

To begin developing the requirement, look at it from three angles:

1.   Business requirements: What is the business focus for this requirement? The organization's focus?
2.   User requirements: What's the user's focus?
3.   System requirements: What is the system focus? What are the hardware requirements, operating system requirements and so on?

Take what you've gleaned from the angles, Dux stated, and use that to define your business needs—this is a must.

For example: Information workers spend 45 minutes each day searching for information. In a team of 20 people, that's 900 minutes lost each day. So what if search productivity can be increased by 15%? That's gaining back 7 minutes from the 45 minutes lost.

Then map those needs to SharePoint requirements, and be specific.

Business requirement: SharePoint shall increase user productivity by 15%.
User requirement: Users can retrieve search results within 5 seconds of submitting a search request that can support a max of 10,000 simultaneous search requests.
System requirement: The SharePoint server shall have at least 2 WFEs and a dedicated SQL Server that has at least dual processors.

A well-defined business need and a clearly mapped SharePoint requirement create a trail, Dux noted. If someone asks why IT is setting up two WFEs, you can point to the requirements for the explanation.

There are four key components to developing requirements, he shared:

1.    Eliciting requirements
2.   Analyzing requirements
3.   Validating requirements
4.   Documenting requirements

Requirements elicitation involves finding out what the stakeholders and users need, determining requirements sources, and deciding how to gather information. In other words, get your hands dirty—talk, observe, research.

Then make sense out of the information by analyzing the requirements. Profile the users and understand and determine what the real requirements are.

Validate the requirements by allowing the users to prioritize the requirements. Help them understand the true cost, resources, time and skills sets needed to succeed—and that they can't have it all. The scope needs to be limited and specific. Pick one process that you can solve, Dux stated, "and they'll get that this is a business platform."

Once you've confirmed the requirements, get them on paper by documenting the requirements. Dux points out that a requirements document doesn't have to be 20 pages, but it does need to include the requirements statement, process diagrams and a traceability matrix.

A requirements document should have specific content in a good structure, he said. "Specific content has to be measurable. You can't just say, 'It's very fast.'" Start with a subject, then the capability, then the criterion: SharePoint <subject> shall increase user productivity <capability> by 15% <criterion>.

In conclusion, Dux emphasized that every internal SharePoint implementation should be treated as a project, no matter how small. "Otherwise, no one takes responsibility," he said, and the implementation is unsuccessful.

For more on the Best Practices Conference, check out the agenda or follow the conference on Twitter using the #bpc10 hashtag. For more about Dux, visit his Web site or follow him on Twitter. To see his presentation on video, visit his slideshare.net page.

Check out our full coverage of the Best Practices Conference 2010: