For many organizations, formal projects represent the most significant collaborative process they have. They impact a large number of people across a variety of roles for extended periods of time. They form the foundation for getting certain things done - and these things tend to be complex and have a lot of moving parts to coordinate. Yet at the same time, project documentation is often the most poorly managed from an information management perspective.
Consider the following for a typical project. The project manager, and perhaps team leads, have Microsoft Project or another project management tool. Everyone else's task lists and timelines are probably kept in spreadsheets - maybe on a single shared drive, but often on individual user's PCs - and versioning is generally done with e.g. "projectXdate.xls", "projectXdate2.xls", "projectXdate2aupdateafterstatusmeeting.xls", and so forth. Updates - to draft deliverables, to schedules, to meeting agenda - is done via email with all the benefits associated with it: people left off a distribution list, email overload generally, even worse document management courtesy of email attachments, etc.
Now the actual collaboration is probably also done via email and looks something like this: a team member drafts a draft and emails it to the team requesting feedback. Some provide it in the form of a marked-up document; some provide it in an edited (but not marked up) document; some provide it as notes in the body of the email; and some don't respond. The team member collects all the feedback, sifts through it, works out any discontinuity between comments, resolves everything, updates to the next version, and sends it out for final consensus and approval. A couple of days later, a response trickles in from the first draft with many of the changes reverted and with many new changes added. The response is from a person whose response cannot be ignored. Yet those of you reading this know this is how it happens in your organization far too frequently.
To paraphrase a very old political saying, email is the worst possible way to collaborate except for every other way. But this doesn't have to be the case - and you may already have the solution installed. SharePoint 2010 can provide a relatively simple way to track and manage project schedules, deliverables, and collaboration. Now, this is not meant to be a SharePoint commercial, and indeed there are a number of other solutions that can do this as well. I picked SharePoint for two reasons: it's probably already in use at your organization, and we have a
course on how to use SharePoint as a collaboration platform.
The bottom line is that instead of using network shared folders + email to collaborate, there is a better way to do it using custom lists, document libraries, and project or team sites. Content types can be set up to enforce consistency in the creation of documents, and in some cases authors might be able to co-edit documents in those libraries in real time while ensuring information isn't overwritten inadvertently. And alerts can be set up to notify team members when a document is added or updated, when a meeting is scheduled, or when a milestone is about to be met (or not!). This is in fact the process we used in developing the SharePoint for Collaboration course - eating our own dog food so to speak.
The point of collaboration is not collaboration - the point of collaboration is to get the work of the organization done by the people who need to get it done as efficiently as possible. SharePoint provides organizations one option to do this and one that is far better and more efficient than email.
#ContentManagement #2010
#collaborative #documentmanagement #project #sharepoint
#SharePoint #ProjectManagement #Collaboration
#Collaboration #ECM #collaborate