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.

Absolute No

At some point in the project, someone such as an end user will ask if something could be changed or a new requirement be supported. We’re trying to maintain scope, so the answer is usually NO.

You wouldn’t like it so why should the requestor. Look for ways that you can say Yes. It might be more of a qualified yes.

Can you add feature G? “Yes, in the next quarterly release.” Notice that you didn’t say NO. You played with the when factor.

Can we change feature H like this? “We can make these changes which get us closer to your vision, how does that work.” In this approach, you are trying to get a little closer to that vision/request while managing against your constraints (time/scope/cost/insert-here).

THINGS TO CONSIDER: Without breaking your constraints, how can you say yes? This helps build relationships and gets closer to the end product (quality/performance) that the end user wants.

Stakeholder relationships can be pain or gain

A group called the Corporate Executive Board publicized research on how a project manager can influence success. They shared that several areas support success such as methodology, domain expertise, and communication. They emphasized that stakeholder relationships are key to influencing success.

Think about it … if your stakeholder is unhappy, the PM will be distracted with getting the stakeholder happy. The PM might have to do “special” research and other distractions just for a particular stakeholder or small group of them. If your stakeholder is happy, then they can support you and (most of all) stay out of your way so you can get the work done.

Effective stakeholder relationships might not be something easily found in a book. The study suggests mentoring and some level of stakeholder management training. The mentoring aspect allows you to better understand how a stakeholder thinks so you can anticipate concern areas, navigate politics, and direct communication better.

THINGS TO CONSIDER: Stakeholder relationships with the PM can support the project or become a distraction. It’s best to manage them well.