IntroductionMany organizations today have implemented technology such as Microsoft SharePoint to provide a central portal into their organization’s information and operations. While the promise of a central portal is alluring, it can also be elusive for project based organizations. The reason for this goes to the very purpose of systems such as SharePoint and project management systems.In addition, mid-market organizations have additional considerations. For the purposes of this paper, a mid-market organization is simply an organization that needs more than the tools that the low-end market provides, but does not have the resources, time, or budget for the tools provided for the high-end market. In other words, they are right in the middle and need the right balance between sophistication, ease of implementation, and cost. Whereas certain solutions may be obvious for large organizations because of the internal resources available, they are less obvious for mid-market organizations.This article will discuss strategies for how to solve these problems and properly implement project management capability with a SharePoint-type of information portal, within the bounds of the mid-market predicament.Different Systems, Different PurposesAn online portal, such as SharePoint, is generally defined as collaboration software with the benefit of sharing information in order to work better. In the last 10-15 years especially, information within the organization has grown dramatically. Emails, spreadsheets, documents, and all other types of information became scattered throughout the organization. The promise (and purpose) of SharePoint especially is to put some structure around this information, centralize it, and make it easily accessible to everyone in the organization. There is a lot of value in this. This is not to say that SharePoint cannot be configured to do a number of different things beyond what was just mentioned, only that this is the primary, stated purpose of SharePoint.For project organizations that are focusing on running projects, this focus causes some gaps if an organization is planning to rely solely on SharePoint for its project management needs. The primary reason is that SharePoint is not project management software and thus does not naturally have some project management features that project organizations need. These include items such as Gantt charts, project scheduling engines, and resource utilization tools. SharePoint does have natural capabilities that do support project management processes, such as lists, document management, and collaboration. It is just that, for project-based organizations, these capabilities tend to weigh too heavily on collaboration and not enough on more formalized project management tools. Organizations with heavy project loads find that they need a balance of both. The fact that this is true of SharePoint is evidenced by Microsoft’s push for deployment of Microsoft Project Server as a tool to be deployed in addition to SharePoint, although many mid-market organizations struggle with the implementation of two complex systems.Conversely, project management software systems, are designed specifically to help project based organizations manage their projects. As such, they generally include more formalized project management features such as Gantt charts and scheduling. A good project management software system will support the processes that a project based organization needs to follow to work better and be more competitive.On the other hand, most project management software systems are not designed as a portal for all information in the organization. They are focused on projects, the information pertaining to those projects, and the management of those projects. As such, it can be difficult for an organization to rely solely on project management software as a portal for the entire organization. It is not impossible to do this, simply difficult without the right mix of project management system capability (or better stated flexibility) and organizational needs.This all is not meant to frustrate the reader, only to reiterate what the fundamental purposes are of different types of software systems so that a coherent and practical strategy can emerge to meet the needs of mid-market organizations with project management requirements.StrategiesWhat are the strategies then that a project based organization can employ to achieve both the centralized portal and collaboration benefits of a SharePoint type of system and the project management benefits of a project management software system?There are three fairly obvious and logical strategies to be discussed along with their strengths and weaknesses.Strategy #1: SharePoint OnlyThe first strategy is to utilize the SharePoint technology exclusively and take the time and resources to configure and even extend its capability to fill in any gaps that arise. There are several advantages of this approach. These include the fact that there is only one system to manage. All of the information is in one system meaning that you do not need to develop knowledge regarding two systems or worry about integration between those systems.In addition, many organizations already have SharePoint implemented within their organization making it an easy decision to use existing technology.There are also some disadvantages to this approach. These include the fact that there will most likely be some gaps in the project management capability that will need to be filled in some way. This could be done via technical configuration or programming, or third party tools, but in some way the gaps will need to be filled to be effective. Another disadvantage is that technical resources will be relied upon to both keep the system operational and help it meet project management-specific needs. SharePoint is not a simple system to deploy, implement, and maintain.The idea with this strategy is to simply do the best you can with your existing SharePoint technology.Strategy #2: Project Management System OnlyThe second strategy is to implement only a project management software system and use it for all of the organization’s needs. There are advantages to this approach as well. Similar to the first strategy, one advantage is that there is only one system to manage. All of the information is in one system thus requiring less training and administration. Another advantage is that the system will be designed specifically for project management. If most or all of the organization’s information is project-based, this will work well.Some of the disadvantages of this strategy include the fact that most project management software systems are not designed for other types of information sharing. For example, you generally will not see information on open orders from the organization’s accounting system in the project management system’s dashboard. It should be noted that this is not impossible, some systems have the capability to link to other systems and display data, but this is not the native purpose of these systems. Stated another way, these systems are usually geared towards projects, and not an overall portal for all the information in the organization.Another disadvantage can be the fact that project management software systems tend to be more formalized which means there may be some additional training involved over a simple collaboration system. This is not necessarily a bad thing – if an organization needs that level of capability, then it needs that level of capability and must train its staff on the capabilities and desired processes – but it is still something to consider.The idea with this strategy is to go full-out into what your organization in reality does: delivering projects.Strategy #3: The Hybrid ApproachThe third strategy is a hybrid of the other two strategies and involves implementing both a SharePoint type portal system, in addition to a project management software system. In other words, you implement both types of systems and connect them together.There are several advantages to this approach. For one, this approach works well with the whole idea of a portal system in the first place. In other words, a portal system like SharePoint is not meant to replace every other system in the organization but to act as a portal and central processing point for the information from those other systems. For example, an accounting system does what it does, while sharing information with the SharePoint system so that SharePoint can act as the central “clearing house” of all information. Likewise, a project management software system does what it does, while sharing information with the SharePoint system. In this approach, SharePoint becomes a true portal for delivering all relevant information across the organization, while the other systems are used to do what they do best (i.e. accounting for the organization’s finances or managing projects).In addition, there is generally more flexibility that an organization has with this approach. Considering the focus of managing projects, if there is a specific need for technology to support a new or improved process, you have more than one option. You have the option of doing that in the SharePoint system or you have the option of doing that in the project management software system, or even in the connection between the two systems. Either system may do certain things better than the other so that you are not tied down to a single technology.As with the other strategies, there are disadvantages to this strategy as well. They include the fact that you have to maintain multiple systems. This is negated somewhat if you take a Software as a Service approach (i.e. you do not host the software yourself), but there will always be some administrative items that you will need to have internal knowledge to function effectively.In addition, you need to maintain an interface between the two systems so that project information can be easily displayed in the SharePoint portal. That is not terrible difficult these days, but still an item to consider that needs to be maintained.The idea with this strategy is to get the best of both worlds.ConclusionsAs with any evaluation of software technology, the conclusions depend a great deal on the specific needs, objectives, culture, and processes of the organization performing the evaluation. The purpose of this paper is to provide background information so that you can determine the appropriate technology direction, not to make the decision itself. Thus it is important to understand your own organization before making determinations regarding technology. Once you have done that, there are some general guidelines that you can follow.If you do not have formal processes and can operate the organization entirely by collaboration, then native SharePoint technology may work.However, if you are a project based organization with any type of scheduling needs, project management software capability will be needed. A distinguishing factor is often in the management of tasks. If a simple to-do list is all that your process requires, then collaboration-type of software may fit the bill. If there is a scheduling component to the process (i.e. tasks need to be done at certain times and the schedule of those tasks needs to be tracked), then project management software-specific capability is generally required. There are other factors (such as resource utilization tracking) that can be evaluated, but task scheduling is generally the most common factor determining project management software need.If your organization is small enough in size and the scope of its information sharing is primarily project management focused, then using a single project management software system is generally a good approach. In other words, if you are in reality delivering projects and that is your world, go with the technology geared towards that world.Conversely, if your organization is large enough in size and has broader information sharing strategies beyond just project management, then incorporating a project management software system combined with SharePoint provides a lot of value.SharePoint is a registered trademark of Microsoft Corporation. EnterPlicity is a registered trademark of Team Interactions, Inc.