Why web projects work better when clients and vendors build together, the necessary ingredients for a successful collaborative project, and how to spot problems before they explode
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.