Business Analysis Summit (http://business-analyse-summit.com) took place in Frankfurt on 2015-09-25. It is the 2nd such summit organized by German and Austrian chapters of IIBA (https://www.iiba.org/, International Institute for Business Analysis). (The first summit was in 2013 in Salzburg.)
Visitors were ~100 people.
Subjectively they are mostly:
- From bigger companies
- With the „customer“ and „developer“ in the same company
- From financial and automotive sectors
- Wearing suits.
„Business Analysis“ and „Requirements Engineering“ describe largely the same area, whereas BA focus is on analyzing the processes (Business) (and Requirements are for them just output) and Requirements Engineering is all about handling requirements during the project; for them Requirements are an input. In the daily work, the areas are greatly overlapping and the title mostly depends on company’s tradition.
The language of the summit was (mostly) German.
IIBA German Chapter
Exists since 2010. Accepted by IIBA as a chapter officially just 2015.
31 members so far (to become a member first register as a member @IIBA and then apply to German chapter additionally – additional 20 EUR / year).
Next summit is planned for 2017 in Austria.
PMI has recently also activities and a certification program on the field of Business Analysis.
Conclusion
It is good to visit such events from time to time to get a fresh view.
Program
Listing here the items which I visited. The full program is available here: http://www.business-analyse-summit.com/ba-summit-2015/programm/. Presentations are also published there.
Keynote: Disruptive technologies: radical progress, which changes the global economy
Speaker: Prof. Dr. Bernhard Kölmel
„Disruptive“ innovation is one, which makes the previous technology redundant (like cars which replace horses).
The usual S-curves of innovations are well known:
The point of the speaker is – nowadays the waves of innovations are coming much faster, making the need to jump from one to another to an essential one for survival of the organizations. It is supported by the Moore’s law.
For established organization which depends on a certain technology, it is a real challenge however to “jump” to the next wave, because the future business will be in a direct conflict with the current business. Still, organizations have to learn to master it.
And: the need for Business Analysis as a discipline and it’s maturity gets a greater emphasis.
Frameworks (and BABOK v3 as an example – „BA Body of Knowledge“) are essential for this.
The speaker himself mostly is doing consulting for automotive industry. Here his point is that „building cars“ paradigm is being replaced by „providing mobility services“, which is a challenge specifically for German car producers, who are dominated by „German engineering phenomenon“.
Stop scaling… start growing an agile organization
Speaker: Andrea Tomasini
Speaker is from agile42.com – agile coaching community.
He is teaching the teams agile approaches, and one of the biggest challenges is to scale the agile approach over the size of a single team.
There are quite many obstacles to scale agile approach.
Speaker’s point is that most of them are in the corporate culture, and not in the processes/technologies.
Agile pilot is always a success, but rolling it out to the rest of the company often fails. The reason is: culture is not ready to accept the different way of working.
Actually, most of the said applies to any change, not specifically agile processes.
Anti-pattern: standardization before the stabilization.
Speaker suggests much shorter changes-cycles (<12 weeks), where a little bit of definition up-front is done, and then it runs through incremental rollout-document cycle. First try out, gain experience, only then – document and standardize. Emerging standardization.
Another principle: decentralization of control. Delegate to the deapest possible level.
Focus on value delivery. Organization should be along the value delivery process. I.e. the main focus should be on the projects delivering the value directly to the customers. The orthogonal structure of the matrix structure (Units in Axinom language) should be secondary, more treated as „community of practice“.
Traceability: leaving the traces on the way from the need to solution
Speaker: Ursula Meseberg
Speaker is from http://www.microtool.de/, vendor for the tools for software life cycle, i.e. project management (in-step BLUE) and requirements management (in-step RED). Small company with ~30 employees.
Topic for traceability. Speaker explained well different kinds of traceability and how they can be usefull:
- De:Revisionssicherheit („auditing acceptability“) – is not traceability, but is about knowing how an artifact was created and changed.
- Compliance – is also not traceability, but is about to understand how an artifact fulfills external requirements.
- Traceability (de:Nachvollziehbarkeit, bad translation: de:Verfolgbarkeit)
- Pre-requirements traceability: requirements to their sources, e.g. stakeholders. When this requirement come from, why it is there, what did we already discuss about it?
- Post-requirements traceability: requirement to the system artifacts created later in the process (implementation to requirement).
- Inner traceability: requirements to each other (e.g. derived, refinement, dependency, etc.) and requirements to documents (which requirement is documented in which document).
- Requirements-to-Tasks: where and how the requirement is/was implemented.
Maintaining additional artifacts which give a view on traceability (e.g. Traceability Matrix) is too much overhead.
Better solution is to use tools, specifically those which already maintain the requirements in a database. Then adding tracing relationships to other artifacts is not so much of an issue.
However, even then a conscious decision should be made, how much traceability is needed and what the team agrees to keep track of.
Challenges of Big Data
Speaker: Prof. Dr. Giampiero Beroggi
Data Analysis is nowadays a special thread under Business Analysis.
Speaker was for years a chief of the deparment of statistics in Zürich.
He give quite a funny introduction into big data topic. But his main points are:
- Without proper analysis, big data remains just a big garbage can
- But even analysis shall follow the business needs and just help to answer the questions raised by business people
The data chain:
- Big data
- Smart data
- Information
- Knowledge
- Decision
- & 2. are in the domain of informatics. 3. & 4. are about data mining. 1 to 4 is refered to as Business Intelligence. All together is Business Analysis.
Speaker showed many catches if the data is (mis)used without applying higher level filters.
„Better smart as big“
„Don’t outsource your brain“
Business Analysis: handicraft or arts?
Speaker: Heber Ferrarz-Leite
(Speaker is the first CBAP – Certified Business Analysis Professional – in Austria, and is there proud of it J)
The answer was: „the art is only possible when the handicraft is mastered perfectly“ (as everywhere else).
Actually, the speaker presented the main flow of actions of a Business Analyst and touched many interesting questions (also relevant for us).
Main BABOK techniques used:
- Interviews
- Workshops
- Questionaries
Split to PM:
- BA is responsible for product scope or solution scope (=solution to be built)
- PM is responsible for project scope (work to be done).
In a way BA is an internal customer to PM & Team. (Applies to a big company with internal customer!) PM has a budget and can raise concerns to BA. Then BA collaborates on requirements simplifications.
Requirements detalization:
- Business Requirements (why are we doing that at all?)
- Stakeholder Requirements (what is user X to achive with the system) – Use Cases are a reasonable tool to use on this level
- Solution Requirements – most detailed level; input for the project team.
„Cooking recepie“:
- Document the current state (de:Ist-Zustand)
- Optimize (define the target – de:Soll-Zustand)
- The path (Gap) – output here is the solution scope. 6 enablers here (solution is not necessary software, software is only one of):
- Process Design
- IT / automation (software development is here)
- Motivation
- HR
- Policies & Rules
- Facility Design
Requirements traceability is important, because it helps to avoid the scope screep: no requirement can be „just added“ – it has to trace back to a stakeholder requesting it or a business need.
BA is responsible for some project risks, i.a.
- Assumptions made during analysis may be wrong
- Constraints, e.g. time, can lead to unmature assumptions / definitions
(In our case BA is responsible for much more risks, related to the budget – we have a different model because of the external customer.)
85% of the BAs are in the IT departments.
I asked the speaker how the whole story will look like if the customer and developer are in different organizations. Interesting discussion followed, showing that the whole community is acting in different assumptions (all in the same organization) and is not aware of the challenges we face in our daily work.
Job market and requirements for Business Analysts
Speaker: Oliver Voigt
Speaker is from an HR agency Huxley, specializing on financial sector.
They made a survey among their clients asking about Business Analysts. There were 231 answers from BAs (BA professionals leading people) and HR departments. Some main findings:
- BA demand increases recently quite significantly. Reasons:
- Complexity of the proejcts
- Outsourcing
- Moving of the tasks
- Most BA resides in IT
- Certifications: to have it make it easier to come through the first barrier (HR). But ultimately is it not very important, and specifically is not important which certification one has (CBAP, PMI-PBA, CPRE).
- In small companies BAs are seen as all-rounders. It is assumed that BAs can do PM per definition. In bigger companies BAs are seen much more specialized.
- Soft-skills are getting much more important (Empathie, Moderation, etc.)
- HR people have very vague understanding of what is BA. For them it is more „something technical“.
