Creating a Useful Project Scope

Articles / Tips

Creating a Useful Project Scope
January 10, 2020

If you’ve ever been involved in an EMR project, chances are you understand the gravity of a proper Scope Document. Documenting the specific what, why, where, who, and how at the onset of a project is time very well spent.

What does a suitable Scope Document do? It serves as the blueprint and parts list for your project. It carefully lists every factor impacted by the project and how. Say your project includes a Registration/Admitting component; your Scope should list all the departments that will be involved. Will you be registering patients in your lab, the clinic, or the ED? Are you expecting the project to interface with other systems? Will you be producing face sheets or using signature pads?

Outlining all these details in advance helps you ensure that you understand the magnitude of tasks, avoid forgetting a key department during the Design phase, and get an idea of the equipment needed. A solid Scope Document ensures that the vendor is aware of which departments must be included. Most importantly, it prevents serious issues from arising late in the project: maybe you hadn’t considered an interface, forgot a department, or failed to address some technical requirements—any of these would prove disastrous for a fast-moving project.

This is a good time to discuss the vendor’s Scope Document. Many hospitals believe that the vendor will develop their scope. And many vendors do provide a “Scope Document,” but when you look closely you’ll realize that it’s more of a parts list than it is a true scope. They’ll tell you that you’ve purchased the Admitting, Nursing, Radiology, and Lab components. They may even address the number of users or equipment estimates. It will give you the what and maybe a bit of the where, but the why, who, and how are sorely missed.

At Atlanticon, we believe in providing a common-sense approach to projects. Projects should not be measured by the volume of documents created, but rather the ease with which your team can carry out their duties and the quality of your finished product. To aid in this, we encourage all hospitals to create a Scope Document that explains your project, not your purchase. It should cover:

  • >What you’ve purchased
  • >The primary function/purpose of each purchased item and why it’s needed
  • >Who will use it—and where
  • >Exactly how it will be used

You also want a Scope Document to cover ALL new components, such as:

  • >New Systems
  • >New Applications
  • >Support Tools
  • >Hardware
  • >New Interfaces
  • >Conversions

Finally, you’ll want your Scope Document to be bound, approved, and signed by all the Stakeholders before your project begins. This keeps your project on target because you will have eliminated surprises, which tend to come up at all the wrong times!

Atlanticon believes that a proper Scope Document should address purchased modules as follows:

  • >Application: Order Management
  • >Function: Allows the tracking of all orderable items and provides clinicians a method for requesting items and services electronically, generating an interface message to outside systems and/or printing requisitions in the providing department.
  • >Used By: In our project, nurses, unit clerks, and doctors will be placing electronic orders to Radiology, Lab, Physical Therapy, Nutrition, and Cardiology. Paper requisitions will print in all these departments, except for Lab and Radiology, which will each receive their orders across an interface and then generate requisitions from those departmental systems.
  • >How Used: Each of the departments will perform their duties based on these orders, with Cardiology and Physical Therapy generating automatic charges as a result of the order. Nutrition will generate worklists to assist them in filling trays. Radiology and Lab will receive these orders via the interface and perform their duties, as outlined in the section specific to their systems.

Each application, each interface, and each conversion should be similarly spelled out.

If your plans change even slightly during the Design phase, the Scope Document should be revised, and the revised section clearly marked, following approval by your steering committee that governs scope changes.

Another example of how a Scope Document can benefit you comes in the area of hardware. This document should state what types of new hardware the users can expect, answering the common question, “Will my printer/workstation need to be updated or replaced?” By stating this upfront, your technical team has a clear guideline on who gets new equipment.

A Scope Document is like a Project Plan—it’s created once and maintained, reviewed, and referenced repeatedly. By obtaining the necessary approvals, your scope can’t be altered without the potential impact first being approved at the Executive level. Furthermore, anyone in your organization is able to read and understand your project.

Scope Documents are all about setting clear limits and providing a definition. This includes specifying what systems are involved, what departments are involved, what applications will be used, what interfaces will be in place, what type of equipment will be used, etc. Read your Scope Document carefully and determine if it clearly defines limits. And make sure the vendor agrees to it—you don’t want to document that you’ll register patients in fifteen locations if the vendor believes there will be only two points of registration.

Document it, get it approved, bind it, and get all stakeholders to sign it—and let your Scope be the blueprint for a smooth project.

Leave a reply

Your email address will not be published. Required fields are marked *