Talk It Through: Three Ways to Collaborate with Partners On Large Projects

July 5, 2017 — John Sieben

Any large project between client and partner is going to come with its logistical challenges. But what happens when another partner is brought into the loop? Does having more than one solution provider become a nightmare waiting to happen, or is collaboration manageable and everything will run smoothly? How can the project effectively be managed? I’ve thought on these questions recently after working on a few projects with multiple partners. There’s no reason to believe that the projects I’m referring to were nightmares. In fact, these projects were managed with different methods that happened to work. The experiences I had inspired me to want to take a step back and learn why the projects ran smoothly without any game-changing hiccups at the last minute.

What Does Perfect Communication Look Like?

What is the key to effective collaboration? Communication. So that’s it then? Have communication and the project will go off without a hitch? I don’t believe this is the case. Here’s a quote from an instructor of mine that was etched into my memory: “Practice doesn’t make perfect. Perfect practice makes perfect.” I think this applies nicely to project communication. It’s not enough to have communication — but rather, that communication needs to be “perfect.”

So, if “perfect” or effective communication is key … then what does perfect communication look like? This is where I started my investigation into what made the collaborative projects successful.

First, Collaborate Upfront on Projects that Don’t Require Close Interaction

How to handle the communication between various partners working on a project is of course going to depend on the unique project requirements. A project might have requirements that allow parallel work to occur without any interaction — or very little interaction — between the partners. In this case, having upfront communication can provide the roadmap for each partner to complete the job effectively and on time. Things to discuss upfront include the following: the various points of integration, the likelihood that integration touchpoints will change, modifications to project requirements, possible delays from any involved partners, technical issues in the development environment, and more.These are all details that need to be considered when working with multiple partners.

Some of those points, such as technical issues and delays, will be unexpected. Adaption from all parties will be the solution to getting through those times. A successful collaborative project where partners do not communicate regularly needs to consider the level of integration between the partners’ deliverables in the final product. If touchpoints consist of simple calls or providing data in some data store, then allowing work done by each partner to be carried out autonomously could work smoothly. The picture here is not too complicated in that case: A few partners will work on their own with little concern for what each other is doing.

The story changes if the integration is tighter, however. In this case, the project requires more direct interaction between the systems. And thus, the project requires greater collaboration.

Second, Working Together on Close Integrations

So what is different when the systems are tightly integrated? Both partners are now more susceptible to changes that each other is performing. Clearly this has the potential to introduce bugs into the overall system if one party is not aware of the modification. But the impact is easily mitigated through updates to partners when changes are planned. But how should this be organized?

One strategy would allow the partners to communicate directly without any intermediary liaison. The benefit with this approach is instant contact between each partners’ developers. The trouble comes from inconsistent updates. Such an approach would benefit from having a required status to be sent out to all partners regularly. However, allowing partners to talk with one another could leave the client isolated. So to extend the idea of allowing the partners to talk to one another, setting up the environment such that the client acts as the intermediary allows the client to stay up to date on the project as it goes along.

This environment does have the potential to have some logistical challenges. This could include the need to organize all parties involved when a direct meeting between partners is required. Or having to wait for the client to relay messages back and forth. Not only does this create a time delay, but it also could become frustrating for the client.

However, the challenges aside, there are benefits to this approach. The client will be actively involved throughout the process. First, the need for collaboration in testing efforts will keep the overall status of the project open and clear. Let’s take, for example, a client working with two partners on a system that sends messages back and forth. Since the client is required to be present for meetings with multiple partners, they will also get to watch the testing session and see the results. If the system is working as intended they will know, and if there are issues they will be made aware.

Finally, Bringing In Your Client is Often Smart

This leads to a second point: If the client is an integral part of the collaborative effort between partners, they can offer input along the way. In a situation where partners require an intermediary to carry out testing, that intermediary will have a view into the system as it develops. Should the client see that the system is not performing as desired, they are in an excellent place to discuss with all involved partners their concerns and open the conversation to find a solution.

Which Strategy Works for Your Project?

At this point, I’ve offered three different methods for handling collaboration in a large project. These are all strategies that I’ve gotten to experience firsthand while working on various projects. And each project was successful and each had its own challenges. My investigation into the differences in each one reiterates a point that can to apply to any project. And that is that each project is different. In this case, there is no one answer to how to handle communication. The nature of the task at hand is going to influence the choices in how best to communicate. So, the effective or “perfect” communication is going to be unique to each project. And it may look different to what I’ve presented here. Therefore, a successful collaboration relies on the communication being tailored to the needs of the task at hand.

We Wrote the Book

The Indispensible Guide to ArcGIS Online

Download It for Free

John Sieben is a Software Consultant for SSP Innovations, a Utility & Telecommunications GIS consulting company in Centennial, Colorado. John has worked on workflow customizations and reporting. Along with this he has spent time working on integrating third party solutions with GIS and SSP products. John’s original background lies in Read more

What do you think?

Leave a comment, and share your thoughts

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>