No one likes to be the person at the table who is constantly talking about trimming project requirements. Call them a buzz kill, but it’s important that someone (ideally multiple people) on a healthcare integration project is willing to play the “bad guy” by keeping scope top of mind. This is especially valuable when making critical decisions as third-party dependencies slip or unresponsive resources put the timeline at risk. Knowing what steps are vital to delivering the Minimum Viable Product (M.V.P.) is one of the best ways that technology partners supporting an integration project can encourage forward momentum where it counts.
Today we’ll discuss some key points that drive home the necessity of drawing a line in the sand in terms of what’s considered within scope for MVP, and knowing when to put anything else in the icebox.
Everyone Wants Everything Yesterday When It Comes To Health IT Projects
You wouldn’t be putting in the work (or the budget, let’s be frank) to make changes to the technology infrastructure of your health system if the effort wasn’t needed (even if for future needs/contracts). That being said, when word gets out that new technology is imminent, requirements and wannabe 
stakeholders may start coming out of the woodwork. To a given department head or workflow owner, their needs are worthy and critical. And they may be justified in their position, but one of the most important responsibilities for an integration project owner is to handle a barrage of requests. As the saying goes, you don’t have enough food to feed all the puppies. (Yes, that’s a bleak metaphor, but it’s accurate.)
Ask: Does This Need To Be In Place To Get Out The Door?
A request may be valid and make it to the list of requirements, but building a viable roadmap is all about arranging tasks in both logical and strategic order. If a feature or functionality doesn’t need to be in place to implement integrated technology/systems from day one, then delegate those to Post-MVP requirements tracking. This doesn’t make you a grumpy gatekeeper; it makes you a dang good PM.
There will always be unexpected barriers, unearthed needs, and unspoken requirements that surface along the way. By “trimming the fat” aggressively and recognizing the value of a lean development approach, the whole team is better positioned to absorb inevitable road bumps with grace.
Make Educated Assumptions To Keep Moving When Decisions Are Lacking
Especially when large hospitals or health systems are involved, getting a consensus on decisions can be quite involved. When integration timelines are aggressive, especially if a high-profile client/payer commitment is involved, waiting for change order requests, updated SOWs, and ELT sign-off can significantly halt progress. Despite the variables working against them, technology integration partners are nevertheless held to ill-advised expectations to deliver on time (and, preferably, under budget). Making the judgment call to proceed with minimal information is bold but can serve as the trademark of those who make it work...versus those who crumble under their circumstances.
Ask: Assuming (X), We Are Going To Do (Y)...Any Objections?
Using this line of questioning can be pivotal when dealing with waffling stakeholders who can’t commit or who keep leaking requirements week after week. It’s not as though you can list the CTO by name under your integration project risks, but acknowledging the challenge and driving forward momentum regardless can go a long way. In our experience, those in a position of power feel the weight of their decisions (and thus dance around them for longer than most timelines can bear), so offering a well-developed “out” by streamlining the decision to “We’re going to do this unless you immediately protest” is valuable on all fronts.
Talk Through The Use Case(s) When Scope Creep Surfaces
Even with the best push-back tactics in place to keep the MVP scope of integration efforts clean, there are times when a request simply won’t be put to bed. In these cases, it’s prudent to make time and space to talk through the use case. In some instances, pressure on the need may reveal faulty logic or other motives, which could potentially provide the out needed to track as a Post-MVP point of discussion. However, there may be cases where a deeper understanding of the feature or need helps the development team contextualize the urgency, and thus agree to add it to the feature set for initial release.
Ask: Is Two Weeks Post-MVP Too Late For This?
When integration clients aren’t accustomed to Agile development environments, they may be unknowingly assuming a waterfall mode of delivery. For them, if it’s not in the first iteration of the newly integrated model, then it won’t be there for months (or longer). Setting expectations for subsequent releases or updates is not only important for managing long-term projects, but can also support scope discussions by giving stakeholders the assurance that their needs will be addressed soon enough to wait.
Perfection Isn’t Version 1.0
Open lines of communication go a long way for setting the stage for a project team in which hard conversations can happen, and scope can be refined for successful deployment. Without low balling expectations (and undercutting the client’s confidence in the team at hand), making it clear that MVP doesn’t equal perfection goes a long way. Define what is critical for getting something in production, especially understanding the value of real-time feedback from end users and departments to refine the integrated components for maximum value. This is the benefit of the Agile approach, after all, and keeping the team focused on the benefit of iterations steeped in well-vetted requirements will bring assurance and vision for all involved.