On Managing Customers

Whether or not an organisation has a Chief Customer Officer, it’s crucial that someone is responsible for championing the ‘voice of the customer’. This needs to be considered in just about every aspect of the organisation at just about every time... When considering changes, great questions to ask can include “Who is the customer here?”, What would our customers say about what we’re about to do?” and “Does what we’re about to do mean we’re appealing to new (or different) customers?” - Adrian Reed

On Business Value

Years later, studies show that projects are not doing much better. Why? Kevin says it’s because business value lies outside the project. It comes before the project – in deciding why to make an investment – and after the project – in helping transition project implementations into operations - Laura Brandenburg

On Solving the Right Problem

How many projects are initiated in response to the acute pain of a “burning platform” where the only option seems to be both drastic and urgent? Yet if the organisation is in pain, has it inadvertently opted for an invasive procedure that might not even be necessary? Knee-jerk reactions lead to unnecessary surgery on our processes, systems and IT; surgery that might even make the problem worse. An extracted tooth will never grow back  - Adrian Reed

On the Importance of communication

Project and organisational change can be scary for some stakeholders — particularly if they think they might be negatively impacted. When there’s no communication, people (completely understandably) fill that void with informed guesses, rumour and suggestions. They draw conclusions based on what they can observe. Inadequate communication on the other hand, can be just as damaging.  The communication has to be appropriate for the audience whilst also being appropriately timed - Adrian Reed

On Being a Good BA

Oftentimes we get so excited about our own ideas and those of our customer that we forget to get the implementation team involved early enough. So by the time we’ve got it all worked out, they feel like all the intellectual challenge is gone. They push back because it’s easy to find issues with another person’s solutions when you have no ownership in them - Laura Brandenburg

On Liaising with Developers

Oftentimes we get so excited about our own ideas and those of our customer that we forget to get the implementation team involved early enough. So, by the time we’ve got it all worked out, they feel like all the intellectual challenge is gone. They push back because it’s easy to find issues with another person’s solutions when you have no ownership in them  - Laura Brandenburg

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.