This post is a follow-up to my SharePoint In Action overview post which can be found at SharePoint In Action: An Overview .
Project success is dependent on great project management. Great product management is only possible if you are using the right tools. If you’re delivering a one-use application feel free to track your schedule on the back of a napkin. However, you need to be better prepared for any other project.
When I came on board to Swimfish I found that we were using Microsoft Project for driving the majority of our product and services driven projects. The team was using the tools well, executing on or near on schedule. It was clear, however, that the individual project files were not providing enough visibility into resource allocation conflicts or project backlogs. I needed another solution. While I did consider Microsoft Project Server I felt that a solution within SharePoint that would ultimately tie back into our CRM system (and other systems as well) was more in line with where I want to take the organization. My goal for the rest of this post is to go over how we are using it today, some of the initial challenges we encountered, and where we will go in the future.
Creating a simple multiple project tracking site within Sharepoint is straight-forward, just use the Site Actions -> Create -> Sites and Workspaces. From there, choose the Budgeting and Tracking Multiple Projects template and create the site. This standard template provides a good starting point to begin exploring the capabilities. For us, however, I needed to make a few changes in the application and in our processes:
- Lose the concept of monetary cost. We use another system for billing and I wanted to avoid duplicate entry or the more attractive, but more sizable effort, of integrating the two systems.
- Added the ability to track if the project was for internal projects, external products, or customer solutions development. This is important for us to better measure and track the percentage of time we’re investing in each area. I have clear targets that I want to achieve and this will help me measure if we are staying on track.
- Before projects begin all tasks must be in SharePoint and their must be project estimates for each tasks. We use this as our baseline and can determine how well we’ve estimated, using this to help us improve our estimation skills.
- For each project I create a Datasheet Grid view for all tasks. The view lists all tasks for that project and includes totals for percent complete. Team members are expected to have this view open and update as they go. This minor amount of extra process ensures that everyone has an up to date view of the project as it progresses towards each of it’s milestones.
- I have also created views for each of the team members, showing their open tasks. This view enables me to quickly determine the individual team member’s backlog. In the startup environment that we live in everyone is working on multiple projects and it’s very helpful to have this view at the individual level as well as at the individual project level.
- Our documents are all stored in document libraries within this site. This has worked well and has improved our level of collaboration beyond what we had been using (primarily Lotus Notes).
REMAINING SHORT-TERM CHANGES
While we’ve made great strides with this system there are a few short-term changes that are still needed.
- Leveraging the Dashboard view as part of our daily standups. We use this great agile practice and it is beneficial for everyone. I feel that Dashboard will provide information for this meeting but have not yet integrated this into our process.
- Creating another view to see resource allocation across all projects that are currently open. Today we have volumes of information available at the individual, and at the individual project, level. The remaining piece is the overview of all resource across all projects, one of the main reasons I went with SharePoint.
- Integrating a tool such as Project Publisher to import/export Microsoft Project files. Microsoft should support this functionality out of the box but does not. We do alot of custom development with customers that want to see Microsoft Project files. It’s critical that we can use these files with our core project management system.
- I’ll be evaluating Project Publisher soon but already have a lot of faith in it based upon this recommendation from Dux Raymond Sy, PMP (http://www.meetdux.com):
“In my experience, Microsoft Project does a great job in allowing project managers to plan and track key project metrics: schedule and budget. However, it is quite challenging since the project information is isolated within the Microsoft Project file. An efficient solution is to leverage Microsoft Project, Microsoft SharePoint and Project Publisher. Project Publisher is a very inexpensive third-party tool that addresses the need most project managers yearn for: allowing project resources to update their tasks on a SharePoint-based project site that synchronizes back to schedule stored in a Microsoft Project file.”
I am a huge proponent of iterative process development. While the work above has already made us a better organization there is much more work to do. While this list is not complete, here are a couple of key integrations coming in the near future:
- Integration with our billing systems. Work on custom projects must be billed in a timely fashion. It’s not fair to customers, or to our company if it is not. Having this more automated will benefit everyone.
- Possible integration with our source control and bug tracking systems, enabling teammates to make changes in one central location and having it flow throughout the company.
- Integration with our CRM system. As engagements are opened in our CRM system I want these to automatically create projects in SharePoint. Automate what you can.
If this is helpful, let me know. I’ll keep you all updated as we continue to refine and improve our efforts here. Also, if you’re doing things with SharePoint that I haven’t listed please share with the group.