Today, the practice of medicine is becoming more sophisticated and multifaceted so that the majority of physicians are struggling to keep up with the system demands. The contemporary Value-based reimbursement models have placed the added burden to doctors’ daily clinical work, some to the extent of quitting, burnout, and even suicide.
The administrative burden is not unique to healthcare; nevertheless, the medical community and health industry as a whole is significantly lagging behind others for adopting new practice modalities. The reason for this lag is the subject of another discussion; however, it is real and worrisome. Although the lingering of practice reform and the increased burden is more pronounced within the United States, nonetheless it is expanding to other parts of the world as well, as part of an interrelated global initiative.
Large healthcare systems have already started implementing more modern management strategies, but independent medical practices are far from being in synchrony with those at the top of the corporate network. But- Physicians must change too!!!
For almost a century, other industries have designed, implemented project management methodologies to overcome several process barriers and become efficient and productive. As mentioned earlier, large healthcare systems have adapted and shaped some of those tools in their operations as well. Since the contemporary healthcare system hardly discriminates between small and large medical practices, it would be just to state that the independent physicians would surely benefit from some form of project management means.
In my earlier articles, I tried to list a few of the most common project management methodologies and their utilities in medical practice. In this piece, I would like to expand on one of the most traditional tools, the so-called “Waterfall” project management Methodology.
Waterfall Modality is about the breakdown of the project based on Activities
The waterfall methodology is about breaking down the project functions into continuing linear yet, sequential phases, where each particular stage relies on the deliverables of the previous step and matches to a specialization of responsibilities. The approach is ideal for specific areas of an engineering perspective, as it is exhibited in Fig. 1.
As valid for many other project management tools, some industries, such as software development is amidst the less iterative and flexible approaches, where progress flows in one direction. Hence “downwards” schemes like a waterfall drives the project from the conception phase through initiation, analysis, design, construction, testing, deployment, and maintenance.
Related: The sway of individuality for the benefit of mainstream and sake of rebellious minority
The waterfall methodology was initially introduced in the manufacturing and construction industries, where the profoundly structured physical settings indicated that design modifications became prohibitively costly much sooner in the development process. During the initial introduction for software development, there were no identified dilemmas for knowledge-based creative work.
History of Waterfall Methodology
The earliest recognized waterfall technique described the use of phases above in software engineering was upheld by Herbert D. Benington at the Convention on Advanced Programming Methods for Digital Computers on 29 June 1956. In 1983 the article was republished with a foreword by Benington demonstrating that the phases were deliberately organized according to the specifications of assignments and pointing out that the process was not in fact implemented in a strict top-down order- but depended on a prototype.
As the name describes the Waterfall Model follows a particular Downflow Order
The first approved report of the waterfall model is often cited as a 1970 paper by Winston W. Royce, even though Royce did not use the term waterfall in that provision. In Royce’s original waterfall model, the phases followed were:
● System requirements caught in a product specifications document
● Analysis culminating in models, scheme, and business rules
● Design under the architectural plan of the system
● The development, demonstrating, and integration
● Testing that embraces systematic discovery and removal of errors
● Operations of the installation, migration, support, and maintenance of complete systems
All in all, the waterfall method states that- one should only move the next phase lone when its preceding stage is reviewed and validated.
The United States Department of Defense implemented the waterfall approach in 1985, as the DOD-STD-2167A. The latter remained their standard for working with software development contractors, which stated that “the contractor shall realize a software development cycle that incorporates the six phases of Software Requirement Analysis, Preliminary Design, Detailed Design, Coding, and Unit Testing, Integration, and Testing.”
Supporting Arguments for Waterfall Scheme
Time spent early in the project delivery cycle can reduce costs at later steps. In other words, a problem encountered in the early stages, including requirements specification, is more affordable to repair than the same bug found later on in the process. This is very much true for the waterfall methodology.
In standard practice, waterfall methodologies end in a project timetable with 20–40% of the time devoted for the first two stages, 30–40% of the third phase, and the rest dedicated to testing and execution. The actual project organization needs to be vastly systematized. Most medium and large projects will comprise a comprehensive set of procedures and controls, which regulate every process on the project. Besides, the waterfall model tends to put importance on documentation, such as requirements documents and design documents. In less than optimal design and documentation scenarios, knowledge can be lost if team members drop out before the project is concluded, thus it may be challenging for a project to recuperate from the loss.
If an adequately working design document is existent new team members or even entirely new teams can familiarize themselves by studying the reports.
The waterfall model renders a structured method; the model itself progresses linearly through discrete, easily understandable, and explicable phases and thus is easy to comprehend. It also provides effortlessly identifiable milestones in the development process. For this reason, the waterfall model is used as a beginning example of a development model in many software engineering texts and courses. It is claimed that the waterfall model can be suitable for projects where requirements and scope are static, the product itself is firm and enduring, and the technology is articulately recognized.
The Application of Waterfall in Medical Practice
In healthcare, many people are not only familiar with a waterfall approach but also comfortable using it in their day-to-day activities. This is particularly accurate for healthcare executives who aspire to observe a sequence of assignments laid out from inception to end organized in a Gant chart, providing a visual summary of the project.
Using the waterfall methodology, management can see a timeline of events, hence will have a reasonable sense of how long every phase of the project is going to take. Waterfall project management is efficient in communicating the overall project scope, tasks, and timeline, but it also has its particular pitfalls.
Criticism of Waterfall Methodology
Not every client of the Waterfall may grasp precisely what their requirements are before they see a working product or solution and so may end up changing their needs frequently, leading to redesign, redevelopment, and retesting, and mounted expenses.
Designers may not be cognizant of impending intricacies when designing a feature, in which case it is healthier to revise the design than persevere in a model that does not account for any newly discovered limitations, specifications, or enigmas.
Organizations may strive to deal with a shortage of robust requirements from consumers by employing systems analysts to examine existing manual systems and analyze what they do and how they might be substituted. Notwithstanding, in practice, it is difficult to maintain a strict separation between systems analysis and development. This is because realizing any non-trivial system will almost inescapably exhibit problems and edge circumstances that the systems analyst did not acknowledge.
Waterfall project management has a distinct track record in completing large-scale schemes, but these projects are often over budget and behind schedule. Stakeholders can also be discontented with the end result because they are typically not as intimately involved in the process and don’t observe final results until the project is concluded.
With the increasing economic pressures met by healthcare systems, it’s more imperative than ever to deliver faster results with continued involvement and feedback from stakeholders incorporated throughout the process. That is why, the lean methodologies such as agile project management can be employed by process improvement teams to achieve speedy, high-quality outcomes.
Disadvantage Waterfall in Healthcare
The Waterfall is a rigid methodology, where its roots go deep in industries such as manufacturing and construction, where the inflexibility emerged out of demand. For example, a builder can’t paint a room before installing drywall. Nevertheless, with the interpretation of Waterfall to other applications, such as software development or in process improvement projects such as healthcare, the rigidity is frequently challenging and can delay a project, both in terms of agility and efficiency.
With healthcare process improvement projects utilizing a waterfall-only approach, it can be challenging to stick to a continuous, step-by-step process of a project from commencement to end. In fact, most improvement projects are iterative in essence and use Plan, Do, Study, Act (PDSA) cycles of iterations. The PDSA cycle allows teams to repeat, emphasize, and show progress beforehand, with a much better outcome, where the client is more contented with the end finish.
Related: The Modern-day Solo Medical Practice needs more than just a Technology
Modified Waterfall Models may be better for Medical Practice
In response to the recognized predicaments with the “classic” waterfall method, various industries have modified versions or hybridized them with other methodologies. Specific models may spout a few or all of the critiques of the “pure” waterfall methodology. Those cover the Rapid Development models that Steve McConnell of Microsoft calls “modified waterfalls” or that od Peter DeGrace’s “sashimi model,” which is a waterfall with overlapping phases. Many other modified versions of the Waterfall exists today, which would be out of the scope of this inscription.
Possible Hybrid Models for Medical Practice
Due to the stringent nature of the Waterfall methodology, this project management tool, in its simple format, has limited utility in an archetypal medical practice. However, It can be of significant use if combined with one or more other methodologies, such as Agile and Lean schemes. All-in-all whichever methodology used is not as relevant as achieving quality results on time within a reasonable budget. And- that irrespective of the method used, any project management tool will ultimately work, provided the user adheres to it, and makes sure that the team understands and is comfortable with the methodology.
Choosing the Right Combination of Methodologies is the Key
While trying to choose the right methodology for a medical practice, one must consider several factors
- Whether all timelines, resources, and budgets are identified ahead of time
- What methodology the client is familiar with, and what they are currently using (If they do)
- It is also important what the project manager is comfortable with and the type of methodology the client is comfortable
Waterfall and Agile Hybridization:
Agile is flexible and accommodates short timelines or when the deadline is ever-changing. It is a reliable tool for projects such as in healthcare where requirements are evolving, and specifications are subject to unexpected changes. Agile has Higher end-user satisfaction than other methodologies, as they see the project development right before their eyes along the way. But it is very complicated for budget approval owed to its volatile and ceaseless nature with no fixed defined completion date. That is why not every program is fitting for this methodology.
Waterfall, on the other hand, as discussed earlier, performs best when the timelines, resources, and funds are identified upfront.
Due to its long history, most patrons are all familiar with the waterfall project management methodology. For the reason that the end-users do not usually see the result until the conclusion of the project, it carries lower end-user satisfaction than the Agile.
Waterfall generally requires optimization after the project is completed, but It holds articulately established upshots. Scope steal can be costly and can negatively influence the timeline.
The Interface Management Resources in hybridizing Methodologies
An “interface project” would fit conscientiously into the Waterfall methodology. Because, If we look at a conventional interface project, we usually have funds for the interfaces and resources along with specific due timelines.
To clarify, an interface is merely defined as a point of relating between entities working on a particular project — for instance, different departments, domains, or skills working to better health outcomes for diabetic patients.
An interface project can pertain to a Physical interaction between components; it can be a functional requirement among systems or Interactions between subcontractors/suppliers. In specific industries such as healthcare and medical practices, interface projects may refer to an organizational scheme where information exchanged between disciplines, Knowledge/information exchanged between parties, or even resource shared between the points of dependencies between equipment, material, and staffing agencies.
Since interfaces have the potential to undesirably influence the cost and schedule of the project, therefore, Interface Management typically serves as the method of managing interfaces and alleviating those risks. However, in the downside, as the number of various entities and the scope of a project increases- so does the risk associated with interfaces, such as helping assure the proper communication and transparency between various interfacing sub-systems.
A Typical Project Management scenario for Medical Practice Application
Let’s assume a medical practice is planning to implement a new service. The facility has brought in three physicians partners into this new program to modernize and render a state of the art service. However, their existing Electronic Health Record System (EHR) doesn’t offer the necessary workflow they need and optimal use of the patient’s record, therefore necessitating a great integration effort which includes the following:
EHR optimization and workflow changes that involve designing and building a new system, introduce EHR’s requiring Interfaces, new third-party applications with interfaces and API (Application Program Interface).
The reforming clinic must also acquire one portal view for all of the above for the clinical staff. Most importantly, the client has no fixed timelines, has changing requirements, and no budget allocated to their transformation, as yet.
The Medical practice has utilized the Waterfall and was a failure due to constant scope changes and unfolding requirements. Then also tried Agile, with no success, due to the unfamiliarity of their staff with the latter methodology. This is a scenario where this medical practice may benefit from combined approaches. Under such circumstances, steps of Plan, Design, Build, Test, and Deploy can use the waterfall scheme. Then one can place each mentioned steps into Agile Sprints/ or Quick Wins termed “Bundles.” (Fig. 2) Using this method, each month, the project administrators would roll out a workflow, EHR functionality, and integration bundles, which allow clinical staff to give the project management necessary input and feedback along the way and observe the progress regularly. If the clinical team encounters a problem with something, management will resolve it in the subsequent bundle.
As you can witness, despite failures with the Agile and Waterfall methodologies individually, combining the latter two based on the client’s requirements and resources, the hybrid project management plan ultimately created a system where upshot was an ample success. Besides, the clinical staff is now observing progress and feels understood. Figures 3, 4 and 5 demonstrate three other waterfall/ Agile hybrid scenarios
The best Project Management Tool is the one that addresses the particular Need
Project management is no longer for the Tech industry. Amidst all the challenges and frequent churning of healthcare regulatory mandates, it seems to us that the traditional yet straightforward clinic work will not sustain the medical practice of the 21st-century. An efficient project management tool was, -is, and -will come even more handy in years to come. Not to mention, patient expectations are on the rise and technology at hand, every industry, be it small or large, are relying on some form of project management methodology.
Any Project management methodology can be useful and productive as long as everyone involved in the team follows it and adheres to it. In the end, the method is trivial to delivering quality outcomes on time and under budget, but choosing the most suitable methodology for a project will help contribute to the medical practice owner’s timeliness and the ability to stay within the means of their resources.
Related: Disclosure and Resolution Program
