|
A key weapon in your project management arsenal, the project office provides teams with access to key people, tools and information. It should act like a library, information desk and tool shed all rolled into one. It usually takes the form of a web site, or portal, and supports team collaboration.
In truth, most of these fads were just common sense repackaged in a lot of intimidating jargon. They have been forgotten for good reason.
It's with a skeptical attitude that I approached my first introduction to a true "Project Office" a few years ago. "Oh sure," I thought, "Another meaningless phrase. Sounds like a pretentious name for a wall covered with Gantt charts that no one ever looks at." Within one week, however, my skepticism had evaporated. Even though it was poorly implemented, the project office enabled teams on three different continents to quickly share information, identify problems and manage changes. The project office has now become one of the key weapons in my project management arsenal.
What Does It Really Mean?
The short definition is that a project office provides the team with access to key people, tools and information. Ideally it should act like a library, information desk and tool shed all rolled into one. In practice, it usually takes the form of a web site, or "portal," which provides email and retrieval of documents like schedules, specifications, design documents and test scripts. In short, the project office supports team collaboration.
From a technology standpoint, a project information portal is pretty mundane. However, the benefits in process improvement and teamwork can be huge.
You Pull, I Push
In the absence of a central, accessible project office, most information is "pushed" to the members of the project team. Notes are emailed or faxed the day after the meeting, drawings are sent when the engineer decides they're ready and the project manager produces schedule updates each week. In short, documents are transmitted when the producer of the information is ready rather than when the consumer of the information needs it. The result was that everyone had to filter through his inbox every day, picking out the important information, filing anything that he may need in the future and hoping that he doesn't lose it before then.
By contrast, a central project office repository enables the information consumer to retrieve documentation selectively when he needs it. This results in three significant benefits:
- Time savings, because everyone doesn't have to look at every document that is published.
- Improved communication, because people naturally retain more when they're reading something of immediate interest.
- Improved ownership and accountability, because the information is pulled instead of pushed. Rather than depending on others to give him information, the project team member is responsible for gathering the material he needs, provided that it has been made available to him. No more "I never got your email."
The Master Plan
The single most important document in the project office is the master project plan. This should show the overall project schedule as well as the critical dependencies between different project teams. On smaller projects (less than 200 tasks or 2000 man hours) the master schedule may be the only workplan used. On larger projects, however, there should be individual project plans for each major vendor team in addition to the master plan.
Don't make the mistake of simply "rolling up" the individual project plans to create the master. Instead, create a separate master plan that contains milestone links to the individual plans. This is necessary for two reasons:
- The vendors (rightly) structure their plans to be meaningful to their teams. But tasks that are important to them may not be significant to the end client. For example, the conveyor installer may break out tasks involving structural steel, pneumatics and electronic controls, while the end client only cares about a fully working conveyor section. The vendor may consider "mechanical installation" to be an important summary task, while the client wants to track "lane 1 conveyor operational" as a key milestone.
- The vendor plans don't track cross dependencies. The electrical contractor may not know that the size of his conduit will affect the location of a divert gate. The carousel supplier may not realize that changing the number of storage positions will affect the control software. A central master plan is required to coordinate these cross-team dependencies.
The master plan should include two types of tasks: key deliverables that are important for the end client and cross dependency tasks for which one vendor depends on another. The end client deliverables should be significant milestones that, viewed together, will provide a realistic picture of progress.
- As much as possible, assign a clear "deliverable" for each task so that completion is absolute and obvious. For example, rather than naming a task "consult with Mary," call it "Mary Signs off Checklist." This forces you to get very clear about what you want from Mary (because you need to create a checklist) and also ensures that task completion is obvious (you either have a signature or you don't).
- Make tasks "all or nothing." Don't allow your team to assign intermediate completion percentages to individual tasks. Instead, leave each task 0% complete until its "deliverable" has been provided, at which time it goes to 100%. If you determine your overall progress by summing up many individual tasks (75 of 100 tasks are completed) it will be much more accurate than a subjective measure of a few tasks (each of our four items is about 75% done). This technique also forces the team member to focus on fully completing a few things at a time.
We recommend that cross dependency tasks on the master plan include "task by" and "task for" values. The "task by" field is simply the vendor team or individual who is responsible for ensuring that the task is completed (often not the same as the people who actually do the task work). The "task for" field indicates that vendor team(s) who is dependent on the task. Each vendor should verify that its key dependencies are included on the master plan. If a cross dependency task is late, everyone can easily see who may be affected by the delay and the affected parties can take action to minimize the impact.
Other Content
In addition to the master and individual project schedules, the project office should provide access to documents such as status reports, specifications, design documents and drawings, meeting notes, test scripts and project correspondence. Although you can get very sophisticated in organizing this information, the only critical element is a well-defined set of guidelines for managing the documents. These guidelines should include a description of the directory structure, file naming conventions, file ownership and document posting responsibilities.
Unless you have a solid document management system with security features, we recommend that all documents available in the project office be duplicated in a non-accessible location and, of course, be backed up religiously.
Getting Fancy
The basic file repository and email capabilities described for a project office so far can be implemented with a simple "extranet" or "portal" website. The only critical technological requirement is user security to prevent unauthorized access.
A little more technology, however, can provide powerful additional features such as:
- Searching capability. Inexpensive search engine software can enable your site users to find instances of text strings just like the search engines on the World Wide Web. For example, a team member could find all project correspondence involving the "shoe sorter" without having to look through every document.
- Document version control. Versioning software records when documents are posted, tracks edits by user and manages permissions. It also prevents two users from updating the same document simultaneously. With this capability, different team members can mark up an engineering drawing without overwriting each other.
- Document workflow automation. This functionality is typically used to automate an approval process. For example, a change request could be routed to the affected vendor for a cost estimate, then to the end client for approval, and finally stored as a finalized change, with email notifications automatically sent to key managers. While it can get complex to configure, workflow automation can add valuable discipline to what is often a chaotic process.
- Web cams. Using an inexpensive digital camera, a web cam can give the project team a real time view of the job site or project status board. Posting a set of digital pictures of the installation can help team members visualize the operation and even avoid physical conflicts, potentially saving site trips.
Of course, there are many other technologies that can support collaboration, including instant messaging, video conferencing and net meetings. In most cases, it is best to purchase these capabilities as needed rather than incorporating them into the project office. In general they do not provide an "information stream" that can be easily captured and stored for future reference. Also, they are usually much cheaper to buy than to build (e.g. instant messaging is free).
Implementation Tips
Although straightforward, the technical details of creating an automated project office are beyond the scope of this article. (Please feel free to contact
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
for more information.) However, we can offer the following suggestions for getting started:
- Keep it simple. It's unrealistic to expect vendors to radically change their processes or invest a lot of money for a single project. The best way to accommodate many players is to limit the level of integration and use the "lowest common denominator" technology. For example, if some teams use AutoCAD and others use Visio, try having everyone post their drawings in Adobe Acrobat format so that they can be viewed by anyone using this free software.
- Use outside help. If you have never created an extranet website, hire someone to do it for you. The cost will be much lower than trying to figure it out yourself and you may be able to learn enough from the experience to do it on your own next time.
- Look at third party options. There are many free and low-cost services that can provide much of the technology you need. Check out www.onproject.com, www.eprojects.com and www.netdocuments.com. Just remember, these services could change or go out of business at any time.
This article was prepared for the Material Handling Equipment Distributor Association (MHEDA) Journal. Although the examples in the article are targeted toward the MHEDA membership, the concepts and recommendations are applicable to any industry.
Steve Deist (
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
) is responsible for the Operations Practice at Indian River Consulting Group, and is available to speak on this and other distribution topics. IRCG is an experienced based firm specializing in distribution issues for business-to- business distributors and manufacturers. The firm was started in 1987 by J. Michael Marks and is well known for helping companies achieve competitive advantage. You can contact them by calling 321-956-8617, or visit www.ircg.com for more information.
Copyright © Indian River Consulting Group LLC. All Rights Reserved.
Please contact Sandie Stewart at
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
for republishing permission.
|
