Previous chapter: Part 2 - The "Why?"
Obviously when your are managing a department it’s important to know what projects are currently in progress within your department. Furthermore, you will have to know the status of each of those projects, who is working on them, what progress is made, etc. In many organizations project managers make a weekly report for their managers to keep them up-to-date on all of this information. This however means that as a manager, the day after the project manager’s report, you are working with old data. Wouldn’t it be so much better if you had up-to-date information on a project whenever you needed it?
From another stands, it will also be very important for managers to have everybody working on a project in the same way. If every project team works its own way, it becomes nearly impossible to keep an overview on all the projects. As an added bonus, when every project team works in the same way, it’s much easier for team members to switch teams and help out in other projects or even for several teams to work together, without having a learning curve before every change in project or team.
The answers to these issues lies in one of SharePoint’s most documented possibilities, project management through SharePoint often called a PMIS (project management information system).
As mentioned before, the project management possibilities of SharePoint are well documented in whitepapers and even books dedicated to the subject. Therefore we will not go into detail about everything you can do when managing project in SharePoint. We will focus more on what you can get out of it as a manager or a team member and how this achieved with basic SharePoint features.
Where to start?
Before jumping into SharePoint and starting making templates, sites and libraries, there are a couple of things that are very important. Most books or papers will provide a chapter familiarizing with the architecture of SharePoint and will guide you with the decision of how many site collections, sub-sites and web applications you need. But they start from the premise that your organization is mature when it comes to project management before you can even consider using SharePoint as PMIS. Although there is truth in the fact that your organization needs to mature to implement the full-blown PMIS in SharePoint, I don’t agree that if you’re not there yet, you shouldn’t use SharePoint. When you are using SharePoint in a bigger scope, like IT Management, using even the smallest pieces of the PMIS possibilities can help you go forward. Therefore it’s very important to start at the beginning. How mature is your project management? What are your needs when it comes to project management? There are a million flavors of project management and although some are more efficient and more successful than others, SharePoint is not there to change your way of working, it’s there to help you in whatever way you want to do project management.
So when you start thinking of SharePoint for project management, think about the bigger picture. What do we want to get out of SharePoint when it comes to project management? Do we just want reporting on status and budget? Do we want a collaboration platform for project teams and possibly even customers? Whatever the answer to any of those questions is, adjust your strategy accordingly. It will not do you any good to create complete collaboration site templates for projects when all you want is a library where project managers can put there project status reports.
The most important advice here is: be honest. If the solution you come up with does not match with your needs, a lot of time, effort and money will be spent on something that nobody will use. Of course, implementing SharePoint for project management in your department will bring with it some change, but it’s important as manager to resist the temptation of changing everything, going from almost no project management to the full-blown PMO with a rigorous structure. A change that big will almost always end in failure. You can introduce some new procedures and reporting documents. Just remember that you can always expand the SharePoint project management later on. As a start it’s important that everybody involved is first convinced that working with this new tool not only provides benefits for management, but also for themselves whether they are project manager or team member.
What can you get out of it?
After you determine what you want out of it, it’s time to determine what you actually can out of it. In a perfect world, the “want” and “can” will be the same, but we all know this is not a perfect world. Compromises will have to be made. For instance, if getting a complex report that combines all the data from all the current projects, doubles the work of getting one report per project, maybe it’s not worth it?
Discuss these things with everybody involved and again be honest with yourself. Prioritize the things you want and don’t try to get everything for nothing. Remember that the fact that you don’t have that combined report today doesn’t mean that when some time and budget is allocated it couldn’t be added later on. I will go into this further in the chapter of the implementation, but the bottom-line here is “baby steps”. Take it one step at a time. Create an architecture that can incorporate everything, but built your SharePoint implementation gradually to make sure that the basics are there and working before going into the fancy stuff.
For the purpose of this story, we will start from the premise that you do want everything SharePoint can offer when it comes to project management. You want the project status information, the progress, the collaboration platform for the team and a place for you the manager that combines all of this information. So how can we achieve all of this?
How do we achieve this?
Achieving full project management functionality in SharePoint will not happen overnight. It will take some careful planning and what I presume will be a lot of long meetings about what everybody wants from it.
The first step will always be to divide your projects in categories. One template to fit all projects is something that will be very hard to come by, so dividing projects into several categories will always be a good idea. That way a template per category of projects can be made. This will limit the number of compromises to be made between teams working on different categories of projects. Again, SharePoint tries as much as possible to help you in your way of working and not to force you to change. One piece of advice applies here, try to limit the number of categories to a maximum of 4. It’s very unlikely that you could not put all the projects you have into four distinct categories (or less). If so, try and combine categories so in the end you will not have to build more than 4 project site templates.
After having determined the categories, it’s time to make the project site templates. Essentially what you will do is create one project site per category and add all the lists, libraries, web parts, features and sub-sites you need in a typical project of that category and save it as a template.
So what has to be in one of those project sites that will enable us to manage a project through it you might ask? Typically a project site will consist of two SharePoint sites. The main site and a document center sub-site that will function as the document management system for that project. The structure of the document libraries within this sub-site will all depend on the way of working you are already accustomed with now and the phasing of a project of that category. The major advantage of having a sub-site that contains all the documents is that upon project completion, the entire sub-site can be moved to an archive or a reference library containing all the documents of all the completed projects. This way, no documents will be lost when the project is completed.
The main project site will be a working site, meaning that this site will constantly be updated and worked on by any of the team members. Here you will have lists with project tasks, project calendar(s), bugs, defects, announcements and any other list that might enable your team to use this project site as their central working place for the project. Typically you will also see pages with KPI lists and excel representations of data that is taken from Excel sheets that are physically kept in the document center sub-site. Finally, most project site will integrate an MS Project file to keep track of the planning. Although integration with Project Server is possible, it’s not included in the default components, so you will have to put in some extra effort or just have a daily view of the Project Server planning updated by the project manager. The possibilities are quite extensive so make sure to consult some of the books or online resource regarding project management in SharePoint.
Now that you have all the lists, pages and libraries you need, don’t forget the navigation. Navigation is one of the crucial factors in the success of a SharePoint implementation. If the navigation is not well thought through, people will not find the documents or information they need and eventually stop using the site altogether. Important advice is to keep the navigation of the project site limited to the Quick navigation bar on the left of the page. Try to avoid putting project links in the top navigation. Keep to top navigation the same throughout the entire SharePoint Portal (see chapter Implementation). What navigation is best for your project is something that has no definitive rules, but make sure you don’t forget to think about the navigation. It will make or break your site.
A new project arrives
So you have created a project site template for every category but now you want to create actual project sites. Most administrators will agree with me that it is unacceptable to have project managers create their own project sites. This will be up to the administrator. Problem there is that an administrator knows very little about the project. So how can he properly create a project site with a correct name, the correct team members who have access or any other information that needs to be available at creation of a project site?
A very effective way to do this is create an administration site where project managers can make a request for a new project site by filling in an InfoPath form or something equivalent. That way, a workflow can be started when the request is created. It can be verified automatically by a manager and after he approves the request, the administrator can create a project site with all the information filled in on the form.
There are more elaborate ways to do this and if you already have a ticketing system or something similar in place, of course that can be used to. But don’t forget that the actual requests may be information you want to include in reports or want to save as reference. Having that information in SharePoint already will vastly improve the usability of this information. Since creating an InfoPath form and a workflow are pretty basic SharePoint features, my advice is to use this as your request system and thus using SharePoint for even one more feature you might not had thought of before you started to read this story.
At Euricom we have developed an extensive SharePoint PMIS system for development projects. For more information on this system, visit our website at www.euri.com or contact us directly.
By Ronny Gabriels, Functional Analyst and ex-.net Solution Architect
Next Chapter: Part 4 - The People