Portal Power

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.