On Stakeholder Observation

The next time you need to elicit a process, try this: Interview the subject matter expert and document the steps in the process. Then watch them perform the process. Chances are, you will pick up a lot more steps in the process than what they told you. They are not trying to be secretive, they are just being human. They make internal assumptions. By observing the process, you get to see each individual action they perform in order to complete the entire process. Only then can you question the reasons behind certain actions so you can truly understand it - Paul Mulvey

On The Importance of Data Migration

Data migration is typically the most overlooked component of a project that involves moving from an old system to a new system. While there can be many people involved in discovering the new business requirements or in designing a new UI, the data migration task itself tends to be either forgotten or delegated to one person. This perceived simplicity of data migration leads many project managers (and sometimes the business analyst) to think that data migration can be separated from the main body of tasks needed to deliver the system - Yvonne Harrison

On Avoiding Manual Workarounds

We should keep an eye out for “manual workarounds” creeping into our project.  We should challenge the view that “a few seconds here and there is fine” and ensure that our stakeholders have the right data on which to base the decision. Small numbers soon become big and can cripple a business case - Adrian Reed

On Eliciting Customer Needs

There is value in letting the customer drive the conversation—whether it be through the repertory grid approach, or by going to a place where the conversation naturally occurs itself, such as Amazon product reviews. More times than not, this approach can give companies a much better shot at really developing features the market wants, features they need, and ultimately features they will use - Kelly Burroughs

On the Power of Data Modelling

I do worry that too many projects nowadays concern themselves with process rather than content, and with slogans rather than techniques. Data modelling is a well-proven technique that is fundamental for successful business analysis - The Business Alchemist

On the Role of Business Analysts

We know that one of the first things lead business analysts need to do is to uncover the real issue, problem or business need. And then make sure that whatever requirements or ideas are suggested align with the thing we were trying to address in the first place - The Business Alchemist

On Requirements Management

Documenting requirements is an important part of any successful project, but at the end of the day, if we are spending our time and energy on managing the vehicle we use to communicate them instead of the requirements themselves, there is a large risk that requirements will be overlooked, be incomplete, and ultimately not clearly define what it is the business needs to be successful - Kelly Burroughs

On Process Initiatives
“People who can think in ‘process’ really well tend to be perfectionists. They want everything to be perfect – they want to see every little piece of the business and how it fits together like a big puzzle. Senior leaders don’t really think that way – for them it’s more like a chess game. And as long as you have people putting together a puzzle talking to people playing a chess game, it will never work. It’s too big a divide.” It can be taken as fact that technical people and managers think different: both in terms of how they think and what they think about. And unless you’re speaking a language they understand, getting your executives on board will always be a challenge. So the key is understanding what outcomes your organization cares about and reframing what you’re doing as a strategic advantage - Diana Davis

On Benchmarking:

If you benchmark against other competitors you will, at best, only ever be as good as them, no better, most of the time worse and you will always be one step behind the trend. Rather than focusing on what your competitors are doing, focus on what the real need of the customer is and deliver that, innovate the customer experience, there is no easier way to become a market leader…let your competitors benchmark you - Steve Towers and James Dodkins

On Being a successful BA

The successful business analyst follows through with the commitment to solve the business problem by making sure that the solution works well in operation and continues to work well. The successful business analyst assumes that the solution may not be perfect and seeks out ways to improve the solution once it is in operation - Steve Blais 

On Data Analysis

If you have data analysis skills, I encourage you to apply them during requirements gathering. If you are light on data modelling skills, I encourage you to learn more about the subject. Regardless, I encourage you to keep these skills hidden from your business users and let them think you have magical abilities to ask ‘good’ questions - Dan Tasker

On Aligning business objectives with requirements

We cut 80% of features from scope that didn’t align with the stated business objectives, and still managed to deliver a $14 million increase in revenue. By closely considering the business value of each feature and its associated requirements, you can ensure that, not only is the project itself aligned with corporate business strategy, but also that the features of the project are aligned with the project’s business objectives - David Reinhardt

On Predictive Personalization

How do you determine what your clients’ customer wants without being reactive? Quick answer: Data Analysis. Gather the data on your client’s customer satisfaction surveys, user testing comments and customer usage data - Christine Wollmuth 

On Organizing Requirements

The key is to have a logical structure that works for the project team and the wider stakeholder community. It’s important to avoid creating an uncontrolled  ‘junk shop’ set of requirements where everything is present, but nobody can find it. Version control and maintaining some form of central repository is also important. It’s key to consider these things early on so that the requirements can be built and structured in the right way - Adrian Reed

On Achieving Project Success

A student in a project management class I taught once said, “Our project has a fixed budget, we can’t add any people, all of the features are critical, there can’t be any defects, and we have to finish on time.” This project isn’t likely to succeed. For each project, we need to decide which dimensions (Schedule, Cost, Staff, Quality and features) are most critical and how to balance the others so we can achieve the key project objectives - Karl Wiegers

The manager’s challenge, then, is to adjust the degrees of freedom to make the project succeed in meeting its success drivers within the limits imposed by the constraints. Constraints define restrictions within which the project manager must operate; the project manager has no flexibility around a constraint dimension. The project manager has a little flexibility around the drivers. A specified feature set might be the primary driver of the project, but features are a constraint if the feature set is not negotiable. Any project dimension that is neither a driver nor a constraint is a degree of freedom - Karl Wiegers

On being creative:

Neil encouraged the use of techniques like finding analogous problems to the one you are attempting to design for, and using that analogy to uncover solutions which might be applicable - James Hulgan

On curiousity:

So, what does a curious BA look like, what do they do differently?

• They ask probing, open-ended questions that make people stop and think.
• They explore a stated requirement vs. accepting it as-is from the stakeholder.
• They investigate the options and alternatives instead of accepting the first solution given.
• They are open to the possibility that “change” could be good. They ponder, research and communicate the risk and value of change—even if time is short and deadlines are tight - Angela Wick Garay

On Involving Developers & Testers in Requirements Elicitation

Developers are stakeholders in the project, but sometimes their input isn’t solicited and they become the “victims” of the requirements that are thrust upon them. I like to have developers review requirements as they are evolving. That way they know what’s coming and can spot areas that need more clarity. You also need developer input when specifying internal quality attributes that aren’t visible to users. Developers can offer suggestions no one else might have thought about: easier ways to do certain things; functionality that would be very expensive to implement; unnecessary imposed design constraints; missing requirements, such as how exceptions should be handled; and creative opportunities to take advantage of technologies - Karl Wiegers and Joy Beatty

Testers are also likely to find many ambiguities, conflicts, and concerns with the requirements as they are developing their test cases and scenarios from the requirements. Testers can also provide input on specifying verifiable quality attribute requirements - Karl Wiegers and Joy Beatty

On Planning For Requirements

This may sound like a lot of work, but I ask you what are the alternatives?  If we don’t plan, how do you know if you are making progress?  How do you know when you will be done?  What answers do you give your project manager?  A bit of preparation can go a long way to answering those questions - Betsy Stockdale

On Requirements

Rather than declaring the requirements “done” at some point, define a baseline, a snapshot in time that defines an agreed-upon foundation for subsequent work and modifications. Once you’ve established a baseline, follow your change control process to modify the requirements, recognizing the implications of making changes. It’s folly to think you can freeze the requirements and allow no changes after some initial elicitation activities - Karl Wiegers

Don’t use uncertainty as an excuse for lack of precision. Acknowledge the uncertainty and find ways to address it, such as through prototyping - Karl Wiegers

On Delegating 

The other benefit of using visual models is that it is easier to bring everyone up to speed quickly. The models will explain what is going on in the project at a very high and very low level.  Models will show the context of the piece of the project that is being delegated, so it is easy to see how that part contributes to the whole. Your models should be the key tutorial tool you use when explaining the project to new resources - Jeremy Gorr

On Using a Business Objectives Model 

The Business Objectives Model is a separate exercise to discovering your product concept. It begins with problems. The discussions of “What is wrong with your business?” leads to answers that assist in defining the product concept. Imagine your stakeholders tell you that they need claws, large teeth, orange and striped fur, and that they needed it to be an elephant. It means they want a Tiger instead. This, unfortunately, is the state of most businesses, and a large reason why projects fail from scope creep and budget issues – Matt Offers.