My husband and I are kicking-off a new and exciting project in our personal lives; having a baby. However, while embarking on what might be called the “Envisioning” or “Planning” phase of the project (aka being pregnant), I’ve found that many of the skills I’ve learned as a business analyst here at ArgonDigital translate into planning for a child.

For example, I’ve been bombarded with advice and helpful hints from just about every corner of our universe; parenting books, pregnancy magazines, doctors, friends, and family members. And, each one of these sources describes things your baby needs, what to do for your baby, and all manner of additional baby “scope.” As this dawned on me, I realized I would need to treat this more like a traditional software development project.

First, I had to think about what my vision or “product concept” for my child was, which is fairly simple; raise a fairly well-adjusted, healthy child. With that in place, I could use my scope management skills learned at ArgonDigital to help me navigate the endless sea of “must haves” for my child.

If you look at some parenting books or go to the baby store to set up a registry, there is a long list of “requirements” for your child, including, but not limited to:

• how many diapers your baby will need in the first year
• bouncers, jumpers, play mats and toys
• how many bottles, nipples, pacifiers, etc. your baby will need
• how to select a day care or pediatrician for your baby

Once I started looking at having and raising a child as a sort of project (one that I wanted to complete on time and under budget, mind you), I started looking at these lists in a different light, comparing each item to my idea of a “minimum viable baby,” those things absolutely necessary for my child to be healthy and fairly well-adjusted.

Similarly, in our work as BAs, we have to help our clients understand what their true product concept/business objective/vision is, and help them discover the minimum list of features to meet that vision. It is only by helping businesses define what they truly need that we can help them manage the inevitable scope creep that arises on every project.

Will my child be less healthy or less well-adjusted if I don’t interview 5 or more pediatricians in my area to find the perfect fit? It’s unlikely, especially since factors like location of the doctor and whether or not he’s on my insurance will play a much bigger role in that decision. Likewise, will that newest, greatest feature suggested by your stakeholder really be a value add to the already defined minimum viable product? Probably not. However, emotions play a big part in both types of projects: as a mother, I want to give my child the best of everything and, as a BA on the project, I don’t want to hurt my stakeholder’s feelings by just shooting down his suggestion.

That’s why defining the business objectives is so important; when you can trace back every feature and requirement to an already agreed upon objective/goal/vision, you can take some of the emotion out of cutting scope. It is easier not to hurt your stakeholder’s feelings when you make a logical argument about how his feature doesn’t contribute to the business objective than it is to arbitrarily say it is out-of-scope.

As seen so far in “Project Baby,” my skills as a BA (specifically in defining business objective and software requirements) has translated into helping me as a soon to be parent. With any luck, my BA skills in elicitation and facilitation will be of great help to me as I continue in this “project” and, hopefully, my experience as a mother in dealing with an especially “difficult stakeholder” will help me become a better BA.