Like most companies, InterKnowlogy is a treasure trove of knowledge. But,
3 years ago, a large chunk of that treasure lay buried in the Carlsbad, California,
software-development firm—hidden in obscure folders and files on the network
and employees' PCs, in email threads, and in the minds of employees and outside
contractors. In 2002, the company began using Microsoft's collaboration tools,
Windows SharePoint Services and later, Microsoft SharePoint Portal Server, to
make that knowledge easier for employees and contractors to access and share.
In a conversation with senior editor Anne Grubb, Lacie Russell, network engineer
and overall IT support person for InterKnowlogy, explains how the company's
SharePoint setup works, how SharePoint has benefited Inter-Knowlogy users, and
a few helpful-to-know SharePoint "gotchas."
What motivated InterKnowlogy's move to SharePoint? What applications were you
using previously that you wanted to replace with a portal?
We were using a custom Active Server Pages (ASP) Web site to host our employee skills matrix, which contains employees' certifications, skills, and other information, such as email addresses and phone numbers. All this information was in the form of little pages that were added to this custom ASP, which a couple of our developers worked on here and there. You had to add new employees to the database manually via SQL Server Enterprise Manager, which was very tedious. We also had a lot of information out on shared folders, and things were hiding on peoples' desktops and workstations. Everything was in pieces everywhere.
We started using Windows SharePoint Services in Microsoft Office Project Server;
when you use Project Server, it creates a Windows SharePoint Services site for
the project. We used the site to store all our project deliverables. When the
SharePoint Portal beta came out, we started playing with it. We started using
SharePoint for more projects—we were using the Beta 2 at that point—and
decided to use SharePoint [from that point on]. Now we use both SharePoint Services
(in Project Server) and Share-Point Portal Server. (Web Figure 1 at http://www.windowsitpro.com,
InstantDoc ID 48953, shows InterKnowlogy's SharePoint home page.)
What's your typical process for a development project, from beginning
to end, and where does SharePoint figure in that?
After we have a project start date, we use Project Server to create
a project schedule and create a Windows SharePoint Services site, which contains
everything pertaining to that project. The site contains premade lists, which
we've customized for our own company, that have information such as issues and
bug-tracking data as well as entire documents such as deliverables, the statement
of work, and any signed contracts.
At the project kickoff meeting, the program manager gives everyone on the project
a link to that site. As an administrator, I can delegate permissions to the
program manager to maintain the site—adding users, for example—which
is cool because it means I don't have to do it. The developers can go to the
site and create discussion lists, look up contact information for the client...
they can go through any information that the program manager puts there. Having
the information in one place saves a lot of space on email. You don't have those
long discussion threads.
What other applications have you enabled through SharePoint?
We use Windows SharePoint Services with Microsoft Office InfoPath
2003—we're in the process of moving our vacation-request application to
an InfoPath form. A user goes to the Web site, selects the vacation request,
fills it out, and submits it. The form automatically goes into the library,
and the manager can go in and approve the time-off form.
SharePoint is also a great knowledge base. Say a developer finds a solution to an issue that he or she has been working on for weeks. The developer submits it to a list that we created—the knowledge base. Each entry contains links to a description of the problem, the solution, and the problem's cause. If someone else has that problem, he or she can search in the knowledge base and find that information without spending time trying to figure out what's wrong.
I also use SharePoint to help me handle IT support issues. When someone has
a support issue, they fill out a form on the SharePoint site and tell me what
the issue is and the expected due date for resolving it. I can go into SharePoint
and see my list of support-task items. I also have another list for my manager
to see what tasks I'm actually working on and where all those processes are.
Using SharePoint in this way saves me a lot of time because I don't have to
have an hour-long meeting with my manager to tell him where I am on my task
list. He can just go to the list and see where I am on each project. And users
can go to the issue items that they submitted and see whether they've been completed
or whether I need more information from them to solve the problem.
So the information is on one site that everyone can access, not locked
away on someone's computer. That knowledge is always available, even if you—the
"keeper" of that knowledge—aren't.
Yeah. I can actually take a vacation and not worry about whether
I forgot to tell somebody something important before I left. It's all there
in the site.
Have you encountered any "gotchas" while using SharePoint?
One gotcha is that for someone who's never seen it before, Share-Point
takes a little getting used to. End users might be used to getting information
in a certain way, and SharePoint looks different. But once you get a hold of
it, it's actually quite easy to remember because everything is the same on the
UI. For example, certain links are always in the same spot, unless you customize
the UI a lot. From a deployment perspective, getting SharePoint to work with
certain applications can be tedious. For example, we want to integrate SharePoint
Portal Server with Active Directory (AD), so we're building a Web Part that
will let us manage AD through the portal. This type of stuff can consume a lot
of time.
Previous
