I came across a couple of articles on the HackerNoon website about real world requirements that I thought were worth sharing. They are Part 1 and 2 of a 4-part series that are being written by Matt Hartley about his experiences developing software in the healtcare industry, with a common thread throughout the articles being requirements.

Click this summary to read the rest of the post!

As of today, almost 8 months after it started, the transition of the site away from Wordpress is complete. Re-creating 51 blog posts and 47 wiki articles took longer than expected. Especially since this couldn't be my top priority by a long shot.

In this post I go over some of the goals of the change, what remains, and provide a bit of a timeline for those who are curious.

Click this summary to read the rest of the post!

I came across a link on Hacker News to a new web site that describes the Domain Storytelling technique.  I haven't finished reading through all of the content, but it looks like something worth reviewing especially if you work in a Business Analyst-type role in Agile processes. But as always, you might useful ideas even if you don't work in Agile.

Click this summary to read the rest of the post!

After a really, really, really long time; I have finally added a new page to the wiki.  This one is on the Investment Logic Mapping technique.  Investment Logic Mapping (ILM) is part of the Investment Management Standard that was defined by the Australian State Government of Victoria, and which has since been adopted by other entities in Australia as well as the Government of New Zealand.

I have added it to the wiki because I believe it's a technique that could be very useful to Business Analysts who are trying to define stakeholder understanding and agreement of what the need is for an investment (be it a project effort or otherwise), what's driving the need, what the benefits of addressing the issue would be, and how those benefits will be measured.

Click this summary to read the rest of the post!

In this post I am going to discuss a specific problem I encountered with a data extract in the form of an Excel file. That problem was that:

• Out of about 25 data elements in the file, only about 10 were in distinct columns
• The rest of the data elements were concatenated together into one string in a single column
• There were nearly a thousand rows of data and I would be getting a new file every month, meaning a manual solution was not desirable
• The discreet data values in the string were not always consistently present (e.g. a value might be present in one row but not another)
• The data values in the strings were not always in the same order

So in this post I am going to go through the logic and eventual Excel functions that were created to solve this problem.  Hopefully you find it useful.

Click this summary to read the rest of the post!

2017 was a busy year personally. I wrapped up a 3-year enterprise-level project; which led to me accepting a junior management position leading a very small team of business analysts; I bought a house; and generally dealt with a number of the curve-balls that life throws at you.  All of which unfortunately meant that this site did not get nearly the attention I hoped.

On a positive note, my goal of writing content that has a longer shelf life and having this site act as a sort of reference resource seems to be working even with a bit of inattention.  2017 saw the following improvements in site metrics over 2016 (as measured by Google Analytics):

Click this summary to read the rest of the post!

Every once in a while I come across an article that discusses some subject in an incredibly clear and thoughtful way.  Issue 2017-02 of IREB's Requirements Engineering Magazine online contains just such an article.  It's titled The goal is to solve the problem and it's an article that I recommend any Business Analyst or Requirements Engineer read.  And if you are relatively new to the field I recommend it even more.

Click this summary to read the rest of the post!

If you haven't read it yet, last month Modern Analyst published an article by Adrian Reed titled The Crucial Art of Pre-Project Problem Analysis that I really, really, really recommend you read.

The article talks about how BA's can add value both inside and outside of the project environment.  It's relatively short but it speaks to issues I have seen over and over again; and that other BA's I have spoken to have mentioned many times as well.  So it really speaks to issues that I think are important to all BA's whether you are a project BA or not.

Click this summary to read the rest of the post!

If you have never watched one of Gojka Adzic's presentations, you really should.  This one is about 3 months old and in the first part is one of the best discussions I have seen on why so many projects and requirements efforts, including those that are Agile, fail to deliver value.  He also has some valid comments on Business Analysis at around the 32 minute mark, and provides some suggestions on addressing some common pitfalls with Impact Mapping starting at around the 37 minute mark.

In my opinion, this one video has more value to Business Analysts than any webinar I ever attended.  If you have the time, give it a watch.

Click this summary to read the rest of the post!

Back in January I was interviewed by Dave Saboe for his Mastering Business Analysis podcast.  The interview came about as a result of the LinkedIn discussion that resulted from my "The Role of the Business Analyst - It's Time for a New Perspective" article that I had posted on this site.

Click this summary to read the rest of the post!

Just a couple of quick news bits from the world of Business Analysis certification that I came across recently and which I thought worth sharing here.

Click this summary to read the rest of the post!

The conceptual role of the business analyst has evolved over the years.  Unfortunately, in my opinion it has not evolved enough in either the minds of most business analysts or in the minds of those who employ them.  For far too many the role of Business Analyst is still one that is focused only on project work and for most of those it is one that begins and ends with requirements.

But that concept of the role of the Business Analyst is one that I emphatically disagree with.  I believe that it inhibits the application of business analysis skills to situations where they could benefit the organization and which thus reduces the value the business analyst can provide to an organization.

While the IIBA has attempted to change this view with the new definition of what a Business Analyst does in BABOK v3.0, I think that definition also misunderstands and short-changes the role that the business analyst can play in an organization.  I believe that even the newest IIBA definition continues to tie business analysis (as both a function and a job) too closely with the project environment.  And that this close conceptual tie to project work is holding back the profession and limiting its value.

So with this article I want to build on the concepts I started putting forward in April 2016 with my post "Have we mis-identified the core purpose and value proposition of Business Analysis?"  I want to put forward for discussion a new perspective of business analysis that I hope will both broaden and clarify the concept of what a business analyst does, and how it can provide value to organizations.

Click this summary to read the rest of the post!

Due to work and other commitments I ended up taking December 2016 off as far as new material for this website goes.  But I have several articles and wiki pages in progress and hope to get the new material coming soon.  In the meantime, here are some quick statistics for the website for the 2016 calendar year vs. the 2015 calendar year:

Click this summary to read the rest of the post!

Ron Ross recently had an excellent article on Modern Analyst titled "The Story of Al's Spreadsheet and Absent Brains" in which he makes several very valuable points.  Those include ...

Click this summary to read the rest of the post!

Way back in 2000, Joel Spolsky wrote a series of articles on his 'Joel on Software' blog (highly recommended) that discussed Functional Specifications.  Now, given that this was written back in 2000 a lot of people will say it is out of date and no longer applicable.  But I think there are many valid points in his set of articles that any BA should think about.

Below I have provided a link to each of the four different articles in the series, along with a sample quote from each.  You may find that what Spolsky has to say resonates for you, whether you follow an 'Agile' or 'Non-Agile' process.

Click this summary to read the rest of the post!

I was recently reading an article surfaced on Hacker News that included a link to this November 2015 blog post by Joshua Kerievsky titled Modern Agile.  In it he lays out the four disciplines he sees that make up the core of 'Modern Agile' and then maps many agile practices to those disciplines. 

Click this summary to read the rest of the post!

As a follow-up to the new wiki page on the Fishbone Diagram a few weeks ago, I have added another new wiki page on the Five Why's technique.

Click this summary to read the rest of the post!

If it’s not obvious from my prior posts on this subject, I’m a fan of Microsoft OneNote.  I think it’s a fantastic tool for business analysts, but it definitely has its quarks and limitations.

This post will explore OneNote’s various search functions and discuss two ways you can structure your OneNote content to take advantage of its strengths while working around its limitations.  Specifically, using one notebook per project or effort; and defining a reusable folder structure that enables you to best leverage OneNote’s searching and tagging functions.

Click this summary to read the rest of the post!

I've added a new page to the wiki that covers the Fishbone Diagram.

Click this summary to read the rest of the post!

A co-worker shared this video today and I thought it was so good I would share it here.  It's not just an excellent overview of the role of the Product Owner in Agile, it also provides a good 'business-oriented' overview of Agile itself.

Click this summary to read the rest of the post!

Tags are a feature of Microsoft OneNote that are often overlooked by users, but which can have out-sized benefits for Business Analysts, students, or others who use OneNote as a tool for gathering notes and information from a variety of sources.

Click this summary to read the rest of the post!

Matthew Kern wrote an article on LinkedIn titled "Agile is Dead" that seems to be going somewhat viral among the project and development communities.  As of the time I am posting this it has almost 150,000 views and is up over 20,000 views just since this morning.

Click this summary to read the rest of the post!

I have recently found myself wondering if we have fundamentally mis-identified the core value proposition of business analysis, or if my view of the issue is skewed by past experience?  So I thought I would lay out my thoughts and see what others have to say.

Click this summary to read the rest of the post!

For a while now I've been studying up on the more enterprise aspects of business analysis, including business architecture and business strategy.  And this new wiki page on the VMOST Analysis technique is first page that has come from those studies.

I plan to add other wiki pages that will eventually cover even more of the enterprise and strategic aspects of business analysis (in my view of the broadest sense), but they may be a bit slow in coming.  Just to give you an idea, I think for this article alone I ended up reading more than 350 pages of material and even then I am sure there are aspects I missed.

Click this summary to read the rest of the post!

I had a call this morning from the IIBA to confirm whether I had received their emails reminding me that my membership had expired (yes) and whether I had deliberately not renewed (also yes).  I was at work and didn't really have time to chat, so when they asked why I was choosing not to renew I gave a few quick responses and had to end the call. But I wanted to explain my logic in more detail here so that:

1. I could see if anyone else out there has the same issues I do or can provide good reasons why I am wrong
2. I could provide a fuller explanation in case anyone from the IIBA actually cares and is willing to consider changes
3. In hopes of changing the minds of some people so that they too stop being IIBA members

This isn't going to be short, but I'm going to try and keep my discussion of each issue relatively brief if I can. Please read on if you are interested.

Click this summary to read the rest of the post!

My former colleague Benedicta (Ben) Makin posted a great little article on LinkedIn that I wanted to share.  It's on the importance of communicating simply, and it's something I think BA's really need to pay attention to.  I know it's something that even after years of trying I still need to improve upon, so Ben's article was a welcome reminder.

Click this summary to read the rest of the post!

I want to present an idea I had for a business analysis artifact that I am currently calling an Analysis Cross-Matrix.  I don’t know if it’s original, although I haven't seen it anywhere else.  I don’t even know if it might be particularly useful, or if there are existing techniques that can do the same thing better. That’s why I am posting this article.  I want feedback.  But so far it seems potentially useful and the initial feedback I’ve gotten from a few co-workers was mostly positive.

Click this summary to read the rest of the post!

I have several large research projects ongoing for the wiki that are limiting my ability to generate as much new content as I would like.  So in the meantime I finished writing up a wiki page I had started a while ago but never completed.  This one is on Decision Tables.

Click this summary to read the rest of the post!

I want to share a quick software tip in the form of a couple of Excel formula's that I wrote.

These formulas convert single cells with names in [Last Name], [First Name] order to [First Name] [Last Name] order.  The first version leaves in middle initials and suffixes. The second version trims everything after the first name. You can also use portions of these functions to pull out portions of names into separate cells.

Click this summary to read the rest of the post!

In April 1946, an article titled Politics and the English Language by the English author George Orwell was published in the journal Horizon.  In it, he railed against the use of vague and over-stylized language in political speech and journalism. Despite it's age, I believe there are lessons for Business Analyst's contained in the article.

Click this summary to read the rest of the post!

If you're a BA who does most of your diagramming with Visio, you no doubt know that it's not uncommon to want to share your work with someone who does not have Visio installed on their computer.

Most BA's I know get around this by embedding the diagram in a Word or PowerPoint file, since almost everyone in a business environment has those applications available to them.  Or possibly even into Excel.  But embedding your diagram into a different Office application has its downsides.  The diagram is often re-sized, is constrained to the 'page' size, and often loses resolution or visual quality.

Another alternative many BA's use is to save the Visio file as a PDF.  And while most people have Adobe Reader or an equivalent installed, this adds bloat to the file can put into a less intuitive interface.

One option I don't see used often is to save the file from Visio to the SVG (or Scalable Vector Graphic) format.  SVG has the advantage of being designed for images, especially line-based images, and of being natively supported by a wide range of web browsers.  SVG also has the benefit of being a vector image format (as the name states), which means that the diagram can be scaled up or down to whatever size the user prefers without losing ANY resolution or sharpness.

Click this summary to read the rest of the post!

A common refrain of the Agile movement is that you can't predict future requirements, but it's one I've never completely agreed with.  Can you predict 100% of future requirements, 100% of the time, with 100% accuracy?  No.  But that does not mean for certain that you can't predict some likely future requirements and design your solution so that you can either include those capabilities in your initial solution design, or define your solution architecture in such a way that adding those capabilities in the future is much easier, quicker, and less costly than they might otherwise be if you made no attempt to include them from the beginning.

And while it's fine for me to say that, the question is how might you go about determining some future requirements or some future events that may drive future requirements in a systematic, thoughtful way?

Luckily, there is a technique from the field of Futures Studies (that is also used in Social Studies, Political Sciences, and other fields) that is both useful for Business Analysis work and relatively easy to execute.  That technique is the Futures Wheel.

Click this summary to read the rest of the post!

As you may have figured out by now, I’m a big fan of Microsoft OneNote.  I find it to be one of the single most useful tools I have as a Business Analyst.  And I don't know about you, but as a BA I take part in a LOT of meetings.  Project status meetings, elicitation sessions, stakeholder meetings, departmental meetings, and so many more.  And at a lot of those, I either want to or have to take notes.  So here are three quick tips one using OneNote to make your meetings notes (and maybe a few other things) a little bit easier.

Click this summary to read the rest of the post!

I updated the wiki page on Waterfall today, nearly doubling its size to what is now an article roughly 35 pages in length if printed.  As with the previous version, I'm trying less to describe the common interpretation of what 'Waterfall' is, and more trying to show that the common interpretation seems to be wrong based on the historical documents.  Or at least that the common interpretation of 'Waterfall' may never have existed as anything more than a straw man.

I'm not a fan of the 'Waterfall' concept as it's normally described, although I am a big believer in analysis and design up front (both of which can evolve later, but the more you do early the better you understand your current situation and where you want to go).  But the thing I find fascinating about 'Waterfall' as a concept is how like a mystery novel it is.

Click this summary to read the rest of the post!

I've been working on several projects lately (only one for this site) that have collectively meant that there have been less frequent updates to this site than there has been in the past. But I came across something today from Nancy Duarte that I really thought was worth recommending.

Click this summary to read the rest of the post!

An article in the current version of Requirements Engineering magazine (offered for free online by the IREB) caught my eye earlier today and I thought it was definitely worth recommending here so that others could give it a look.  The article is called TORE - A Framework for Systematic Requirements Development in Information Systems and is written by several people who work at the Fraunhofer Institute for Experimental Software Engineering.

Click this summary to read the rest of the post!

Perhaps the single most important thing a business analyst can do when they start working on an initiative (whether it be a project, process, or problem analysis) is to learn the language of the stakeholder(s) they will be working with.

Learning the language of your stakeholder(s) should be among the very first tasks you undertake as a business analyst. Indeed, in my opinion, it is the very foundation of EVERY other activity a business analyst undertakes with that stakeholder.

• It is difficult to understand the business problem(s) you are trying to solve if you do not understand the subtleties of the language the stakeholder is speaking. Even common terms used within the larger organization can have subtly different meanings to your stakeholder that are important for you to know.
• When working with multiple stakeholders, you cannot communicate optimally with them if you do not do so in language that they understand at the most complete level.
• When working with multiple stakeholders, you cannot identify potential differences in stakeholder needs if you do not understand the exact language each stakeholder is speaking,
• You cannot most effectively plan to elicit information if you do not know the meanings and relationships of the concepts the stakeholders use.
• And you cannot fully understand the information you elicit from stakeholders if you do not understand the full meaning of what they communicate.

How do I propose you learn the stakeholder’s language? By using glossaries and concept maps.

Click this summary to read the rest of the post!

I've been a bit busy lately and haven't posted anything new to the site, but over the weekend I came across a white paper titled How Do I Know What Questions to Ask? that I thought was worth recommending.  It's from Roxanne Miller over at Requirements Quest and it's a nice 20-pages or so discussion of planning for interviews as part of requirements elicitation.  There are a couple of pages of example questions, tips on planning what questions to ask, and information on identifying the stakeholders you need to be involved.

Click this summary to read the rest of the post!

I have added a new wiki page on the Matrix Prioritization technique as an addition to the set of prioritization wiki pages I posted earlier this month.

Click this summary to read the rest of the post!

After working on them off and on for several months I am posting the first batch of wiki pages related to prioritization today.  The new pages include:

• A wiki page that extensively discusses the concept of Prioritization
• Several wiki pages that discuss specific prioritization techniques in detail.  These include:
• Category Assignment Prioritization
• Cumulative Voting Prioritization
• Hierarchical Cumulative Voting Prioritization
• Hierarchical MoSCoW Prioritization
• Kano Model Prioritization
• MoSCoW Prioritization

As usual, I've tried to make these in-depth information resources that include step-by-step instructions.  My goal is to provide a reference that goes beyond what you are likely to find anywhere else on the web if that seems feasible.  In particular, the Prioritization concept page and the Kano Model page have more consolidated information than I have found anywhere else.

Click this summary to read the rest of the post!

If you haven't seen it yet, you really should watch the YouTube video below. It's based on a Russian story (link to the original in the YouTube info section) and shows the occasional absurdity that goes along with being a Business Analyst, a Systems Engineer, or any other expert role that runs head-first into a business need that just doesn't make sense. It's hysterical and sometimes so true it's painful. It had several of my co-workers laughing out loud.

Click this summary to read the rest of the post!

In case you missed it, I wanted to point out that the International Requirements Engineering Board (IREB) recently launched an online magazine aimed at Requirements Engineering professionals called (appropriately enough) Requirements Engineering Magazine.

Click this summary to read the rest of the post!

After about three and half months of (mostly) weekend study, I sat for and passed the Certified Professional for Requirements Engineering - Foundation Level (CPRE-FL) exam today. And for anyone interested or who might benefit from it, I thought I would share some thoughts on the certification itself, the exam, and my study process.

Click this summary to read the rest of the post!

I added a new wiki page for Use Case Diagrams.  I'm not a big fan of them, so there may be ways the sample diagrams could be improved or even have errors.  But since I had to study up on them as preparation for the CPRE-FL exam, I tried to make the information as accurate as I could since I might be tested on it.

Click this summary to read the rest of the post!

I've never been a fan of Use Case Diagrams.  I always thought they were an example of forcing information into diagram form that is better captured in a simpler structure, just because someone thinks diagrams are always easier to understand.  Or because the folks behind UML thought they had to have a diagram for every possible need, no matter that putting some information in diagram form actually makes some things harder to understand.

For systems with lots of functionality and dependent use cases, a Use Case Diagram can be practically un-usable.  Especially once you start having a lot of Extends and Includes in the diagram.  Luckily, most of the Use Case Diagrams I have seen don't have many actual use cases in them, and have few or no Extends or Includes.  For the simple systems, a Use Case Diagram isn't that bad.

Click this summary to read the rest of the post!

I added a new page to the wiki section.  This one is on Decision Trees.  As usual, I tried to go beyond what is on Wikipedia.  But I would really like suggestions for improvements on this one.  I've used decision tree's occasionally as a BA, but always in the logic-mapping way.  We very rarely use them in the business decision way at my employer, and when they are done they are almost always done by the PM.  So I did my best based on past classes, a small bit of secondary experience, and what I could find on the web.  But I'm sure there is room for improvement.

Click this summary to read the rest of the post!

I added a new page to the wiki that covers the Unified Process and it's major variants.

Click this summary to read the rest of the post!

I wanted to try and wrap up one more of the many wiki pages I have in progress on this long Thanksgiving weekend, so here is one more new entry for the Wiki.  This one is on Feature Tree's. 

Click this summary to read the rest of the post!

I added a new page to the Wiki that covers Decomposition.  Originally I was just going to write about Functional Decomposition since that is what is in the BABOK, but when doing my research for writing the page I came across too many other examples of when Business Analyst's use a broader range of decomposition types.  So the wiki page covers structural, behavioral / functional, and goal decomposition.  I have also included very simple examples of documenting decomposition with a diagram, an outline structure, and a table structure.

Click this summary to read the rest of the post!

Have you ever struggled to explain to someone what you do?  Not just to that distant cousin at the family Christmas party, or the random person you are chatting with in line at Starbucks; but people who actually work within your organization?  Or even worse, the senior people who are going to be taking part in your project and who have no idea what a Business Analyst does?

Have you mumbled something about projects, processes, and software?  Maybe mentioned requirements elicitation, analysis, and documentation?  The problem isn't that you don't know your job, the problem is that your job title is wrong.  We are not business analyst's.

Click this summary to read the rest of the post!

This new white paper by Joy Beatty of Sielevel and Karl Wiegers popped up in a recent Google search I did.  It's short but has some nice info and ideas in it so I thought I would share.

Click this summary to read the rest of the post!

As part of a BA discussion group at work, we were discussing different ways to encourage a focus on defining the root cause of the problem before a solution is specified. We had all had far too many experiences with a business partner saying the problem is that the system does not .... (have a drop-down here, have this extra screen, a button for this, etc., where the problem is defined as the lack of the solution they have already decided upon without any investigation to ensure that the problem has been correctly identified. I brought up the use of Problem Statements, and was asked by my peers to write up my ideas in more detail. I ended up writing it in article format so that it could be shared ahead of time, and it was deliberately written to generate some discussion. I hope you find it useful as well.

Click this summary to read the rest of the post!

I came across a post on the HBR Blog Network (part of the Harvard Business Review web site) that was directed at business leaders, but which I think applies to business analysts just as well.  The blog post talks about 5 steps that you can take when failure has occurred in order to adjust, learn, and hopefully not repeat the mistake.  It's a simple lesson that applies to much more than your professional career, so I thought it worth sharing.  Enjoy!

Click this summary to read the rest of the post!