TeamClock.com, one of our internal projects, has undergone a web 2.0 makeover. Basically, we took the dashboard and made it a smoother user experience. You can read some of the technical details over at FiveSticks.com, and you can see the results on the dashboard overview.
One way to attract visitors is to use your body in a way that goes against nature. Then blog about it. People love a good self-abuse story! Visit the Sleep Deprivation Project for an example. The SDP only gives text, which gives it a little less weight. I’d like to see a video or at least some pictures, something which gives a little real time aspect to it.
If you scroll down the page, you’ll find a photo of an obese man wearing a shirt proclaiming his victory over anorexia. Nice.
Just a reminder to everyone, we have begun our summer hours.
Start an experiement where you eat something disgusting for a week. Chronicle your adventures on your website. For an example, visit The Monkey Chow Diaries.
Summary: Risk management is an important part of website design, website maintenance and software engineering. You can reduce risk by focusing on clear business goals, incremental funding of development toward those goals and open communication with your developers. Thinking about the risk your projects face early and often will help you end up with a better result.
I think about risk a lot. Risk management is one of the foundations of software engineering and I believe in taking it seriously no matter what type of project we’re working on, even if it’s a relatively simple website. Let me illustrate what I mean by controlling risk.
Customers come to us with varying degrees of preparation. Many customers, usually experts in their field, come to us with a well thought out and fairly polished statement about what they want. And they’re looking for a quote. They’re doing a standard purchasing process. They describe what they want, someone gives them a quote for it and then that’s the price. They get two or three of these, pick the one that best meets their needs and then move forward. This is one style of risk management.
The problem with this type of risk management is that it doesn’t address the full spectrum of reasons that websites and other software projects fail (cost). It fails to address any of the failure points (inappropriate features, lack of innovation, etc) that are also leading causes of website failure. Incidentally, when a customer comes to us with this kind of request, we usually don’t issue a quote. Why? I’ve never seen an RFQ or statement of needs that accurately captures what the end system will actually be. And, even if they did, they’d leave out one very important component: innovation. But I’m getting ahead of myself.
Next: a concrete example.