Resistance posted to Flickr by Elishams
I should always listen to myself.
When embarking on my stroller site, I thought I’d approach the project differently. In my day job (if I had a day job right now), I would be overseeing a team of project managers, coaching them in the ins and outs of deploying huge applications for major web sites. Or helping them run a project for adding a vertical to a site or creating a shopping tool. No matter where I’ve worked, the process for deploying sites looks generally like this:
1. Identify there is a project and get permission to start.
2. Define the business, technical, creative, strategic requirements. This usually requires activities like stakeholder interviews and spreadsheets that are dubbed “matrices” just to make them sound a bit more fancy.
3. Design the solution using wireframes, mock ups, use cases. Once functional requirements are written, the tech team will define the architecture.
4. Develop the site.
5. QA the site.
6. Deploy and monitor the site.
There are versions on this – ones where you take a more iterative or agile approach. But no matter what you do, it’s all basically the same.
So even after 13 years of experience of delivering interactive projects big and small, I listened to someone else who was really smart, but in retrospect now realize that he knew nothing about delivery.
Now I’m nearing the end of our first push to go-live and this is what I already knew but obviously needed to be reminded of:
1. Working with a remote team who speak English as a second language means that communication channels are not ideal. Communication needs to be crisp and expectations set and managed.
2. Write a spec! Unless you are doing something TOTALLY on the cheap and do not care about the end product too much (I ask you, though, why bother), then some kind of documentation that explains the layout of the interfaces (aka “wireframes”) and the user flow (aka “use cases) is tantamount. Even a basic one. Trust me. It would be saving me hours and hours of back and forth right now, as well as a ton of frustration.
3. Hold a meeting with the designer and developer to review the spec and answer questions. Ensure that they understand the goal of the site, as well as specification itself. Items that would be easy to understand among locals can be surprisingly excrutiatingly painful across continents. I can’t tell you how much back and forth there has been on the difference between “reviews” (i.e. editorial reviews) and “reader comments”.
4. Ask for a timeline and insist on weekly meetings and status reports to track progress. I did not do that and didn’t realize that there was next to no progress on the site for the first three weeks of a four week project.
5. If you are lucky enough to have a project manager, do not trust that he or she is on top of everything. Make sure that action items, decisions and critical discussion are properly logged in issue logs. Follow up. I cannot tell you how many times I thought that something was agreed to, and weeks later when I’d reference it, my project manager would seem to have no recollection of the interaction.
6. Understand cultural differences. My friend Chris described his experience working with India and Bulgaria like this: “Working with India, they will tell you everything is fine and completely on track, but when you press them, you find out they will be 6 months late. Working with Bulgaria, they will tell you that the sky is falling and the site will be delivering late, but when you press them further, you find out that the schedule is only about 2 hours behind.” Don’t I know it.
7. When progress is floundering, push hard. I finally set a very aggressive timeline to get the project done after it was behind by 2 weeks. In the end, my stroller site will deliver one month late – all of which I could have avoided if I just followed my instincts and experience.
Related Posts:
