It was the spinning tupperware drawer that got me. I was in a friend's recently built condo, and he was showing me the ins-and-outs of the build, when we came across the drawer. It fascinated me because it was obviously custom-built to meet my friend's obsessive-compulsive tupperware organization needs.
"Was this drawer design in the blueprint?" I asked.
"No," he said. "I just happened to come in when the builders were working, told them what I wanted, and they built it!"
I was shocked; I had always thought you gave the builders a blueprint, told them the colors and textures you wanted, and they built it. At that point, I'd thought, you pretty much get what you get.
In the web world, this is how projects often go. The client needs a website, and the client hires a vendor to help. A blueprint and design is created, the vendor builds the website, the client is trained, and from then on they're responsible for maintaining and improving themselves. This may be the ideal scenario for some projects, but it can be extremely risky when working on complex project with many unknowns, when using open-source software, or on agile projects that require frequent adjustments. I find that enterprise projects are most successful when both the client and vendor are equally engaged during the development process. Ideally, the client has a committed development team for the project, as if it was an internal project, and the vendor team acts as an extension to the client team.
Why build a site together?
Setting the client up for success
A successful launch isn't the only thing that makes a project successful; a client's comfort in maintaining the site after launch is also critical. Close collaboration between the client and vendor development teams ensures the client's team knows the system when the launch arrives; they've already been working close with it, and ideally no special "training period" is needed! This approach is a huge plus for vendors, too. The earlier the client starts owning the project and the decisions made, the less chance there is of last-minute finger pointing!
Requirements & Feedback Loop
On the two most recent enterprise projects that I have worked on, the client's biggest complaint about past vendors was that they failed to fully understand the requirements. This classic cartoon demonstrates the problem well.
The client has an idea, perhaps notes captured on paper — heck, maybe even a working prototype! Their vision may not be clear, though; when the time comes to implement the full product there are varying perspectives, and the end result can fail to meet the client's needs. Sometimes, avoiding this fate is just a matter of the client being more closely involved in sprint reviews or progress meetings. However, I have found that the more the client's team understands what is being built and how it is being built, the better feedback the client can give along the way to achieve their vision.
Decision Making/Conflicts
Clients that are closely involved in the building process are better able to make informed decisions. This can prevent "blind decisions," moments when the client agrees to something without fully grasping the impact or the outcome. In addition, when conflicts arise, both the vendor and client are speaking the same language and can communicate problems and solutions more effectively. All of these build trust around estimates and performance, too; as they collaborate, clients become more aware of the things that are easy to implement and the ones that require research time or custom code. The success of the project becomes a shared responsibility, and both teams are in it together rather than tossing requirements and bug reports over an artificial wall.
Insight on both sides
Both the vendor and client can offer valuable perspectives throughout the project. The vendor team has the open-source experience working with the development framework, the experience of working with different companies, and a grasp of the most likely challenges that will be faced. The client team has the product expertise, and the knowledge of company history—as well as a deep understanding of the team members' personalities, the politics, and real stakeholder needs. Because of the varying viewpoints, both teams can spark ideas and help each other find solutions to inevitable challenges.
Ingredients for successful collaboration
The right team
I have found that there are four crucial roles when both vendor and client are building a project together.
- Developers: It's important that both teams complement each other. Sometimes, that means having matching roles on each side (1-1 database admin, etc.) while other projects may benefit from dividing different types of tasks between vendor and client teams. Either way, ensure that clear communication is maintained.
- Architect: This is usually a senior developer on the vendor's side responsible for maintaining a bird's eye view of the system that is being built. They need the technical knowledge of both the tools being used and the system being built to answer the difficult questions that inevitably arise: they become the go-to person for analysis of changes or additions and how they'll affect the system.
- Project managers: On both the client and vendor sides, project managers function as communication liaisons for the rest of the team. This is extremely important, as the two teams can easily drift into their own "tribes!"
- Client stakeholders: These may be the most important people to keep closely involved. They don't need to know all of the day-to-day nitty-gritty details, but they'll need to ensure the team is building a system that meets their needs. It's essential to build several checkpoints into the project timeline, points where these stakeholders can review the system and ensure that they understand what the team is building, and that the team is heading for the right destination.
Training
In order for the client's development team to be involved, up-front training—not only for the framework being used, but vendor processes, tools, etc.—is usually necessary. It's important to establish these things early on so that the project can begin smoothly. Developers often get immediate attention when it's time to train, but anyone who'll be making technical decisions for the project will benefit from the same information.
Confidence & trust
Building trust helps to keep the teams engaged on the project and involved in the decisions made. I find trust is built when the vendor team clearly communicates what is being built, how it's being implemented, and why decisions are being made throughout the project. Vendors who do this are sharing best practices while they develop, and ensure that an eventual hand-off to the client's team will be smooth. This is another great way to build trust is through in-person collaboration. On one of our recent projects, the developers used large white-boards at the client's offices to decide on the various groupings of Drupal features we would create. The client's team participated in the brainstorming, and was immediately engaged in the analysis and decisions that resulted.
Stick to the plan
Once the client's development team becomes more familiar with the website framework, and how to best utilize it, they may want to start changing/adding things to the plan. It's important to stick to the vision the stakeholders signed off on, while communicating that gold-plating iterations can happen after the project is finished. This doesn't mean the spinning tupperware drawer cannot go in, but it needs to be evaluated in the overall plan.
Project check-ins
Take time to look at the project together as a whole and do frequent retrospectives to see how the teams can improve the working relationship. Evaluate things such as communication processes, ticketing, documentation, project schedule/flow, and resources. On a recent project, we did an evaluation midway through the project and realized we had too many people involved on the daily scrum calls. We limited the calls to our internal team members and transitioned to weekly calls with the client team.
Red flags to watch for
While collaboration between two teams can bring many benefits, there are times when the process stumbles and needs recalibration. Over many projects, I've learned to recognize some warning signs that should trigger a heart-to-heart with the client. To our clients: don't worry! All clients appearing in this work are fictitious. Any resemblance to real clients, living or dead, is purely coincidental!
Lack of resources for the client team
If the client doesn't have the team to support the project or the capacity to spend time on it, collaboration simply won't work. They may seem to have the perfect team structure, but if they're spread too thin on other projects and "fire fighting," the vendor's team will spend their time waiting for input or picking up the slack. Sometimes, a disengaged client team is a warning sign that the client isn't fully committed to the project. It may make more sense to move to a more traditional approach, with the vendor's development team implementing a spec outlined by the client.
No point person
On the client side, it's a good idea to have a point person who already has trust in the vendor, is familiar with the development framework, and has clear goals for the project that is being built. Without this point person in place, the project may be compromised simply because there is not a "cheerleader" encouraging the client team to work effectively with the vendor. Having a point person also limits the possibility of an "us vs. them" attitude evolving when conflicts arise.
Limited timeline
Ramping up a client's team in preparation for actual development takes time, and getting two different teams to work effectively together doesn't happen overnight. Evaluate the client's willingness to invest up-front time in training, coordination, and planning to ensure that the project goes smoothly. If the timeline is too tight, a traditional "build to the blueprints" approach may be a safer bet.
Back-channel bribery
Although it sounds obvious, one of the biggest red flags is a client that attempts to short-circuit the collaboration process by convincing individual developers to sneak in changes or feature additions. Although it's always tempting to bypass processes when changes need to be made, the divide-and-conquer approach can undermine the effectiveness of the group decision making process, and threaten the entire project if allowed to spiral out of control. This can easily spark political battles, siphoning energy from the important work of completing the project itself.
Conclusion
In the end, both clients and vendors want to build a website that meets the client's business needs. The better the vendor understands those needs and the client's vision, the better the outcome. I think the most important benefit of building a site together is the relationship that is created; in a healthy collaboration, the vendor is viewed as a genuine partner, rather than an outsider with different priorities. From my perspective on the "vendor" side of the fence, it's also a lot of fun working with a client's team! There are few things as rewarding as working together to build an awesome project.