- Getting to Business Value
- Developing a Model of Your Customer Relationship
- Setting Business Goals
- Setting Requirements: Who, Where, What, and Why
- Organizing and Publishing Project Documents
- Prioritizing Requirements
- When Requirements Should Bend
- Knowing Your Boundaries
- Making the Business Case
- Quantifying the Return
- Developing a Straw-Man Schedule
- Avoiding the Big Bang Project
- Outsourcing
- Setting Executive Expectations
- Getting the Right Resources Committed
This chapter is from the book
This chapter is from the book
This chapter is from the book
Organizing and Publishing Project Documents
Even before the project begins, best practices call for storing, publishing, and organizing the project’s documents online. Put them in an intuitive hierarchy, with all the project-related documents in one place that is scanned by an internal search engine or a desktop index (such as Google’s free desktop search or X1’s indexer) and is backed up regularly.
You can store these documents in a shared folder on a file server, but even better is to have them in an intranet site. Best of all would be a wiki3 that’s accessible to all team members (including contractors). Your top-level wiki “article” should include pointers to the project schedule, the current phase’s goals and nongoals, project personnel, news, discussion forums, blogs, and user tips on the system. The wiki should also provide a hierarchical library that includes all of the requirements documents, discussions, rationales for priority calls, and the project requirements phasing spreadsheet.
The wiki should be “Information Central” for the project, so any relevant information should be available there, including team members’ contact information, email aliases, email/discussion archives, cheat sheets, podcasts, WebEx sessions, screen cams, and internal success stories. By making it really easy to get to and find all the current project information, you’ll be on the road to clearer communications, better expectations management, and a much lower chance of confusion throughout the project.
You should also put a short document into SFDC’s Documents section describing how to get to the file server or wiki. Promoting what’s there will allow any interested user or project team member to quickly become better informed.
It’s usually best that these documents be editable Word files, with change tracking turned on. For Excel files, the first page of the spreadsheet should include a revision history indicating who changed what and when. The files should be downloadable by any authorized user, but should be updatable only by sending the changes through the project manager. In this way, the project manager can filter and prioritize input and manage the evolution of the requirements and other documents (which inevitably change throughout the project).
Documents should never be deleted. Obsolete documents should be marked as such and moved to an archive directory.
For certain kinds of files, it’s useful to leverage the shared editing and shared access of Google Docs. Although the files have to be much simpler (no macros or heavy formatting), Google Docs sharing can improve collaboration in a distributed implementation team. This is particularly true for status documents, priority lists, or other highly collaborative content. SFDC has recently created an integration with Google Docs that makes this option even more tempting.