I have spent a few days exploring what has been termed a very complex problem.

This type of problem was in some ways familiar to me and I applied a variation of a technique I used before in my work on True Machine Learning.

Although I didn’t solve the problem, I was able to formalize it in precise terms and I was very pleased with the fact that this formalization relied on what is a graph theoretical version of the known philosophical principle all in all.

I created a property of a node in a graph that is described in terms of the geometry of the entire graph to which it belongs, relative to the place this node has in it. This means that the entire geometry of a graph has a version of it described from the point of view of each of its nodes.

The whole is reflected in each of its elementary constituents.

And that is beautiful.

Even as a traditional business analyst, I can be more agile than a agile purist.

This is to make you understand the problems you incur when you simplify complex realities down to a small set of buzzwords and prescriptive practices while not questioning nor understanding those realities. You may actually end up doing the precise opposite of what you claim and wanted to be doing.

I can spend more than a month just in requirements elicitation and analysis — the agile purist nightmare.
At the end of it, I produce my deliverable which is a functional specification. This is a formal, highly structured document that is meant to explain to anyone interested in the project what is to be achieved (but not how, despite some functional constraints can limit those possibilities) as well as to secure the commitment of the business towards the project. This is also called the scope for the projet, that is, the set of things that the delivery team will be working on, or equivalently what the technical deliverables will look like to the customer who will receive and use them.

Delivering a functional specification at the end of a say 6 week work timeline is in accordance with the agile principle “document late”. This principle means to delay as much as possible commitments (in this case, scope commitments), when we will be more certain and have more information about what those requirements are.

During that period, and besides getting the requirements, my focus is in securing alignement between all stakeholders throughout the process.
In the mean time I am not “building” my deliverable, I am using artifacts that help me accomplish these goals. They can be a range of artifacts, but they all have in common that they are meant to evolve with the interactions with the stakeholders and they do not provide any guarantee to any stakeholder regarding team commitments.
These are the artifacts (or the “working deliverables”) that I exchange with the stakeholders. Unlike a formal project deliverable, such as a functional specification or a minimum viable IT solution, they are not meant to be approved by anyone.
The feedback they ask for is intented to adjust those deliverables until the conditions are met for a formal commitment by the team regarding the scope.

An agile purist would in abstract do exactly the same thing as I did here (so you see how the distinction agile/traditional is in this case misleading and atcually meaningless), with one main difference: he would use formal project deliverables to elicit feedback.

The implication of this is that

• I do not incur the overhead of actually implementing a (minimally viable) solution
• I can adapt to change in requirements easier because they impact working deliverables meant to evolve just-in-time
• I am sharply focused in promoting alignment between stakeholders and commitment on their part to the project, which protects the whole team
• I defer the delivery team commitment to the very last responsible moment when it can be done with the least cost
• I clearly separate in the project timeline two very different things which are the alignment between business stakeholders (a focus during analysis) and the alignment between those and the delivery team (a focus during implementation), thus making it more easily manageable and reducing risk

Due to this, I am more agile as a traditional business analyst than an agile purist. So you see, its not the fact that I am a business analyst that prevents me from being agile and even more agile at that compared to someone whose role title or prescription is “agile”. Although I am also formally a (Disciplined Agile) Scrum Master.

This is also in accordance with a (PMI) Disciplined Agile principle, which is that our focus must be in achieving agility, not in following a specific practice or methodology.

From the point of view of the delivery team, one could argue that the priority would be to get early feedback from stakeholders regarding architecture, usability, and other characteristics of the implementation deliverables that are not in the scope of a functional elicitation, however this is always bound to the necessary precedence between models or designs (requirements) and their implementation (IT solutions). You can do it at the same time, in certain circumstances, but that adds the overhead of evolving two very different types of deliverables at the same time with the waste injected by having to make corrections twice instead of once. On the other hand it doesn’t necessarily assure you a quicker elicitation of requirements.

As an example, I had a junior analysts team with me in a project once. I gave them guidance about this subject and in particular I explained them the differences between a formal specification and the working document I was proposing them to use during elicitation.
As I expected, the project manager prompted them to deliver the specifications in the usual two week agile timeframe. They chose to deliver the formal specification while I was constantly delivering the working document in my elicitations (that is, I was not formally delivering but instead I was extending the iterations duration to adjust to my needs, which is a totally valid Lean managment approach). The overhead for them of having to constantly change the formal specification and to explain it to the customers, and the overhead to the customers of having to approve successive versions of the documents, made them extremely inneficient, made the customer weary and insecure in trusting the team’s work quality, to the point that in the end I alone managed to secure more scope than they did altogether, even considering the difference in seniority. In reality, lesser seniority in analysis should point them to work on more simple artifacts, just like I proposed to them. Following a 2-week delivery cadence just for the sake of its name should have been secondary to them, despite being paramount to a project manager with very little analysis skills.

This is a practical example. Of course, I took care to explain to them that in the future, if they will be working as analysts, they should behave as such and not as a project manager trainee with little knowledge of managing stakeholders for business analysis. Therefore, instead of blindly following a project manager’s orders, which is in itself anti-agile because it is prescriptive, they could instead follow the informed advice (which is agile) of more senior practicioners. And thus be more agile than agile purists themselves.

A true analyst OWNS the elicitation process. The interaction here depicted is the ultimate example of the kind of traps an analyst gets into when not in charge of the process, and how to deal with potentially harmful stakeholders.

The subject of building, formalizing and communicating knowledge is closely related to business analysis tasks. Therefore, this course by Prof. Keith Devlin from Stanford is a valuable resource to get to know and to improve in BA. And it is available for free to anyone, as knowledge should be!

Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value.

Business Analysis Book of Knowledge (v3)

Note that this definition does not ascribe the responsibility of performing business analysis tasks to a specific stakeholder in a project. In fact, the same standard states that a business analyst is anyone who performs those tasks, not necessarily a person who has the job title or role “business analyst”. This is why you will read about “business analysis as a mindset” not as as a project role [1]. In reality, the business analysis field gains its vitality from the broad range of skills and backgrounds of professionals from many different fields, technical or otherwise.
Naturally you may ask why then do we need the business analyst role in projects, since not only anyone can perform those tasks but they rightly should be expected to do so. You will understand the answer to this while you read my answer to the heading question as well.

To fully understand this article you need to keep in mind the definition of “stakeholder”. A stakeholder is anyone who as a stake or an interest in a change initiative, that is, someone who is or will be affected by the outcome of the project, directly or indirectly. This includes those who pay for a product or for its development, those who use it, those who build it, and even regulatory bodies who may not even know about the existance of the initiative (until they are required to perform their role). When I started my career (not that long ago) I often heard managers use this definition incorrectly. For them the most important people were those paying, but that is not what defines a stakeholder. End users couldn’t care less about who payed the developers to build the product they use.
As a side note, poor management (and poorly skilled managers) is one of the biggest roadblocks to busyness analysis and its role in achieveng meaningful change, but I will delve into this deeper in other posts.

Now lets answer the heading question starting with an analysis on the definition above.

Enabling change

If we accept as given that organizations need to change in time, then our focus will be in understanding how to enable change.
Now if we accept that a single individual in a organization cannot alone accomplish change, which will be a logical necessity because 1) an organization is comprised of many inter-related individuals and 2) each individual has a particular set of interests or stakes in a given project, then we need to accept that either 1) many individuals will be able to concile their approaches into a single best common strategy or 2) a few indivuals will need to focus on this task alone.

Defining needs

Who is to be responsible for needs definition? Can the party who has the primary driver to satisfy the needs define them alone? As explained before, this may be straightforward in small simple projects or organizations, but not much so otherwise.
And how should that be done? Again, should a single party set the standard of operations? How effectively will a business manager be able to explain his needs to a developer or an end user? Do the work methods of a Director make it easy for a client using the solution to understand if their needs match?
Clearly, there is a need to 1) adopt a common standard in the organization for identifying needs and to 2) devise a way to make it clear if the understanding about the needs agrees between all the stakeholders in the initiative, and finally to 3) reach alignment about the needs the project should address between all parties involved, from business to developers and end users.
I once was in a project that was peculiar in several regards, one of them in that there as an elicitation made (by me) at the same time the developers team was building the solution, that is, they were with me in the same requirements meetings and after each they would turn their understanding into SW while I was updating the elicitation and making the actual analysis work. This was a very good experience in that it allowed to test the subject of this article — did the developers really need a formal elicitation analysis to deliver? The results couldn’t be more clear:

• after the 7th delivery of the team they were still grasping the basic understanding of the overall scope they were working in for several months
• core functional concepts were not properly understood
• not a single of their deliveries passed enough quality criteria to even finish the quality assessments
• each developer had his own understanding of the meetings despite the frequent live interactions with the client and his availability
• they did not verbalize many of their doubts and when they did (often after wasting working hours), I showed them that the answer was already clear in the elicitation I was making even before it was finished
• the client would sometimes contradict himself or leave ambiguity which made things even worse for them (frequent and frustrating rework)

It was months of work of several developers wasted in reaching no specific end goal besides a generalist and poorly functional prototype. The initial assumption, proven wrong in the worst possible way, was that everyone would get the same picture of the needs and in the quality assessment stage only minor deviations would need to be corrected. Does this sound convincing to you?

Recommending solutions

Is a business manager likely to recommend the same approach to addresss a need as that of a computer engineer? Are even technology specialists always on the same page regarding the same problem?
It is obvious that decisions will have to be made by the accountable parties, and sound decision making relies on sound data to support it. This is where business analysis tasks add value to projects. A business analyst (unlike a functional analyst) will many times not have the business or industry expertise required to fullfill this task alone, but it is up to him to reach for the subject matter experts to provide those essential inputs.
I once was in a project with a large team. I got to know about a technical problem the implementation team was facing that was blocking them from being able to reproduce a highly integrated workflow end-to-end, without being stuck in the middle waiting for a reply from an external system. I made an assessment to it and I concluded that we might be able to solve the problem by understanding a feature that that external entity was using for communicating with our system, which as an adaptation of a standard.
When I told a senior SW engineer about this, he promptly replied “we have no budget for that”, even before I laid out my arguments. Clearly he did not understand my position and he had many other (for him more important) things to worry about than my analysis. Faced with this reaction and because of the impact of the problem, I decided to try to solve it myself. I succeeded and soon after the whole project was benefitting from it in hours of work, in complexity of work, in quality of delivery.
Although I as an analyst was not expected to actually build a solution, my point here is that it was essential to have a person in the project who was not being subjected to delivery or management pressure and to be able to clearly and unbiasedly assess a problem and devise a solution. If you are going to make decisions, base your approach on anything better than your casual-under-pressure gut instinct. If you cannot do so on your own, then ask an analyst to help you.

Delivering value to stakeholders

How do you get a dozen or more people agree on the definition of value and on how to deliver it? Do you believe “value” derives univocally from a stakeholder’s need? If that is so, then is the financial value for the Finance Department the same and aligned with, the business value of the Administration Board or with the value of using a solution by the cients?
Clearly there is the need to follow a process to assess the multivaried dimensions of the value that the initiative may bring and to concile those dimensions.
That is a great part of what the business analysis processes are devised for.

A rationale for the change

Can you justify a thousand dollars initiative with a wish from a client, a need from a specific stakeholder, or a management doctrine? If so, then you do not need business analysis.
If you cannot, which will be very likely in not-so-simple change initiatives, then you will need to be able in the end of analysis and prior to implementation, to explain in clear terms why the change has been accepted and why it is being carried out as a initiative with the involvement of many different stakeholders.

Conclusion

By now you should be convinced of the advantages of a business analysis approach.
As a final takeaway, I want you to take the opportunity to realize the implications of all this for the profile of a business analyst.
Do you believe that a person who helps identify needs, understands needs, promotes alignment, assesses value, recommends solutions, has a narrow or highly specialized training or expertise?
Its the precise opposite. The business analyst, if there is one, should be a generalist.
Industry expertise will always be a plus, if managed adequately and this is what is not always granted. On the other hand, a narrow expertise will surely hinder the capability to delier value to the initiative.
I often had to face skepticism from highly specialized SW engineers, until the moment when I told them how to apply mathematics to a problem (or how they were doing it the wrong way) or when I pulled my sleeves back and coded a C# snippet to correctly parse a numerical string value according to regional (locale) settings. I had skeptics from business because I was new to the industry while they were specialized in it, until I gathered their inputs with others and presented them findings which they not only had to accept as correct but that actually brought value to them in the form of new insights or easier approaches to obtain the needed insights.
In this regard, it is important to understand that the industrial education we have today, namely higher education, while it can excel in supplying specialized workers for our industries, is very poor in delivering the broad range of skills an analyst needs.
The implication of this is that 1) experience is more effective in building an analyst profile than formal education and 2) there needs to be an active search for improvement and autonomy of learning from a prospective analyst.
One of the reasons why I love this job is that I can work in completely different areas or industries, which allows me to learn a lot during my working life. This is because an analyst is to master not a specific industry knowledge but a set of skills and tools that allow him to work with industry experts in any field.
I recently learned about the concept of Exformation developed by Francis Laleman [2] and I found it so important that I want to use it to close this article. Exformation is about the (ever shifting) structure underlying knowledge, not about knowledge itself, and that is why it is universally applicable especially in Education (learning & training, which Laleman can show you about in his workshops). Well, because an analyst cannot base his approach on the “knows” given alone (which will often be incomplete and contradict themselves), that is, he also needs to discover new “knows”, he needs a (flexible) structure no less than he needs the actual information — this is where exformative approaches add value tho this business.

____________
[1] Yulia Kosarenko has relevant pedagogical work about this subject and BA in general.
[2] You can learn about Francis and his work at Beyond Borders. If you connect with him on LinkedIn you will benefit much from his insights on a variety of subjects.

Its not all about business phylosophy. Here’s a useful tool for you if you have to keep at hand many textual values such as passwords, usernames, etc., or have to use frequently the same values which you don’t want to do by memory.
The Clipboard is a windows executable that boostraps values from a .txt file; the labels appear on the UI and the associated values are copied to your clipboard once you click on the item in the list.
You can edit the file to suit your needs; it should be located on the same directory of the executable. You can also edit and add or remove entries at runtime, however that doesn’t change the file contents (you have to edit it directly).
Please note that the .txt file is not encrypted, therefore if you use it to store sensitive data place it in a secure location.
Download and unzip the files here [1] and start focusing on the really important stuff!

____________
[1] you may be prompted to login to Dropbox but that is optional; the files are public.

If you are an analyst or if you parse data on a regular basis, you must already have had the need to concile data from different sources regarding the same subjects.
Take a classic example: matching countries codes and phone prefixes. Usually you will find lists for each of those, but if you want the aggregate data by country based on those separate sources you can use this excel (with a sample included for you to evaluate; unzip to access file).
This excel matches the records in two sheets based on the first columns. While the columns match (from left to right) the data is put in a 3rd sheet in the respective row, and orphaned records are left to the end of the list. This means that any number of columns can identify a record. Any differences detected will be signaled in orange background (matched but differing records). In the example given you can see that there is a new column on sheet 2 and that several records were left unmatched.
This of course can also be applied to detect changes in two versions of the same file.
Save yourself precious time and just copy paste your data and click a button!

This is a method by which you can assess the degree of overlap between periodic processes based on their parameters (initial start, duration and period). It was used in a project to minimize the overlap between periodic async processes.
You can download the paper here.

The point here is for you to make an assessment of the best approach to analyse sets, based on the understanding that the sets you are interested in may be related to each other in a “generative” way and that you may be able to generate those sets in a fashion that leads you to identify the “best” set under given criteria.
This allows you to avoid in some cases the usual performance traps on combinatorial problems.
The sets can represent anything as long as they are mapped to numbers because this is a constructive numerical approach. For instance, I applied this approach in a project to identify several ways by which items in a given list could be adjoined to map to items in another list, both lists being related to financial transactions and their values.
You can download the paper here.