Skip to main content

Should Business Analysts Model Requirements?

Written by Elizabeth Larson on . Posted in Articles. 1 Comment on Should Business Analysts Model Requirements?

During a recent client visit I encouraged the use of modeling as a way to uncover hidden requirements and expectations. One of my clients expressed her rather strong opinion that modeling requirements was not and should not be a part of business analysis work. Oh, she could accept the fact that uncovering gaps between the “as-is” and “to-be” using process models made some sense, but she was adamant that this gap analysis should be done by a business SME, not by a business analyst (BA). As to data modeling, well that was technical in nature and if done at all, she said, it should be done by the technical IT staff. Use cases were helpful to the testing staff, but were clearly technical and were not to be done by BAs. Prototyping? This should be done by developers-no question about that one!

I was surprised at this reaction, which was expressed so emphatically. Perhaps she had no experience modeling requirements and felt insecure about her ability to do so. Perhaps she assumed that the norm for her organization was the norm for the industry. Perhaps she thought that models were truly technical in nature. Perhaps the line in the sand between business analysis and design was clear in her mind and modeling of requirements went into the technical bucket. Perhaps she thought that “solution” requirements (functional and non-functional) had no place in business analysis.

Is the real answer the consultant’s mantra “it depends?” In this instance I’m not convinced that it is. It seems to me that business analysis has to be concerned with what affects the business. If we’re creating a new web page or modifying one, we want to be sure that the navigation makes business sense (process modeling), that the information on the page is flexible and correct (data modeling), that how our customers interact with the website works for them (use case modeling). And I know that when we show people pictures, we uncover requirements that they would never have thought of.

Do these models have to be completed by a BA? No, they don’t. They can be performed by anyone in the organization who has knowledge of and experience in creating these documents. Having just said that anyone can model requirements, however, I’m now going to go out on a limb and make the case that BAs are best suited to model them. Here’s why:

  1. Modeling is a great way to uncover expectations-those unarticulated requirements that are rarely revealed at the beginning of business analysis, if at all. One of the advantages of modeling is that it provides a structure that encourages questions. Business analysts are in the best position to understand this structure and ask questions of the business subject matter experts (SME)s. They also are in the best position to interpret the answers and understand the impacts of responses they receive. Also, BAs generally recognize the importance of asking a variety of questions from multiple perspectives. Creating different models (business process, data, use case, low-tech prototypes) provide these different viewpoints (more about which in a future blog).
  2. Being consultants and liaisons, BAs are in a unique position to understand the business and to translate the requirements into something the designers can design and the builders can build. They can also translate the technical design back into something the business clients can understand and approve.
  3. BAs who can model requirements will almost certainly see gaps that jump out at them, screaming to be addressed. BAs, it seems to me, are uniquely qualified to address these gaps in a way that serves the business and makes sense technically.
  4. BAs are probably more likely than technical staff to go to the business to get questions answered. At the risk of gross generalizations, technical people may have a tendency to answer the questions themselves, without getting input from those who will be most affected-the business users.

My advice is to recognize that business modeling is best done during the business analysis phase(s) of a project and is best done be those who understand their importance in eliciting requirements.

Don’t forget to leave your comments below

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected]

A BA’s View of the Root Causes of U.S. Health Care Conflict

Written by Marcos Ferrer on . Posted in Articles. 1 Comment on A BA’s View of the Root Causes of U.S. Health Care Conflict

After bearing the unbearable sausage-making that passes for problem resolution and debate in our currently polarized political environment, it is time for a BA to speak up on the matter of the Health Care Debate (what, no one asked you either?).

The biggest divide in the debate seems to be between the idea that Health Care should be a free market institution versus the idea that Health Care should be run as a public good available to all.

Let’s ignore the misrepresentation that employer provided health insurance (the primary vehicle for accessing Health Care in America) is a free market in itself.  When was the last time you took a job but rejected the insurance in favor of a personal choice?  In addition, health insurance is so heavily state regulated that, in effect, local oligopolies form, and choices are restricted (try to get catastrophic insurance in Maryland sometime – it can be done, with persistence).

Let’s also ignore the misrepresentation that consumer “spending” out of their insurance plans creates a “free market” in purchasing Health Care.  Once your employer takes potential wages so you get health insurance, your out of pocket costs are typically small enough that it distorts the real price of care, and causes over consumption (ask your local economist what happens when prices are distorted).

Having ignored these misrepresentations, we are now in a position to consider what is missing in this debate that the BA toolkit could possibly help with.

How about Feasibility Analysis?  We can ask questions like “Has this been done before?”   Answer – Yes, by most of the developed nations of the world.

How about Root Cause analysis?  We are the only advanced nation that still has a strong political commitment to the idea that each citizen should have to negotiate the price of their health and lives with mathematical, marketing and manipulation experts, and that this negotiation is “free”.  The whole assumption around free markets is that all parties have the same information, and that each is unconstrained by any coercion.  When my life, or my family’s life is at stake, and I am negotiating for those lives, am I truly “un-coerced”?  When the only “affordable” health insurance is money that I must negotiate away as part of taking a job, am I really free to choose.  SO – ROOT CAUSE – MY LIFE, MY JOB, are SO IMPORTANT to me, and so trivial to the insurance company, that we cannot negotiate from an equal footing.

How about Making the Business Case?  The cost of uninsured, emergency room users is well known.  The cost of health insurance is well understood, including the fact that the U.S. spends more for less than any other developed nation.  The cost of an unhealthy population is trickier, but has been estimated by many economists.  The cost of people being meek on their jobs because they are afraid of losing their health insurance, in addition to their incomes, is even harder to estimate. However, as a BA committed to making things better, it is my observation that people with jobs are mostly afraid, and don’t like to speak up or join in change, leading to the increasing “smoking” of the U.S. by other nations economies and capabilities.

The benefits are harder for people to see, at least at the level of the common good, especially because we have never experienced them, and our culture encourages selfishness first, except in case of disaster. Some still don’t think health care is a disaster, otherwise I am sure they would do the American thing and pitch in.  Nonetheless, these benefits can be estimated, have been estimated, and have been demonstrated in other nations.

How about a little BPR?  I am sure if someone analyzed the time and effort and overhead that goes into delivering a simple freaking checkup, one would conclude that there is a lot of wasted heat and light.  Indeed, a quick and dirty think through would immediately get rid of the “adversarial” fault-based process for deciding to give health care. And it would streamline the process by using rapid expert decision making between doctors and patients. It would also provide quality measurement data on the performance of doctors and hospitals.

Alas, the last issue I mention is the toughest – building consensus and managing the discussion of requirements.  The current environment in Congress and the political landscape is full of “meeting killers”, people who are not interested in solving the larger problem, but only interested in their own turf.

As BAs, we have all seen this, and sometimes we have been able to negotiate good requirements in spite of bad behavior.  If only Congress had a BA – any candidates?

By the way, if you disagree with my analysis, please know that as a BA I am not attached to it – I am happy to sit back and watch those who disagree get what they get, until the crisis is great enough that they can blame me for naming it, and kill me for being the messenger – Sigh!

Keep the discussion coming – I can hardly wait on this one!

Don’t forget to leave your comments below

Marcos Ferrer, CBAP has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. Following graduation in 1983 from the University of Chicago, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in diverse industries. His recent projects include working requirements for the Veteran’s Administration, introducing BA practices at the Washington Suburban Sanitary Commission, and creating bowling industry models for NRG Bowl LLC. In November 2006, Marcos Ferrer is one of the first CBAPs certified by the IIBA. He has served as an elected member of the DC-Metro chapter of the IIBA, most recently as President, and assisted in the writing of the BOK 2.0 test.

© Copyright 2010 Marcos Ferrer

Treat Your Career Like Weight Watchers

Written by Kupe Kupersmith on . Posted in Articles.

This week I caught the Joy Behar Show on Headline News. Joy is one funny lady. This segment of her show was about weight loss/maintenance. One of her guests was the CEO of Weight Watchers, David Kirchhoff. The one thing that has always impressed me with Weight Watchers over the years is their philosophy. Mr. Kirchhoff explained it in three words, education, support, and behavior change. As I was watching the show I kept thinking, that philosophy is what needs to be a part of our daily lives as business analysts.

Education

As we have discussed before, many business analysts are moved or hired in from other areas. Many come from the technical side of the house and others come from the business side of the house. Not until recently have you seen universities teaching students some of the skills needed to be a business analyst. Actually I am starting to see elementary schools breeding future analysts. My daughter’s third grade class was learning about process flows. I almost cried when I reviewed my daughter’s homework. Her teacher thought I was a freak when I ran into the classroom the next day and would not stop thanking her for teaching the kids about process flows. But I digress.

What this means is many of us got into a BA career without any kind of formal training. It is critical for newcomers to get foundational training on the techniques available to business analysts. The projects we work on are critical to the success of our companies. How can we expect consistent positive outcomes from those that have not been trained properly? Why is this tolerated in our field?

Education is on-going and not a one-time event. You don’t go to a class and check off a box saying you did the education piece. I hope blogs like mine and others are educational. There are more advanced classes, books, conferences, online forums dedicated to business analysis and, of course, your local IIBA chapter. My advice is never stop learning.

Before we move on, I want to make sure everyone knows my background/bio. I do work for a business analysis training provider, B2T Training.

Support

In the United States, January is National Mentoring Month (NMM). Created by the Harvard School of Public Health and MENTOR, NMM is marking its ninth year in 2010. By focusing national attention on the need for mentors, as well as how each of us-individuals, businesses, government agencies, schools, faith communities and nonprofits-can work together to increase the number of mentors, we assure brighter futures for our young people. I think it is wonderful that these organizations are promoting mentorship for children. Learning at an early age the value of having a mentor or mentors will help these children succeed in life.

Now more than ever it is so important for us as business analysts to find a mentor. At the same time, we should open ourselves up to become mentors for someone else. It is very enriching to be a mentor. Without mentors, BAs will continually be set-up to fail.

A mentor is someone with experience in a field or subject that helps a less experienced person advance in their career. In the past, companies had a layer of management that moved up the ranks. Part of their role as a manager was to guide and mentor the less experienced team members. Although I am seeing a shift in that BAs are growing up to manage BAs, there is still a large gap. Many BAs are managed by people who have never played the role of a business analyst. This presents the situation where many BAs cannot look to their manager for guidance around the BA activities they do day in and day out. We need the support because we can’t do this alone. Even the greatest Jedi to ever live, Luke Skywalker, had a mentor in Obi-wan Kenobi. Find a mentor that can help you grow as a business analyst.

Behavior Change

It is not enough to get the education you need and find a mentor. You have to make the commitment to change. At times, I am just as guilty as the next person when I come out of a training class/seminar. I am fired up and excited just thinking about how I am going to implement all these new things I learned. I wake the next day, bounce out of bed, and I rush to the office. I sit in my chair day-dreaming about all the new skills I have, and then do the same thing as I did prior to training. This is natural. Sometimes it is hard to determine which of the new skills you should try out and when.

My suggestion is start small and keep building. Brad Childress, the Minnesota Vikings head coach, said he starts his rookies off with a small menu, but with deep knowledge. In other words, he gives his rookies a few plays to focus on instead of the entire playbook. As the rookie gets comfortable with the few plays, he adds more to their plate. Use this philosophy as you learn new things. Don’t try to make a complete change all at once.

Take a few minutes to think about where you may need some education and look for avenues to acquire what is necessary. If you don’t have a mentor, please begin your search to find at least one. Lastly, begin changing your behavior now in small chunks. I think we all know Albert Einstein’s definition of Insanity: doing the same thing over and over again and expecting different results. Together let’s stop the insanity.

All the best,

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected].

BAs Adding Value to Projects

Written by Ian Partridge on . Posted in Articles. 1 Comment on BAs Adding Value to Projects

I’m sure there must be a thesis somewhere on this question: How do you know whether a specific decision or action definitely influences the actual event? I like soccer analogies – in a pre-World Cup game against Argentina, Sven-Goran Eriksson then manager of the English national team, was praised for his tactical decision to bring on Peter Crouch and the 3-2 victory that resulted. Yet, Eriksson was slated for poor substitution decisions during the actual tournament when those decisions did not lead to a more positive outcome. In truth, can you really prove these decisions have either a positive or negative outcome? England may have beaten Argentina without the introduction of Crouch and, during the World Cup, the outcome of the games could have been even worse if the substitutions hadn’t been made!

I would like to think deliberate decisions and actions can influence a positive outcome, and I especially believe this is the case when business analysts work on projects and are able to play an effective role.

Too often I have experienced misunderstanding of what the business analyst role is and what it can add to a project. This article looks at how business analysis activity can have a massive impact on the outcome of a change program.

Context and Challenges

Following an earlier company acquisition, a leading telecommunication company initiated an IT project to decommission a legacy billing and customer care system and migrate to the company’s strategic systems.

Similar projects in the past had taken at least 18 months to complete, were poorly managed, and had run over time and budget. This particular project had been initiated twice before, had not progressed, and there was no documented output. However, expectations had been set by IT that the project would be completed in five months.

Contractual arrangements with the vendors of both legacy and target systems were driving accelerated delivery time scales, and a staff rationalization program was underway in the impacted business area in preparation for the new system.

No resources had been allocated to the project – apart from me, the lead business analyst.

I am a strong advocate of best practice; however, proven methodologies, training and technical skills very rarely provide a ready guide for dealing with challenges such as these!

Scope of the Project

The company’s project methodology was to undertake an initial feasibility phase or, what it was to be in this case, an unfeasibility phase! There was a view among senior management that the changes would impact about 5,000 customers and could be achieved by manually keying customer details from one system to another. In fact, the scoping activity completed as part of the analysis made clear that this was a business transformation project, migrating systems that were at the very heart of the acquired company, and involving very significant changes:

  • 100,000 customers would be impacted, and nearly every interaction they had with the business would change: changes to bills and billing dates; the company brand they were familiar with; changes to the TV channels they received; and other services gained or lost
  • The opportunity to adopt a standard operating model – based on virtual contact centers, centers of excellence and consistent national processes.

Managing Expectations … or Trying To

At a meeting to discuss the way forward that involved senior stakeholders and the recently appointed project manager, I highlighted the issues regarding scope, risks regarding previous projects of this type, and the opportunities the project provided. Although the stakeholders took the issues on board, the time constraints remained, and it was agreed to undertake a five-week impact analysis.

It would be nice to recount that the business analysis view was readily accepted, but this wasn’t the case. Often, the task-focused, project management view of implementation conflicts with the business analysis objective of a quality implementation that delivers value and business benefit. This was the case here. Again, best practice would say that success factors would be agreed upon and defined at initiation, yet this had been ignored The first two bastions of project management – time and cost – were being pushed hard with little consideration being given to the third – quality!

With business analysis resources increased to three and a remit to engage technical staff, a framework was agreed upon to carry out a gap analysis between target and source systems. An aggressive schedule of workshops was planned, and senior managers across the business were consulted to ensure the project scope fully addressed the benefit opportunities and business goals. This also provided the chance to get commitment from areas supplying subject matter experts (SMEs) to the project, as well as re-setting expectations around required activity and timescales.

A key success for the gap analysis was fully engaging the SMEs attending workshops. The approach we took was to be clear about:

  • The drivers of the project
  • Why we were doing this work in a tight timescale
  • Why we needed their involvement

This simple, yet often overlooked, approach had immediate benefits: contact center staff were surprised at the high cost of extending the support of the legacy billing system. They thought the motive for the change was purely headcount reduction. Involving staff in the decision-making reduced resistance to change and led to more motivation and commitment.

The output of the gap analysis highlighted two things:

  1. The impact of replacing these legacy systems was extremely broad and deep. More than 100 sub-systems and interfaces would need to be changed or decommissioned. No simple keying of customer details!
  2. The work was estimated to take 10 months to complete.

Business Requirements and Detailed Analysis

I’m still surprised that in many organizations, and on many projects, the benefit of doing analysis and undertaking requirements is not better understood. I won’t go into the pros and cons of various techniques other than recommending that the activity needs to be:

  • Fit-for-purpose
  • Appropriate to the organization
  • Communicated, in terms of its value, to relevant stakeholders

The output of doing this work on a major project is, undoubtedly, documentation. There were two main concerns we had to counter: the perceived lack of value of the analysis, and that this was seen as the reason to extend the project timescale by five months. I have often seen that tight project timescales lead to under-analysis; business managers sometimes prefer “doing” to understanding the “what” and the “how.” I’m sure many people have experienced solutions to problems that weren’t properly understood, or delays due to extensive change requests. Moving to “doing” too quickly only creates a false sense of progress. With good analysis, you reap what you sow.

The concerns were addressed by briefing the main project stakeholders on what we were doing and why, covering all the detail that would underpin the project plan and providing visibility of the work to be carried out. We also highlighted how independent research supported the link between clearly understood requirements and success – especially for complex projects.

Documentation

We couldn’t avoid the fact that a reasonable amount of documentation would be produced due to the breadth of work. To make this as pragmatic as possible, a document template was defined from scratch to ensure that only the relevant information was captured, that it was easy to populate, and that it would be consistent and easy to read. The format was agreed upon by major stakeholders, ensuring expectations were managed and avoiding resistance to receiving documents.

As for the gap analysis, we were to engage many SMEs and would need to cover a fair degree of technical input. The work was divided into workstreams, each assigned a lead BA and a lead technical analyst (TA) with my role as an overarching lead. Excellent relationships were fostered between the BAs and TAs, helped by the co-dependence of our roles, to make the work a success.

Relationships

I have always believed the softer skills are a far greater asset to a business analyst than the more technical ones. Interpersonal skills make the difference when resolving issues, managing conflict, communicating, influencing, etc. Active relationship building proved really effective on this project. Just as engaging workshop attendees had encouraged participation, and two-way communication helped address resistance to change, good relationships with TAs helped gain more buy-in from SMEs. In the end, more than 100 SMEs contributed to this phase of the project. I have seen situations where BAs and TAs do not work well together and have even heard a TA accuse BAs of “sucking out what we know and then documenting it.” This is perhaps a little extreme, though there is some truth in it when you consider what BAs do in terms of facilitating understanding.

The lead TAs on the project were given joint responsibility on authorship of documents produced. This was not only to address the workload but also resulted in their feeling fully bought into the analysis work and championing the output. As well as being another benefit of having a clearly agreed and pragmatic template, this also really helped in achieving sign-off for the work.

Sign-Off

Whilst communicating the template and approach for documenting the analysis, I also defined and gained acceptance for a sign-off process from the managers who were acting as operational sponsors. They were the people who would be committing their resource to the project, would be receiving the change into their areas, and their approval would be the measure as to whether the analysis was fit for purpose and a success. Attitude to formal sign-off can vary greatly within organizations, even where this is part of the internal governance of project methodologies and frameworks. I really believe that without proper sign-off you don’t have commitment, true buy-in or a proper baseline to manage further change by.

Reviewing the sign-off process led to a better understanding of the issues faced by sponsors, principle of which was the appearance of large documents in their inboxes with no real clarity of what they were really being asked to sign off, little understanding of impacts and insufficient time to review. The answer was a clear schedule of when each output document would be completed. The schedule had been agreed to by the BAs and TAs to ensure it was realistic but challenging, with each document being completed in three stages:

  1. A final draft, quality reviewed with the document authors and workstream leads
  2. A structured document walkthrough with BA and TA leads and nominated SMEs and managers
  3. A final issue for sign-off by the sponsors

This proved really effective for the following reasons:

  • Everyone was focused on delivering work to meet the timescales in the schedule. Involvement in planning this and agreeing to it achieved commitment from everyone.
  • The quality review sessions made sure work was a good standard, consistent across all the areas, and that there was acceptable coverage of analysis.
  • The structured walkthroughs ensured all feedback was captured together and facilitated challenge and understanding of different viewpoints. You knew everyone had read the document as you were going through it with them.
  • Sponsors signed off documents quickly as their direct reports were heavily involved in agreeing to them during the walkthrough sessions.

Summary

Following the approval of this phase, the project moved into development and implementation and went live over a weekend with no problems of any significance. Although it was a month late due to data migration issues, it was described as the most successful migration project undertaken by the company.

A review of lessons learned highlighted the appropriateness of the approach taken to analysis. The effectiveness of working relationships between BAs and TAs, clarity of scope, division of work across functional areas, and the actual documentation were credited as contributing to project success.

The company used the analysis approaches described above as the blueprint for a subsequent migration project that had been on the back-burner for a number of years, and without doubt, the experience of this project gave the company the confidence to undertake it.

Given the opportunity, business analysts can make a real difference to the projects they work on, and the success that follows is no accident.

Don’t forget to leave your comments below

Ian Partridge is an experienced BA manager and business change professional. Currently working as a contractor/BA consultant, Ian has more than 12 years of experience, including media, asset management, telecommunications, banking and retail. For more information visit www.2broconsulting.com . Ian can be reached at [email protected] and [email protected].

Tips for Presenting Requirements and Deliverables

Written by Maria Horrigan on . Posted in Articles.

Business Analysts PresentingIn the past, my presentation of business level requirements has involved walking the business through the 80 pages of UML use cases and watching them glaze over after 10 minutes. I wanted them to understand what they were signing off on but this was not the right way to present the material to my audience. I was finishing up a project recently and was asked to present our teams’ findings, requirements specification and design to the director group.

My project was to develop a consolidated reporting tool that would bring together six different program data sets. So I took a user centered design approach to developing the business requirements and incorporated a lot of the information architecture tools and techniques I had learned on projects over the least three years.

I started with face-to-face consultations and workshopped the needs and wants of the service users who were required to supply reports. I also talked to internal users who would analyze and summarize the reports for the branch’s policy decision makers. We decided to use user stories and personas, want maps and process maps to present our findings about what the users really wanted and then used the site map and a prototype to show how the system would look and feel.

The presentation went extremely well as the directors were taken through the process and had the visual clues to show them what the user experience would be. So why was this presentation approach successful? I think it was because my BA documentation tends to be very visual, as I find that my audience likes to see how the design and the system will work, and need to be brought along the journey. In a recent presentation I told the story through the eyes of the users and found this was a very effective way to present my deliverables.

Here are my top five tips for presenting requirements and deliverables:

1. Establish and Communicate the Purpose. On my project, the service users clearly wanted a system that would help them manage and plan their day-to-day service business, not just a tool to use for reporting back to the funding branch. I presented our findings from the stakeholder consultations and then presented the six personas to demonstrate our understanding of these six key user groups. I told their story by presenting user scenarios and explained why they wanted what they wanted from the system. My key message was that the system users wanted a management tool, not a reporting tool. By clearly presenting this purpose and demonstrating through personas and user stories, the directors understood that this change would mean a win/win at implementation time as the burden of data entry for services would be lessened if there was something in it for them – namely useful management reports.

2. Use Visual Artifacts to Display Requirements and Design. The personas were a very powerful tool to show what the archetypal users of the system wanted and how the groups differed in what they required. We displayed the primary, secondary and tertiary user needs in a want map and this helped to show the key differences and commonalities of wants across the varied stakeholders. The process maps showed how the different groups would interact with the system and how we would help them through the process, streamline the process and reduce duplication of information. The prototype helped to show how automation and integration of data would decrease data entry burden and also capture information that could be used to aid their management and planning.

By presenting deliverables as user scenarios and showing the findings through use of personas and want maps, the directors were able to see the value in responding to the needs of the services as this would, in the long run, gain acceptance and quick wins for the system implementation. Walking this audience through use case after use case would have missed the mark with this group, as it would have been too detailed and technical and would not have given them the same feel for the concept of what the users wanted.

3. Understand your Audience. My presentation was aimed at the business users, and I needed to understand their needs so I could tailor my presentation to meet their needs. I needed to understand who the key players were? Who were the influencers and decision makers? What did they want from this system? What were the relationships between the different stakeholders? This was difficult as it was a short project (only 10 weeks) and I had little direct contact with some of the key players. Therefore, I worked closely with my business product owner to ensure he saw the deliverables in progress and had a chance to comment prior to their being presented to the directors and executives. I sought his guidance on how to handle the meeting; the dynamics of the stakeholders involved, and walked him through the key messages. This preparation meant that I could frame the deliverables in a way that would hit the mark for this audience.

4. Understand the Business Context. Presenting to an audience when you don’t understand their business does not end well for the presenter. In conveying understanding of requirements for the business and users, I believe it is important to know the business context. I did my research and preparation before the meeting and asked myself:

  • What are the key drivers for this change?
  • What processes are involved?
  • What are the internal or external environmental constraints or opportunities out there for this group?

Once you know the context, demonstrate that you understand the business needs and vision. Then demonstrate how your solution will meet that need.

5. No Surprises. In the past I have been reluctant to show my work in progress, as I wanted it near completion before sharing it (as the “Virgo” perfectionist in me wanted to make sure it was right!). In working on Agile projects in recent times, I have embraced this skinny solution concept and am now comfortable starting with a skinny version, and fleshing it out as the work progresses. When I had finished a piece of thinking about users, processes or design, I would share these artifacts with the core project team, the key business product owner and then refine. This iterative approach helped my target audience to get a feel for what the deliverable would look like and meant that, when it was being presented, it was not a new concept, just a more refined and validated version of what they had seen earlier. Remember that you are presenting your requirements design solution, not telling a joke, so sending material out beforehand as pre reading will not “spoil the punch line”. If you feel people may miss the point of your deliverable without you there to narrate, then allow for their questions at the end rather than taking questions throughout the presentation.

Don’t forget to leave your comments below

Maria Horrigan is an experienced business manager, IT strategic planner and information and communications specialist. She has over 10 years senior management experience within the pharmaceutical industry, not-for-profit and Government. As a principal consultant, Maria is an experienced information architect, senior business analyst and IT strategic analyst and provides advice on developing system requirements with a focus on information architecture and user-centred design, to ensure appropriate IT systems are intuitive and usable. She is a senior practitioner and a well-known Australian speaker on communication, user-centred design, and business analysis. She has experience managing large federal government contracts and project management of large scale business system implementation, systems planning, and analysis and change management. She has a reputation for innovation, managing change, driving strategy implementation and successfully delivering programs. Maria is a Board member and Vice President of Women in Information and Communication (WIC).