Toby Bourke
Were you in the workforce or studying in 2010 when Uber, the Apple iPad, Microsoft Azure and 4G mobile data networks were released?
If so, you will probably recall (perhaps with a sigh of nostalgia about simpler times, tinged with frustration) the sometimes-painful experience of being a team member contributing to a Word document, Excel spreadsheet or PowerPoint file before these products supported real co-authoring. Prior to co-authoring, we collaborated far less often, and when we did, the number of collaborators were fewer, usually with a propensity to be co-located. Of course, many people no longer sit side-by-side next to their colleagues in an office cubicle environment.
For those who don’t remember how it worked, we waited patiently for our colleagues to make their contributions to a file that was passed around from colleague to colleague, which we would save and diligently email back to a project manager after each revision with a newly modified file name like Smith_St_Reservoir_Risk_Assess_v6.doc. If you lived through this versioning nightmare, I bet you have a memory of someone titling a working document Smith_St_Reservoir_Risk_Assess_final_final.doc with the instructions to “ignore all previous versions”. By today’s measure, this process is unthinkably slow and error prone. Thankfully, those days are long-gone.
If you have an interest in business optimization and workplace culture, you’ll be aware of the connection between the adoption of co-authoring in common corporate software and changes to staff deployment and project team selection. Collaborative working trends have dramatically changed go-to-market strategies of service-oriented organizations, and it’s no surprise that early adopters of co-authoring achieved advantages. Some businesses adopted the so-called follow the sun model of diversification of project resources across time zones with goals around faster project delivery, better development of junior staff, reduced staff risk, lower business overheads, and broader range of expertise and experience on project teams.
The implications for niche engineering software
Now that most businesses have long-since adopted co-authoring tools – indeed, many organizations are fully cloud-based now – it begs the question: Why do the same engineering-services companies whose businesses have thrived in direct response to the adoption of co-authoring software for document creation and numbers analysis still accept file-based, single-editor engineering software?
Well, any of the following reasons might help explain it:
- Solo expert users: Niche engineering software is sometimes selected by software users who may have a role that is unique in the company. They may not feel like their workflows should overlap with many collaborators. In fact, while it might sound cynical to say, some may even perceive their disconnected tool choice as having a bit of built-in job security. If this is the case, they will not see co-authoring as important software selection criteria. It’s equally important to consider that these ‘solo experts’ are sometimes created by the lack of co-authoring capabilities in the software tools that their employer provided to them. Either way, it’s a lonely way to work.
- No policy for outliers: While productivity is usually an important aspect of choosing software, IT management teams don’t always have the bandwidth to scrutinize software selection if it is only used by a small minority of their company’s employees, so they may overlook this detail.
- Perceived status quo: The majority of niche engineering products do not offer co-authoring, which contributes to, and reinforces the perceived status quo expectation of ‘single user at a laptop/workstation’.
What are the impacts of these kinds of choices? A niche software industry with most products being ‘single editor’ results in engineering teams that are set up to reflect the limits of the adopted technology – namely that they are set up for collaboration in series, not in parallel. A team with an expectation of collaborating in series will probably not think to seek out technology that that allows parallel workflows, which is a short-sighted option that contributes to working in silos. Indeed, they may not have ever experienced the benefits of working in parallel.
The importance of collaborative work in planning and operations
If we narrow the focus further to consider just water network hydraulic simulation software, and further still to city or regional water, sewer and drainage networks, we can see that the work of these engineers involves dealing with very challenging data, which needs to be manually reviewed and improved in readiness for network simulation.
For example, every water utility needs to manage tens of thousands of mostly underground assets. The data for these assets was created in various technologies during different eras by engineers who didn’t communicate with each other, using evolving engineering standards, and often in response to constantly varying political/economic objectives. This Swiss cheese of water network data ultimately needs to be made whole, which can be more effectively and efficiently achieved via collaboration.
For many cities, it probably took more than one hundred engineers many decades (and a lot of hard-learned lessons) to effectively design today’s urban water networks. Yet single-editor software asks a single engineer (or many, in series) to plan for this imperfect network’s immaculate future performance! That’s a lot of weight on one person’s shoulders. The use of co-authoring capable technology allows many engineers to work on each of the challenging areas of uncertainty and data cleansing simultaneously, and in doing so also help protect the mental health of our stoic water engineers.
Organizational benefits of working in parallel
Why is working in parallel so important to engineering organizations? Well, delivering accurate and optimized engineering recommendations and other project deliverables in less time is one answer, but co-authoring and parallel workflows offer a range of positive outcomes:
- Increased productivity: Parallel workflows reduce project delivery time, which equates to profit in the private sector and cost-effective service delivery in the public sector.
- Fewer conflicts: Engaging real-time knowledge transfer between project disciplines and between service provider and client reduces miscommunication. This should not be underestimated as a benefit!
- Staff development: Every network hydraulic modeler must learn to build their first real world network model at some point. Spoiler alert: this is usually done on the job. In the past, office environments were critical to knowledge transfer from experts to beginners. The realities of the current globalized, digitalized and increasingly virtual office environment means that software needs to step up and fill the physical divide between mentee and mentor.
- Innovation and impact: When they aren’t coaching the next generation, the best engineers constantly utilize cross-discipline outputs and delegate or automate low-impact, error-prone or low-skill tasks to focus energy on innovative and high-impact tasks. Top-performing engineers are always looking for better ways of doing things, of finding new efficiencies across workflows; they need technology that supports this approach and that allows them to stay focused on high-impact work.
- Accurate deliverables: When an organization allows all relevant talent to contribute to all projects by way of parallel workflows, they can realize more accurate engineering outputs. This naturally results in less re-work and ultimately more efficient infrastructure spending.
The future is collaborative, connected, and in the cloud
Choosing parallel project workflows over siloed solo work isn’t just about best practices, it really is the future. At Autodesk, that future is exemplified by Forma, our industry cloud that uses the principles behind BIM (Building Information Modeling) to unify workflows across teams that design, build, and operate built environments by relying on a single source of truth in the cloud.
When people talk about BIM, they are often talking about the construction of buildings, so while “BIM for water” might sound a bit wonky as a catchphrase, the same principles underlying BIM apply to water infrastructure planning, design and operation. If your software of choice as a drainage designer, hydraulic modeler or asset manager cannot clearly communicate to collaborators in real time in order to tackle more and more complex infrastructure challenges, you will be operating at a distinct disadvantage. Unfortunately, ‘slow and steady’ does not always win the race.
The future will not be disconnected
We’ve been offering real-time collaboration in InfoWorks applications for a very long time. In fact, InfoWorks WS Pro and InfoWorks ICM have been uniquely capable of supporting an unlimited number of co-authors in a conflict detection/resolution environment since the late 1990s, roughly a decade before Microsoft unleashed full co-authoring support in Office 2010.
This collaborative environment has allowed some of the world’s largest cities such as London, Shanghai, Hong Kong, Tokyo, Toronto and Chicago to create water network modelling programs and contractor alliances that are always ready to concurrently answer multiple questions posed by the public, regulators, land developers, town planners, network operators, contractors, planners and designers alike. With full co-authoring capabilities, the large in-house water network modelling teams employed by these cities do not have to worry about model integrity or suffer through the downtime associated with single-editor, file-based software.
These cities have tackled the most important part of building successful water infrastructure networks, which ultimately isn’t just securing funding and meeting regulations, but in finding ways to successfully and efficiently collaborate and communicate.