In many development organizations, software developers use Microsoft Word to communicate and gain consensus on important information, such as requirements, specifications, test and validation plans, and marketing collateral. Critical to project success and the customer validation of product requirements, these technical documents are shared with other project stakeholders—product managers, engineers, project managers, marketing staff, and support and QA professionals—who edit, annotate and send document versions to each other for feedback. Making these documents available to colleagues and requesting feedback is a necessary step to ensure that the team knows what they are building. And sometimes you feel like the guy in the picture.
Anyone in development can tell you that at least a few requirements will be changed during the course of the development phase. When these changes occur, it becomes even more important for stakeholders to review them and understand the scope and ramifications of those changes. Whether you use waterfall or more Agile methodologies, requirements drive development effort and shape the final result. So reviewing these documents early and often throughout the coding phase is critical to everyone being on the same page, and delivering valuable software.
There are only a few ways, however, to share and solicit technical document feedback. If you are not scheduling formal inspection meetings or using a document management system (which forces you to review serially), then you are likely using Microsoft Word to create these documents and artifacts and email to distribute them to team members. In this quite typical situation, development teams rely on Microsoft Word as both a document authoring tool AND a document review tool. Their challenge is that Word was designed as a document authoring tool, not a review tool. Because the document editing process is not centrally managed in Word, document authors need to navigate through tedious email feedback. This process is not only confusing in larger teams, but it can lead to significant mayhem – especially when critical feedback is overlooked, contradicted, or even ignored.
Because PeerReview Complete is purpose-built for document review, it simplifies the review process, eliminates lengthy email trails, and ensures compliance with electronic signatures. Let’s take a closer look at how PeerReview Complete accomplishes these goals.
Document Review, The Problems with Using Microsoft Word
|Document Review using Microsoft Word||Document Review using PeerReview Complete|
|Reviewers may edit outdated document versions||Documents are centrally managed. All reviewers see the exact same, always current document|
|Reviewers can’t see each other’s comments (unless they check in/out doc and modify only one, centrally stored doc), and authors can’t see all the comments in one place||Reviewers use threaded contextual chats and can see each other’s comments in real-time|
|Emails cross, causing overlapping threads and confusion||There are no emails to cross. All threads are maintained in one place|
|Review meetings that gather the team together are challenging to schedule||Teams can review documents synchronously or asynchronously. Meetings are not required.|
|Comments are deleted and lost||Comments are permanently logged. Defects are tracked through resolution.|
|Microsoft Word does not gather metrics||PeerReview Complete gathers metrics automatically|
|Lacks inherent document “sign-off”||Enables electronic signatures for key stakeholder document sign-off|
|Documents in email can be accidentally forwarded to the wrong party||Documents can be downloaded and forwarded in email, but not accidentally|
PeerReview Complete makes the documen review process easier and faster and ensures that all comments are preserved in one location. Meeting regulatory and compliance mandates just got easier with PeerReview Complete’s unique document review and electronic signature capabilities.
Learn more about PeerReview Complete.