Last week my 16 year old daughter took her PSATs. While we were talking to her about how she thought she did, it became very evident that she had no idea why the PSAT was important. She claimed that nobody had told her. We discussed a couple of questions she didn’t know and whether she guessed or skipped them. We asked if she knew which option was the best choice for the PSAT. She didn’t know.

This entire conversation frustrated me quite a bit, as I attended a session with her in the Spring about planning for college and some of the major milestones, including the PSATs. Additionally, for most of the summer I was reminding her that she had access to SAT practice tests and she should make the time to take them as her time becomes limited once school starts. At one point in the conversation, I realized she was right. Nobody had explicitly sat down and said the PSAT was important for x, y and z reasons. The importance was implied within broader conversations, but never explicitly stated.

It was easy for me to extrapolate this problem to project management as there have definitely been in situations where you were challenged with a request for less than solid reasoning, mostly because the other person didn’t understand why you were asking. We see this all the time in features and functionality delivered to spec, but that never at all meet the needs of the requestor. To the person doing the explaining, their why is fully ingrained in their own experiences. Each time he/she does this specific process, they have to execute these workarounds because the business need has outpaced the software development. The software developer sees the requirement for the new feature, and implements his interpretation of it. Unfortunately, the lack of understanding of the business needs and processes often result in a working feature that doesn’t fully resolve the business need (although it might replace the workaround).

Flexible development methodologies that allow for knowledge sharing, iterative review and feedback loops are helpful in minimizing this type of issue. As project managers and analysts, we need to hone our ability to ask “why?” not just “what?” Our documents and artifacts need to be flexible enough to articulate both, otherwise there’s a lot to be lost in translation.