If your web site has a customer feedback form, you can learn from Apple’s mistakes.
If your site attracts a lot of visitors — or even a niche community of visitors that advertisers want to reach — you can place advertising on your site to generate revenue. This post looks at three types of advertising to consider.
I waited for Tivo. I waited for iTunes video downloads — and I'm coping with its still-too-limited content. I'm even scraping by without Amazon Unbox. But THIS is the last straw:
We are deeply, deeply sorry to say that due to licensing constraints, we can no longer allow access to Pandora for listeners located outside of the U.S. We will continue to work diligently to realize the vision of a truly global Pandora, but for the time being we are required to restrict its use. We are very sad to have to do this, but there is no other alternative.
Our friend Adam put us onto Pandora a couple of months ago. It is a deeply groovy, rapidly addictive web radio service that creates custom channels based on your musical preferences. It took just a tiny bit of feedback to get a great mix that plays a great range of mellow working tunes on one channel, a set of showtunes on another channel, and energetic hip-hop on a third. Most magically, each channel settles into that perfect balance of tunes you know and love, and tunes that you are thrilled to discover. For those of us who have ceded control of the radio to our children, this is a wonderful chance to explore musical genres that don't involve farm animals or princesses.
But once again, Canadian sovereignty has done me out of my online content. Part of me (the part that subscribes to Entertainment Weekly) wants us to undertake the digital-era equivalent of those currency schemes in which countries adopt the US dollar instead of going to the trouble of running their own currencies; let's just trade our precious intellectual property freedoms for a broadband hookup that delivers all the goodies available to our southern neighbours, and sign onto all the American I.P. laws so that what works there works here.
The other part of me (the part that subscribes to the New Yorker) is sick of being ingored by media companies that can't be bothered to navigate regulations they haven't written themselves. Yes, it's very convenient to get the laws changed when your mouse is about to go rogue, but sometimes companies have to figure out how to comply with laws instead of just writing new ones.
And the way I see it, there's no time like the present: with the majority of the US media empire stymied by a labour force that has recognized its own interests in digital media rights, their lawyers might as well turn their attention this way. Maybe we can catch their attention if we point out that the writers up here are covered by a different union.
How can online collaboration tools like Basecamp support effective project management? That's one of the questions that came up at the values-based project management session I attended at Web of Change, led by Rob Purdie of Important Projects. I wanted to continue the conversation with Rob himself, and promised to blog our own project management workflow at Social Signal so that he could offer his comments and feedback on how to improve our approach.
Let me begin by saying this is very much a work in progress: we're still searching for the Holy Grail of optimized workflow, and feel like the tools we use now — particularly Basecamp — don't fully meet our needs. I'll address some of those limitations towards the end of this blog post, but let me begin with an overflow of what we use and how we use it.
Our main tools are:
- Basecamp: for project-related task management and client communications
- OmniPlan: for prospective project planning and gantt charting
- Remember the Milk: for internal task tracking
- iCal: for internal scheduling and time tracking
- Google spreadsheets: for capacity planning and docket review
This blog post will focus on how we use Basecamp, which is our main tool for managing the ongoing work of individual projects. The fact that we use so many other tools speaks to the issues we have with Basecamp — which is one of the issues I'm particularly keen to hear Rob address. We're also fans of — though not religious adherents to — David Allen's Getting Things Done methodology, which has influenced our approach to task management.
We set up a Basecamp site at the beginning of each client engagement. Some of the best practices on Basecamp set up that we are trying to adopt as our standard include:
- posting a welcome message to Basecamp that explains how to use the site (see VentureMarketing's Basecamp Welcome PDF, and their Basecamp client jumpstart, for another approach)
- presenting an overview of Basecamp at an early client meeting
- when clients e-mail us outside of Basecamp, redirecting them back to the Basecamp site, often by copying-and-pasting their messages into Basecamp
I add all our subcontractors to Basecamp as members of Social Signal, so that we can cover any technical issues without dragging the client into the Drupal abyss. We recognize that our clients don't always benefit from seeing how the sausages are made, and when it gets into some of the intricacies of module development or permissions configuration, we like to keep the excruciating details private so that clients aren't drawn too deeply into technical issues. Unfortunately, Basecamp only allows private communications among members of the same company, so we choose to treat all our subcontractors as members of Social Signal.
Structure and usage
We use messages for communications that require an action or response. This includes:
- communications with clients and client updates
- client requests (bug tracking, questions, etc.)
- internal discussions of how to handle tasks (marking these discussions private so they aren't visible to client)
We use writeboards for communications that are FYI only (though we may use messages to notify each other of a new writeboard).
We use task lists for items that require a "next action" (in GTD terms).
We have recently refined our use of messages to keep better track of all open loops. We respond to urgent messages as they come in, and at least once a week (and ideally every 2-3 days) we review all the messages in a given project space, and update status. We find that updating message status on a real-time basis is excessively time consuming and leads to duplication of effort.
Our message categories vary a bit by project but mostly reflect major categories of project activities (see screenshot — some items deleted to protect client privacy).
When we review a message we briefly note our response, action required, or action taken, even if it's already completed, for future reference.
We then edit the title of the original message to note the status of that message:
- QUEUED: the message requires an action or response. An item is only marked as "queued" when it has been added as a specific task or tasks in a to-do list. An item may be marked as "queued" even if we anticipate that it will prove too low-priority to address; however by adding it to our queue it can be reviewed with the client during our next review of outstanding tasks, and prioritized accordingly.
- CLOSED/RESOLVED: the message requested or required an action or response that has now been completed. We switched from marking items "resolved" to marking them "closed" because sometimes messages are closed because the team (including the client) decide that no further action is warranted, because the item is low priority or because the issue is not expected to recur. When an item is closed we ALWAYS leave a final comment noting the action or decision that led us to mark the message closed.
- NOTED: the message provided information that is needed by the team or client, but does not require direct action. When an item is noted it is usually placed in a writeboard we expect to refer to at a later date, e.g. a "think about for phase 2" writeboard or an "items to review before launch" writeboard.
Editing our message titles to reflect the status of each message gives us an at-a-glance view of which client issues have been addressed, and which need to be reviewed for action items.
We have recently shifted from using fewer, generic to-do lists (which we were trying to standardize across projects) to using a lot more to-do lists, each one corresponding to a set of related tasks. This reflects the GTD notion of grouping tasks by "contexts" or as "projects" consisting of multiple tasks.
By grouping related tasks we ensure that:
- related tasks at the same time, and can therefore consider a solution that might address multiple requirements or bugs at once
- tasks can be ordered in sequence or priority, so that a team member can quickly see which tasks must be completed in which order
- a team member can see who else is working on related tasks
- tasks don't get lost in long (20+ items) lists
When we had fewer categories we found that the very long lists of tasks under each made it hard to identify relationships or priorities; the shorter list of tasks makes this much easier.
We keep our to-do lists organized alphabetically; when we decide to prioritize a specific set of tasks as the next focus for our work, we move that to-do list to the top of the page and mark it "P1: to-do list name" (as in "priority 1").
Writeboards are our long-term storage area and collaboration space. We use writeboards for:
- to-dos that we are considering (often for a future phase) but haven't prioritized/organized yet
- reference information (like a description of our e-mail configuration)
- meeting notes
- personal notes that we might want to share with other members of the team, but which don't require an action from anyone (we may still use messages to notify the rest of the team that we have created a writeboard for them to look at)
Our experience with Basecamp has been shaped equally by the technology itself, and our diligence in using it. Of course, these aren't unrelated issues; if Basecamp really met all our needs, so that we could keep all our tasks organized in one place, I suspect we'd be much more consistent in using it.
We find that Basecamp works well for:
- collecting client and team correspondence in one place for future reference
- organizing project tasks, particularly site/softeware development tasks
- keeping track of our "someday" ideas in writeboards
- centralizing our project notes as writeboards
We find that Basecamp works poorly for:
- personal task management; we often transfer our basecamp tasks to Remember the Milk, where we each maintain an integrated personal "to do" list
- sensitive communications with other team members (due to lack of privacy settings)
- project planning (we use OmniPlan, then transfer milestones to Basecamp)
What we like about Basecamp:
- industry standard — most of our partners and subcontractors, and a few of our clients, have extensive experience with Basecamp
- nice-looking user interface
- client-friendly/intuitive to use
- e-mail notifications include full text of the message
- availability of 3rd party add-ons
What we need that we're not getting from Basecamp:
- deadlines for specific tasks, not just milestones
- priorities for tasks
- ability to assign one task to multiple people (though I recognize that could be a mixed blessing)
- ability to comment on a task
- bug tracking (could be addressed by ability to comment on a task)
- ability to make messages/to dos private when communicating with people outside our own company
Nice-to-haves would include:
- spreadsheets (as well as writeboards)
- personal calendaring
- ability to store project templates so we don't have to recreate all our categories from scratch each time
- option to automatically alphabetize categories
- option to keep message categories and to-do lists in sync (i.e. creating a new to-do list would create a new message category with the same name)
- tags in addition to categories
- better RSS output and/or an iGoogle widget that lets us interact with our tasks from our Google homepages (as Remember the Milk does)
One of my favorite compulsive activities these days is looking into Basecamp alternatives. So far my conclusion has been — to paraphrase Winston Churchill — that Basecamp is the worst possible project management tool, except for all the others. Here are some of the "others" I have looked into, or mean to look into; I'll try to come back to this post and annotate the list with the reasons we haven't moved to any of these:
Unfuddle — intriguing because it includes subversion and bug tracking
Clocking IT — a free basecamp alternative, but as far as I can see no built-in messaging. Time tracking, though.
Michael Silberman of EchoDitto put me onto Central Desktop as a somewhat pricier Basecamp alternative that includes many of our concerns about Basecamp. We're trying it out, and it looks promising, although I'm a bit disappointed in the look and feel (it's not nearly as pretty as Basecamp) and daunted by the prospect of moving our projects over. However the prospect of being able to assign deadlines to tasks (imagine that!!) probably outweighs every other issue.
Brian Benzinger's roundup of project management tools for developers provides quick takes on some of the above, plus many more.
In the course of my obsessing over Basecamp and project management workflow I've found a number of useful blog posts on other people's use of Basecamp and Basecamp alternatives. For some reason many of the blog posts I've come across are by friends in the non-profit tech sector; I'm not sure if that's because of Google's freaky habit of customizing search results, or because non-profit techies are somehow more obsessed with workflow (comments, anyone?) Here are some of the posts I've found helpful.
Sonny Cloward mapped his workflow, which hinges on Basecamp, Backpack and Mozilla Calendar.
Ruby Sinreich blogged her thoughts on Basecamp plus GTD, which includes creating virtual "people" who represent different contexts, so she can assign her tasks to contexts.
LifeDev reports on using Basecamp with GTD, in this case using to-do LISTS as contexts.
Jon Stahl provided an overview of collaboration practices at ONE/Northwest, which includes using Basecamp.
I'm going to take Central Desktop for a serious spin. I'm going to continue praying to the 37Signals gods for true Basecamp-Backpack integration, or to the Remember the Milk guys for Basecamp-RTM integration as an answer to their "how can we start charging for RTM?" quest. I'm going to try out Omni's forthcoming OmniFocus task manager.
And I'm going to resist the temptation to engineer an in-house Drupal solution to our project management wishlist. After all, our needs aren't THAT exotic, and there are an awful lot of people chasing the same vision. I'm trusting that one of them will get us much closer to a solution before long.
Meanwhile, I'm eager to hear from Rob Purdie and others about how we can improve our current Basecamp usage. In particular I'm curious to hear:
- how people use Basecamp as part of GTD
- best practices for to-do list structures and message categories
- best practices for managing privacy and disclosure among staff, clients and contractors
- advice on how to manage personal to-do lists within/alongside Basecamp
- how people cope with Basecamp's lack of task due dates
- experiences with Basecamp alternatives
- advice on encouraging good Basecamp habits among staff, clients and contractors
And if you've blogged your own project management approach or workflow, please let me know by sending an e-mail to alex [at] socialsignal [dot] com, or posting a comment here.
This year's Web of Change conference included a session with Rob Purdie of Important Projects on values-based project management. Here are my notes on the session, which focused on collaboratively sharing tactics for boosting the various aspects of organizational culture that support effective project work.
Success of any project can be judged by 2 criteria:
1. were the objectives met?
2. did the team find the work itself rewarding?
Projects not going well has to do with not having a project friendly environment
What is a project?
A project is a temporary endeavour undertaken to produce a unique product, service or result.
ALL PROJECTS HAVE:
– objectives: the things the project is unertaken to achieve
– deliverables: what project will produce in order to achieve objectives:
– requirements: qualities deliverables must have/criteria deliverables must meet in order to achieve objectives
– constraints: that project must be delivered within [time/scope/cost] (the iron triangle) [scope=quality]
Project management is the application of knowledge, skills, tools and techniques to project activities to meet project objectives.
On good projects, people take the time to define objectives.
Org culture is the river; the project is the boat.
If org culture is flowing smoothly, you just have to steer the boat; otherwise you're driving upstream
Projects involve risks, so risk-averse organizations will have trouble
With problematic culture you need more money, and more authority as project manager
Build a project-friendly environment, at least within the project team.
Build a culture of personal empowerment and risk-taking.
WHY PROJECTS DON'T GO WELL….
b/c of a set of assumptions that turn out not to be accurate
confusing the politics of anti-hierarchy with the need to get shit done
WHAT MAKES A GOOD PROJECT MANAGER?
– people skills: being able to listen and communicate well; need to manage expectations and explain things clearly so all sides understand; integrating into project culture is all about people skills
– they need to be bright and flexible and quick and adaptable and know how to talk to people
– persistence: keep coming back for the piece of info they need
– do they need to be values aligned?
Need balance between outputs and processes (ends and means)
Don't burn people out.
Cross-functional integration is valued
Risk taking is supported
High conflict tolerance; need to be able to engage in healthy conflict; a meeting with no conflict is not valuable
Value open and honest communication; respect for one another
5 groups: (how to build each)
Personal empowerment — grow our teams so people feel empowered. Everyone wants to contribute their best work (whether they know it or not). When people feel frustrated it's b/c they feel blocked. How can we remove things that get in way of allowing people to contribute their best work?
Trust — need closure in communications as pro-active way of building trust. Whenever I have a conversation with anyone about anything i want to know who is doing what by when. If you can do that with every conversation, nobody is going back to their desk wondering if the other person is going to be doing the thing that needs to be done for me to do my work.
Respect — what are some specific tactics for instilling this in group. Being late is disrespectful.
- Buy-in. Are you going to stick with the project through hard times?
- What is everybody's standard of excellence?
- Commitment is a great quality for organizers, but it's different in a project context.
- Can't focus on the meta-level of commitment at every project level — objective of producing the brochure can't be saving the world.
- Project has a beginning and an end.
- Commitment can be to doing a great job, to saving the world….but need a long-term theory of change.
- Need to make sure we continue to find projects that the team finds meaningful. Team wants to be happy as well as paid.
- Make sure that the projects speak to the values of the people I'm working with.
- What projects you're choosing — projects can be aligned with a range of values. When does choice of project become strategic — not just about feeling good about the projects you're doing.
- Can someone who's not values aligned authentically serve the role of supporting other people's values.
- Think of this as irrigation: project manager is irrigating the growing plants — the people who are trying to get the job done.
- You are serving a group of people who really care about this —
- How can you transform someone into excitement about this value of promoting social change?
- Ask them: are you interested in transforming?
- Commitment builds trust.
- If you do what you say you're going to do — you make a commitment — that builds trust. If you can't fulfill a commitment you've made, you go back to people and tell them you can't make it and tell them when you can meet them.
- Staff commit to timelines but then don't meet it. People commit to overly amibitious timelines as a way of proving their commitment.
- PMsÂ need to ASK, rather than tell, when something can be completed.
- Time estimates should be offered by the person doing the work.
- Need to create a culture of honesty about how long things will take.
- Projects are always in a longer/larger context.
- Overcommitment — working overtime — as a sign of commitment. Burn-out as a sign of commitment.
- Sometimes the culture can be great, but people are just wrong about how long something will take.
– need to be engaged in planning
– how to embed project into longterm goals of org — creating a culture
– establishing groundrules; closure on all conversations — who is doing what by when; clearly defining roles & responsibilities; including play in project activities to build trust
– project debriefs to make transparent what was broken
– Quakers: creating formats for appreciation — framing contributions in ways that are around appreciating fellow team members' work
– book: The art of possibilities
– tied to trust, communication and accountability
– clear expectations about individual expectations
– what everyone is responsible for as a team member
– groundrules for ccing people, lateness
– here are the ground rules we're going to stick by
– issues board: every specific period — if you're feeling disrespected , there's a way to bring that up
– respecting what client brings, client respecting what shop brings
– proactively handle team by getting to know how they handle conflict
– establish ground rules
– separate problem from person — give people a sense that the objectives are the enemy, not the people on the team
– clarity of objectives
– remember that decision-makers aren't the same as the implementers
– create culture with open feedback channel
– bilateral clarity of expectations — client needs to be accountable for their inputs
– bioteaming manifestos
– distributed teams
I’m just back from SXSW, where I was reminded that there are still a few people out there who are thinking about the Internet as a potential business opportunity rather than as a chance to reinvent democracy.
At the panel I was on — Remixing Business for a Convergent World — it seemed that what is really converging is how both business folks and political hacks are looking at the Net. Let’s take, for example, the question of how to make strategic use of blogs — a question that my fellow-panelist, Robert Scoble, addresses in his recent book Naked Conversations.
Thanks to blogs, businesses can no longer afford to ignore even their smallest customers. Traditional blue-chips are starting to recognize that their next p.r. crisis could be precipitated by a cranky shareholder or dissatisfied customer who blogs about the company. As for the latest generation of web start-ups — sites like Squidoo, Frappr, or LinkedIn — they’re not only sensitive to customer perceptions: their entire business models are based on user (i.e. customer) contributed value.
Once you start to see customers are value creators, rather than value consumers, a lot of business truths get turned upside-down. Take, for example, the idea that businesses are primarily accountable to their boards or shareholders. Does anyone out there think that the success of del.icio.us or Flickr depends more on Yahoo shareholders than on the users who are contributing bookmarks, photos, and software plug-ins?
If businesses find themselves suddenly accountable to their users, that kind of accountability is old news to both government and civil society organizations. Governments have always been primarily (if imperfectly) accountable to citizen-voters, and civil society organizations (whether community service groups or political advocacy organizations) have always been primarily accountable to their members and donors.
The net result is that it’s business that now needs to learn from civic and public organizations about how to enage at the grassroots level. It’s not like public and nonprofit organizations have all the answers — great examples of effective two-way member/voter engagement online are still rarer than the many examples of organizations that are still in “broadcast” mode — but at least there’s a decade of effort to look at.
For those of us who’ve been thinking about online democracy and grassroots engagement for something like that long, the rise in business interest should come as (mostly) good news. Sure, there’s more competition for public attention: efforts at getting voters to participate in policy discussion now have to compete with businesses offering free ipods in return for customer feedback.
But there’s also a rapidly expanding toolkit for grassroots community-building. Tools like Squidoo, Flickr, and del.icio.us offer entirely new ways of involving members and encouraging members to interact with one another. Just as important, the private sector’s growing embrace of customer “community” may help to build a broader culture of pervasive engagement.