Time boxing

Recently I was given a project which was researched months before I received it. There were some research artifacts but not anything really comprehensive. As a good PM, I decided to create a charter. However, I didn’t want to slow down the project (high visibility).

I applied a time-boxing approach. I can be a perfectionist, trying to get the wording and organization just right. With time-boxing, I gave myself 5 hours across 2 days to complete the charter. The process promoted time management, right-sizing the documentation, and “not over-doing it.” I created the charter with the information available and didn’t try to find all the little details. If I didn’t know something, I acknowledged it as a follow-up for the requirements/prospectus/scoping document phase.

THINGS TO CONSIDER: Time-boxing can sometimes save you from yourself, allowing you to focus on the important pieces and being time-driven.

The Cost of Perfection

I worked full-time as I attended MBA classes. I balanced work, dating, family, socializing, volunteer work, and school. I’m a person who likes the A. One semester, I worked on a big work project where I worked 50-65 hours per work for a few months while I took two MBA courses. As I tried to balance my life, I noticed the relative large cost/time increase to get the A. Then I remembered the most important thing … A’s are axcellent, B’s aren’t bad, and C’s still pay cash; my company reimbursed for C’s and above. I was getting the education I wanted and matching my effort to the grade. I was happy with B’s.

In my prior quality assurance/testing career, you learn there’s a point of diminishing returns of continuing to test. You can find 80% of the defects but it costs a lot more to find that remaining 20% because they are more hidden or exception. It could take just as long (if not longer) to find the last 20% of the defects than it took to find the first 80%. QA finds a balance between time and accepting the remaining risk.

In my firm, I see requirements gathering phase of a project taking a really long time. It’s the first stage of the project after kickoff and it tends to go longer than planned. Maybe we need to improve the requirement brainstorming and gathering technique effectiveness. It also could be that we’re trying to be requirement perfect in an imperfect world. Are we getting the bang for the buck of not proceeding until “all the requirements” are gathered? (Yes, this is a waterfall type project.)

I like the lean (or agile) approach of time-boxing. Users/Customers will tell you what’s most important first. These are things they are most familiar. Time box the requirements phase to say we will close this level of requirements gathering on x date. As the project progresses, the users will identify new/revised items that came to mind. They could be seldom exceptions or special functions for specific events like year end processing. You can introduce these through change control or have requirement entry points. I might have missed the bus at stop 1, but I can still catch it at stop 3.

THINGS TO CONSIDER: Time box requirements gathering to balance against the point of diminishing returns. Use change control or requirement entry points to manage those missing or unspoken requirements.

20 Questions

Have you seen the 20 questions game (www.20q.net )? Radica created a handheld version which is very entertaining. Wikipedia shares that this began as an artificial intelligence project. Over time, it has progressed as the program learned.

The way this works is that you think of anything and then let the game begin. Usually within 20 questions, the game will guess the object you were thinking about. It could be a ball, baby, Dalmatian, salt, or more.

Why do I bring this up … the questions that are asked highlighted a good requirements gathering technique. The questions attempt to understand what it’s not as much as what it is. It divides the population of potential answers then continues to refine/divide until there is a small population remaining.

When you go out for lunch or dinner, what is easier to highlight … what type of food you want or don’t want? For most people, it’s usually easier to identify what you don’t want. That dramatically reduces the population of potential answers.

Some users are the same way. They have trouble articulating exactly what they want but they can tell you what they don’t want. With that data, you can refine your product to better meet customer needs and expectations.

THINGS TO CONSIDER: During requirements gathering, try to understand what the customer doesn’t want.

Kano Analysis

I stumbled upon Kano analysis a few months ago. It provides a nice technique for driving to “real” requirements that drive customer satisfaction.

I’m not fully utilizing Kano analysis yet; I’m not jumping into the deep end of the pool. As a starting point, I’ve refocused my requirements prioritization/justification techniques. I use the following labels – 1 Must-Haves and cancel the project if I don’t have these, 3 Differentiators in the market place, and 5 nice-to-haves. I allow for some ambiguity by using a 5 point system instead of a 3 point system.

If I get weighted too much in the 1 Must-Haves, then I delve into some Kano-type questions to help justify that level of must-haves. Kano suggests using a multiple question approach to double check answers, come at it from different ways. Questions styles could involve exploring boundaries or implications of taking-away to name just a few. This tries to understand if this is an indifferent requirement where “out of sight out of mind” does not impact product satisfaction. On the flip side, does adding this feature increase customer satisfaction. For instance in MS Word, I’m guessing that the Web Layout feature was not a must-have in Word 2003 original version. It’s a good differentiator from similar products but there were likely more important features to deliver successfully with proper quality.

Search the internet for Kano analysis and see what insights you find.

The Parking Sign

At the 2007 AYE (Amplify Your Effectiveness) conference, I met a nice gentleman named Michael. In the QA Testing (software quality assurance) field, he’s known as the Braidy Tester. Michael has great insights and creative methods to get you thinking. And sometime just to get you smiling. Michael will write QA Testing lyrics to accompany tunes that we are familiar like Barry Manilow's "Copacabana" or Van Halen's “Finish What Ya Started.”

You don’t have to be in the QA Testing field to appreciate the Braidy Tester. Recently, he posted a Parking Sign (click the link) and asked readers to write requirements about the sign content. It was a great exercise in ambiguity and context/domain-knowledge assumptions that we sometimes build into requirements (or parking signs). He shared the results and his brainstorming techniques. He shared some good heuristics such as emphasizing different words and using synonyms to view other interpretations. Take a few minutes and read that blog article and maybe more.