A Selection of "Our Take" Columns

as possible about what users LIKE, as well as their suggested improvements. And yes, before eliminating a feature, be sure it won't result in disgruntled customers. Let's all commit to complete user requirements. And next time, don't take my louvers!

2 January 2002
My project assignment: Make a New Year's resolution. I am the project manager. I have to be sure the requirements are thorough and clear so I know how to plan for following through on my resolution. I have to acquire the resources to ensure project success (e.g., access to health food and a gym). I'll need to implement all the "people skills" I've learned in my vast experience to give pep talks (to myself) and motivate, so that I make a positive contribution to my project's success. Since this project requires overtime offsite (at the gym), I'll keep the project's purpose in mind in order to help maintain discipline during the project's, uh, "lifecycle" (gradually increasing difficulty). I also have to accumulate all the information to be sure the requirements are correct (e.g., nutrition information on packages for menu inspections). As I progress in my agile development project, I'll keep up the exploratory procedures by varying recipes. This can prevent project burnout. I will celebrate the success of my project with fudge brownies and big cigar.

20 February 2002
The Project and the Expedition
Lately I've been reading Stephen Ambrose's book about the Lewis and Clark expedition. The project began with an enormous amount of training and planning. The sponsor (Thomas Jefferson) and the project manager (Lewis) worked together preparing the requirements. They knew they would have to rely on a lot of exploratory testing. Lewis pieced together the right people to make up the team. They were experts in eXtreme Programming. After each iteration, the manager and comanager (Clark) constantly revised the development plans. Many of the initial requirements proved naive and unworkable.

They struggled through the lifecycle like a keel boat pushing upstream through uncharted territory. Ultimately, good project management proved flexible enough to adapt to every development, while keeping the interests of the sponsor as the central priority. The final product didn't have precisely the same set of features initially envisioned, the deadline was pushed back about a year, but all concerned were well pleased with the outcome. The retrospective conducted by the sponsor (they didn't have facilitators in this role yet) revealed that, given all the unexpected developments (scope creep), it would be hard to improve on any aspect of the project.

Speaking of expeditions...Here at StickyMinds we are embarking upon another expedition of our own: version 3.0 of StickyMinds.com. We often receive feedback from our StickyMinds members. Those comments and a lot of other usability goals are driving this project. We'll keep you posted.

6 March 2002
Having trouble communicating with someone? In all the theories of "effective communication" I've been exposed to, there is one universal rule: understand the person with whom you are talking. Find out what makes the other person tick, what their values are, what their style of expression is and why, etc. Rather than cite one of the many books on the subject, we find a good example from a long-enduring source: Star Trek.

The case in point is Captain Kirk's debate with the M-5 multitronic robot. To make a long story short, M-5 was supposed to be a handy tool, but instead, it takes over the Enterprise and attacks Federation ships (surprise). Kirk knows the personality of the robot's creator and understands M-5's hard-coded values and how to communicate with it. Knowing what makes M-5 tick,