A lot of the work 
I do with my colleagues at OpenIssue involves informing people about their technology options and different approaches to adopting these options. Through this process, we discover that clients often have certain “beliefs” or ideas about technology.
Over the years, we have found the following short list of ideas are prevalent in the client (and consulting) ecosystem. When clients can be informed that these are, in fact, technology myths rather than truths, we can help them avoid putting time and money into no-win pathways:
Myth 1: You can have a single system.
There is no such thing as a single system in information processing architectures, especially if it is cloud-based. Many pieces come together to make a user experience possible.
Our work calls on us to architect systems and the connections between them. While not all systems can work together well, in the circumstances they can, we favor improved communication over system consolidation.
Picture a forest and all the things involved that make it function – the trees, the low ground cover in between, the squirrels that spread acorns so that more trees can grow, etc.
It’s important to pay special attention to this myth. When this line of thinking is present in a project dynamic, decision makers can be misdirected towards a false simplicity which is, unfortunately, often supported by unfulfilled vendor promises. This paves the way for becoming a “Beta Tester” (or even Alpha!), which can interrupt your operations and the work that your technology is intended to support. We like to balance customization and new features with business continuity and opportunity cost analysis.
Myth 2: Project requirements are complete.
Project and system requirements are never “finished” per se, nor can they ever be fully “correct”. They are always drafts until the team really dives into the project. At their best, project requirements provide a solid starting point for what ultimately becomes an evolving business negotiation, with a maturing understanding of the project’s goals and outcomes.
We always make room for both reality and change in the execution of a statement of work. It’s something like crossing a narrow rope bridge over a high ravine: I’ll tend to watch each step very closely, and never lose sight of the other side nor the way back.
Myth 3: Budgets and timelines can be fixed.
Timelines and budgets are critical for any project. However, most project timelines and budgets do not stand the test of external change. The best a project team can do is to both have a plan, and also expect it to change.
Just like when you plan to take a long walk on what starts out to be a gorgeous day, it’s important to bring a rain jacket or layers, because the weather can easily fluctuate.
Flexibility and change management can be a difficult when consultants produce “not to exceed” (NTE) agreements in this dynamic environment. NTE agreements offer “fixed costs” and can wrest control out of your hands, and into the hands of the vendor if not implemented inside of an effective communication model.
Compromise should be the outcome. The key here is to remain actively involved in which compromises are made, when they are accepted, and how they are implemented.
At OpenIssue, we employ these and other mitigation strategies to manage this dynamic of changing timelines and budgets: weekly project check-ins, a well-defined escalation plan, and burn rate reporting. Both client and implementation teams need to be at the table and communicating regularly for this to go smoothly.