The other day, I was preparing a quickie assessment of the biggest office suppliers in the US, and I thought “Instead of trying Google or Wikipedia, I’ll use this newfangled Wolfram Alpha thingy that’s out now.” And after approaching that query, along with some other spur-of-the-moment questions, I’ve finally realized what Wolfram Alpha is.

Read the rest of this entry »

When it comes to the classic “iron triangle” project management model of time, scope, and cost, the three key stakeholder groups which directly influence and work on a typical interactive project are in constant conflict based on their perspectives. I’ve been asked many times in the past: “What’s your approach to handling this kind of situation? How do you resolve the differences between the creative, business, and technical teams?”

Read the rest of this entry »

Software development lifecycle processes can sometimes be seen as impediments or tedious tasks. But it is worth reminding everyone that the smart work up front will save you headaches later. In my experience, well-written software requirements serve two main purposes: it orients all project participants and helps get buy-in about what you’re trying to do (since you’re articulating what you’re trying to accomplish), and it makes sure that everyone (from the project sponsor(s) down to the technologist and back up to the end user) can say that the project is done to expectations.

The trick is how to write a good requirement, for any number of situations. Part of the answer is to follow this convention:

The [your words here: system, actor, function, dependency, etc.]
must [your words here: do, process, store, etc.]
to [your words here: accomplish a goal, serve a purpose, etc.].

and to focus on the “what” (substance) of the need as opposed to the “how” (design) of the need. In addition, there are 8 key criteria that each requirement should satisfy to be considered well written.

Read the rest of this entry »