Network design heavily relies on the first and most crucial of the steps to success, the ability to uncover business and technical requirements and constraints. Failing this step means the design you create, no matter how “cool”, may fall short of satisfying your customer.
How do you go about uncovering these requirements? There’s a discipline around eliciting and specifying requirements, among other things, called Business Analysis or BA. According the International Institute of Business Analysis, BA is “the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders. Business analysts work across all levels of an organization and may be involved in everything from defining strategy, to creating the enterprise architecture, to taking a leadership role by defining the goals and requirements for programs and projects or supporting continuous improvement in its technology and processes.” Sound familiar?
What can we learn from BA? Eliciting – not gathering! – requirements from your customer! According to the Oxford Advanced Learner’s Dictionary, “elicit” means to get information from somebody often with difficulty, whereas “gather” means to bring things together that have been spread around. Did I say this task is easy?
The business or technical requirements are typically not readily available or documented, but rather it resides in the minds and hearts of the stakeholders. The BA methodology to uncover requirements involves preparing for elicitation, conducting the elicitation, and confirming the elicitation results. I think that by learning some of the BA tricks the chances of success increases.
Preparing for elicitation
Elicitation as opposed to gathering is an active task, therefore it needs some preparation. Who are the key stakeholders for the project (enterprise politics come to mind)? Try to ensure that the meeting or workshop you’re facilitating to uncover the requirements for the project has a good representation of decision makers, architecture, engineering, operations, end users, and they all are informed of the goal of the meeting or workshop in advance.
Determine which technique or techniques you will use for eliciting requirements. They can include:
- Get the stakeholders together and, making sure they feel free to speak up and with the business needs in mind, brainstorm with them to come up with the requirements and success factors of the project.
- Is there any documentation or diagrams available at all that can tell you what the current state of the network is, the reasoning why it is the way it is, the policies (security, BGP, HA, etc.), baselines, traffic patterns, application requirements, footprint, SLAs, vendor preference?
- Either passive or active observation/shadowing of end users interacting with the various applications to understand what it is that they really care about and opportunities for improvement.
- Interview the stakeholders one-on-one for an in-depth understanding of why there is a project in the first place, where the business is going, theirs needs vs. wants, the critical network characteristics and capabilities, the current pain points, constraints (budget, regulatory, schedule, etc.), their risk-taking levels, and success factors.
Conduct the elicitation
Now it’s time to execute your elicitation plan. It can happen once, but typically it happens throughout the project lifecycle, but the more you uncover upfront the less back-and-forth will be needed later. As you do the elicitation, record the sessions if possible, and document your findings and assumptions in detail. This quote from Henry Ford is quite interesting and tells us there might be traps along the way: “If I had asked people what they wanted, they would have said faster horses.” Your stakeholders may have preconceived beliefs and ideas that may get in the way of your elicitation task. Instead of focusing on the How, focus on the Why!
Confirm elicitation results
Once the initial elicitation is over, but before you go to the drawing board, it’s time to share your collective findings with all stakeholders to confirm your understanding of the project needs. Since the elicitation may have come from multiple angles in multiple events, it may be the case that not all stakeholders have a complete view of the project, so showing them all your collective findings is important. Make additions, changes, and/or deletions to your Business Requirements Document as necessary and get the customer’s approval so you can proceed with creating your network design options.
We can learn from the Business Analysis domain a few techniques on active eliciting of requirements, constraints and assumptions to increase the chance of success on our network design projects. Not all tricks will be used all the time or on all project sizes, but now you have a new tool in your toolbox.
Do you meet with the right stakeholders to elicit requirements for your design projects? Do you have a favorite methodology to elicit requirements? Is there a topic you want to hear about on my upcoming blogs? Add it to the comments field!
Elaine Lopes is the CCDE and CCAr Certifications Program Manager and Team Lead for the CCIE program team, and she’s passionate about how lives can change for the better through education and certification.
Here are a few additional ways for us to engage and keep the conversation going:
- Cisco Learning Network CCDE Study Group
- Connect on Twitter too
- CCDE study materials for the Written and Practical exams
- Related Unleashing CCDE blogs: CCDE: Book of Questions, Customer Engagement in Network Design with Emanuel Lipschütz, Business Requirements in the Network Design Process with Daniel Dib
- Related Links: International institute of Business Analysis