Making the Project Scope Useful, not Useless

Many years ago, we noticed that most sites develop Charters and Scopes and Implementation Visions - nicely bound and impressive to view from a distance.  But once they were written, they collected dust and were never referenced again - certainly not what most would consider useful project documents.  The problem was that very few people ever referenced these items, and they were not widely shared among the stakeholders, let alone the project team.

We also noticed that vendors would provide a Scope Document as part of the purchase.  These Scope Documents stated WHAT you bought, but did nothing to state HOW you would use them in your organization.  Integrated systems are highly flexible, and how you choose to use them can vary greatly from hospital to hospital.

So, projects would march along feeling comfortable because there was a Charter on the credenza in the CIO’s office and the vendor had provided a Scope Document.  Here’s where the problems would begin.  Part way into Design, nursing might say that they need 25 assessments built, and Pharmacy feels that they could benefit from 5 or 6 as well.  How about 50 or 60 ordersets to go along with that?  And a couple dozen reports.  After all, you did buy a report writing utility.  Your project has now encountered SCOPE CREEP, and you are still in Design mode.

At Atlanticon, we believe in providing a Common Sense approach to projects.  Projects should not be measured by the pounds of documents created, but rather, the ease with which your team can carry out their duties and the quality of your finished product.  In order 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
• Who will use it
• And exactly How it will be used

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

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

Finally, you want a Scope Document to be bound, approved, and signed by all the Stakeholders before your project begins.  This keeps your project from creeping into the next 3 years.

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, who will each receive their orders across an interface and 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 interface and perform their duties, as outlined in the section specific for their systems.

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

And if your plans change slightly during the Design phase, the Scope Document should be revised and the revised section clearly marked, following approval by your steering committee governing 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 should expect, helping answer the common question, "Will my printer or 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 / referenced repeatedly.  And by obtaining the necessary approvals, your scope can't change without the impact being escalated to the Executive level for approval.  Furthermore, anyone in your organization can read and understand your project.

Keep in mind that Charters have a place—they serve as a starting point and a vision for the project.  And Scope Documents from the vendor serve a purpose, telling you what you have contractually purchased.  However, there is not enough detail to make it clear to everyone what the limits are.  Scope Documents are all about setting clear limits and providing definition.  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 gives you limits.  And make sure the vendor agrees to it—you don’t want to document that you’ll register patients in 15 locations if the vendor was of the understanding there would be 2 points of registration.

Document it, get it approved, bind it, and get all stakeholders to sign it.  The Scope Document will help keep your project on track.

No related posts.