Adrian Reed
Adrian Reed
Member for
13 years 10 monthsAdrian Reed is a consulting lead business analyst who is passionate about the analysis profession. He is principal consultant and director at Blackmetric Business Solutions, where he helps organizations solve their pressing problems. Adrian speaks internationally, trains, and consults on business analysis and business change-related topics. You can read his blog at adrianreed.co.uk.
Adrian Reed is a consulting lead business analyst and principal consultant and director at Blackmetric Business Solutions, where he helps organizations solve their pressing problems. Adrian also speaks internationally, trains, and consults on business analysis and business change-related topics. Read his blog at adrianreed.co.uk.
All Articles by Adrian Reed
All Stories by Adrian Reed
|
The Importance of "Occasional User" RequirementsOccasional users are likely to go back to more traditional, offline methods if the online equivalent isn’t immediately intuitive. There is little benefit for taking time to learn the system—as they’ll only be using it occasionally. This could impact the business case for moving a process to the web. |
|
How Requirements Can Help Avoid Project Failure and WasteStudies and experience show that higher quality and better value solutions are achieved by projects that attain a thorough and unambiguous understanding of business and user requirements. Adrian Reed looks at how requirements can help avoid project failure and waste. |
|
Making Assumptions on Projects Is a Ticking Time BombAssumptions are a fact of life. Without making assumptions, it’s unlikely that many decisions would get made, and certainly fewer projects would ever get launched. However, sometimes assumptions come back to haunt us. Adrian Reed looks at how to handle assumptions when working on projects. |
|
Brainstorming: A Great Tool for Business Analysts and EveryoneBrainstorming is an extremely useful tool in business analysis. In order to yield maximum results, brainstorming sessions need to be well planned and consider the needs and preferences of the attendees. Adrian Reed provides useful tips for preparing a brainstorming session. |
|
Resilience and the Softer Side of Business AnalysisBusiness analysis is a wide and varied discipline that relies on the practitioner's honing and developing skills in a number of areas. Adrian Reed looks at an important business analysis attribute that is rarely talked about—resilience. |
|
How to Bring Requirements to Life A key skill of the business analyst is to elicit and analyze requirements and to help stakeholders consider a range of possible solutions. Because abstract and logical requirements are extremely hard to digest, Adrian Reed offers concrete ideas on how you can bring requirements to life. |
|
Clean Language in Business AnalysisClean Language originated within the discipline of therapy and focuses on understanding other people’s personal metaphors. It can help business analysts to form better questions and prevent inadvertently leading or pre-supposing a solution. |
|
Dodging the Requirements HazardTacit knowledge includes the knowledge that business stakeholders possess that isn’t codified or written down anywhere—and information they don’t even know they possess. The challenge for business analysts is that it is essential to get at this type of information in order to write requirements. |
|
Business Analysts—Don't Hide from the Data ModelAmong business analysts, there is often a real reluctance to model data as it is seen as a technical activity rather than a business-focused activity. Adrian Reed explains why data models are important, and how they can help map out and understand the problem domain to avoid misunderstandings. |
|
The Importance of Consistent Business RulesOften organizations have multiple information systems with different systems performing different functions. Adrian Reed highlights the importance and benefits of applying common business rules where there are multiple systems. |
|
A Good User Experience Starts with Excellent RequirementsAdrian Reed highlights the importance of creating solid requirements in order to create a good user experience. Techniques discussed include engaging users early in the requirements cycle; stakeholder identification, categorization, and management; and process identification and modeling. |
|
Why Cultural Differences Matter to Project StakeholdersIn a time when many projects span organizations, countries, and time zones, an appreciation of culture—including national culture—is of paramount importance. Adrian Reed explains how cultural guides, comparisons, and observations can be extremely useful for your projects. |
|
Cast a Wider Net to Get the Best Software Requirements Stakeholders often have different views about a software project—the scope, what requirements to include and their priority, and possible solutions. To get the best requirements, you need to talk with and understand the worries, fears, challenges, and ideas of as many stakeholders as possbile. |
|
There's No Such Thing as an IT ProjectAdrian Reed makes the case that there is no such thing as an IT project—there are only business projects that implement, impact, change, or interface with IT. This sounds like a subtle distinction, but it’s deceptively important. |
|
Internal Social Media and the Business AnalystAdrian Reed looks at the use of internal/corporate social media and networks by business analysts for overall process improvement. Key benefits include locating stakeholders, engaging stakeholders, understanding process faults, and finding incremental ways to improve processes. |
|
Do Too Many Business Analyst Cooks Spoil the Soup? Adrian Reed looks at common challenges related to stakeholder engagement and answers the question: How can a business analyst best operate when it doesn’t seem possible to get direct access to stakeholders and when there are multiple BAs from different organizations or different teams in the mix? |
|
Avoiding the Security Black Hole with Non-Functional RequirementsSecurity vulnerabilities highlight the importance of the non-functional side of systems. Creating confident security starts by spending sufficient time eliciting and analyzing non-functional requirements. Adrian Reed explains how to avoid the security black hole with non-functional requirements. |
|
Using Your Business Analysis Skills to Set Career GoalsAs change professionals, it’s easy to neglect career development in the rush to finish projects and “get stuff done.” Why not use the business analysis tools and techniques that you use on projects to help plan your career development? Adrian Reed offers tips for using your BA skills to set goals. |
|
How to Help Project Stakeholders Avoid the AspirinWhen we first speak to project stakeholders, they talk about all of the problematic symptoms—as this is the day-to-day pain that they feel. Developing requirements and solutions around these symptoms might be the equivalent of taking aspirin because the root cause will still be there. |
|
Where Is the Business Analyst in UK Government Software Projects?While the UK government has taken major strides to save money and deliver more with less on its major projects, Adrian Reed looks at the possible implications of the absence of the business analyst role in the government's mandated guidelines and policy manuals. |
|
Seven Tips for Virtual Requirements MeetingsIncreasingly, projects teams are dispersed and may be working not only in different cities but potentially in different countries, continents, and time zones. Adrian Reed offers seven tips to help overcome challenges when facilitating virtual requirements elicitation sessions for a dispersed team. |
|
Project Lessons from the Great Train RobberySuccessful repetition of any business activity can lead to a false sense of security. We often assume that just because something has worked in the past, it will always work in the future. Adrian Reed looks at what we can learn from the Great Train Robbery and how selective perception affects us. |
|
The Great PM and BA DebateThe discussion of the relationship between the project manager (PM) and the business analyst (BA) is quite common, and some see a natural career path from senior BA to PM. The BA and PM roles are complementary—and there may be similar shared competencies—but there is a very different focus. |
|
Cutting through the Requirement Prioritization NightmareRequirement prioritization can be a difficult exercise. Stakeholders often insist that every requirement is essential, and prioritizing requirements can feel like asking them to part with their most treasured personal possessions. Adrian Reed offers three ideas for making prioritization easier. |
|
Playing the Critical Friend through Enterprise AnalysisEnterprise analysis focuses on achieving a solid understanding of the problem or opportunity and the business and customer value that the organization hopes to achieve. An important part of enterprise analysis is acting as a critical friend when stakeholders can't see beyond the silver packaging. |
|
Are SMART Goals Smart Enough?A common way of approaching business and project goal setting is to use the SMART technique (Specific, Measurable, Achievable, Realistic, and Time-bounded), but is it smart enough? Adrian Reed explores a personal goal setting technique, PECSAW, to attempt to answer that question. |
|
Care about Your Business? Then Care about Your Projects!The distinction between project failure and business failure is slight—one can very easily lead to the other. One way to help avoid the downstream issues on any project is to ensure that sufficient project management and business analysis resources are assigned. |
| |
Debate: The Danger of "Negative" Requirements Is it advisable to define a system by stating what it shouldn’t do, or should “negatively-framed” requirements be avoided? |
|
Is Your Data Deceiving You?Do you know how clean, accurate, and up-to-date your data is? Learn how to increase the quality of your data so that your data never deceives you again. |
|
Why the UK Police Are Wrong about IT and Why You Should Care While value for money is always important, a more important question should be “What problem are you trying to solve?” Unless you fully explore the problem, you’ll have no idea if IT is the best solution. |