In some of blogs I mentioned that our organization knows the job position of project lead and business analyst. Especially the job position of a project lead may sound strange in a lean and agile organization without projects. Actually we never discussed these names, we just reused job position names that were around. The names existed when I joined Digitec Galaxus. Nevertheless names for job positions matter. The reason is that everybody in an organization assigns a set of responsibilities with these names. Everybody knows what to expect from a person acting in the job position of X.
Unluckily job position names can as well lead to misunderstandings. In my experience only a part of the persons in an organization are able to distinct between a job position and a role. This sometime puzzles persons if two persons with different job titles act in the same role, for example in the role of a business analyst. In our organization for example persons in the job positions business analyst, project lead, erp specialist and software engineer are regularly acting in this role. And it does not help that the name of the job position is identical to the role name. A typical question is “What, now a project leads does some part of the business analysis, I thought this is done by our business analysts?!” The more interesting point is: where is the difference, what are the responsibilities that are unique to a job position. You have to communicate rather these “unique owned” responsibilities within your organization. This fosters persons to discover the responsibilities of a job position and to receive support fast in case they have a request for this special responsibility.
Now, to discuss the job positions of project lead and business analyst it is interesting to look at the roles and responsibilities of the job positions. What is the common set and what are the “unique owned” responsibilities.
Just to remind to our SAFe like system working with initiatives and fastlane. Initiatives implement desired changes derived from our strategy or based on a demand coming from a department. Larger changes, like building up a new logistic center, introducing a standard software for X are decomposed into a set of initiatives and called a theme. Small software system related changes go through the fastlane channel from departments to engineering. Every department owns its own Kanban board managing its own changes and demand and there is one single organization wide Kanban board holding the initiatives (in SAFe called business and architectural epics).
Now, let’s see what the “unique owned” responsibilities of project leads and business analysts are. And just a word regarding “unique owned”. Our interpretation of owned is that this team of persons in the job position of X care to develop the responsibility in collaboration and communication with the rest of the organization that is involved in these activities. There is no “shut up – that’s the way to do it”. It is rather the way of “this is our recommended proposal for a standard method, technique, procedure or process. A common agreed and accepted standard proceeding will help us to be more effective and efficient. Let’s try to do it this way. In case we can improve it, based on our feedback, we will do so. Please give us feedback”. In the change process of our methodologies we established as well an experiment, inspect and adapt process. Luckily this is welcome and accepted by the majority of persons.
The core responsibilities of a business analyst are:
- Business analysts are the experts for our business processes – best in an end2end view. Together with the subject matter experts (we call them erp specialists, erp stands for our self-developed “enterprise resource planning” system) they take the responsibility to identify, develop and optimize the business processes.
- Business analysts help the departments to improve in alignment with other departments – as a business process typically crosses more than one department. They help the departments to develop ideas for improvements and mature these ideas into initiatives and fastlane issues.
- In the context of initiatives they support the development of the user stories in collaboration with software engineers, usability experts and with the users working with a new process or a new system. They act in the responsibility of a Scrum product owner for the Scrum teams. In this context they work very close with project leads on definition of goals for initiatives and the measures to reach these goals. This collaboration is part of the alignment between initiatives and product backlogs of the Scrum teams.
- Business analysts care for that changes flow back into the organization. They take the responsibility of end2end tests together with the departments, with engineering and with project leads. Business analysts are an essential part in quality assurance of our business processes and systems.
- Business analysts are responsible for the way we build up an appropriate documentation of our business processes (the business process management process J). We just decided to document our business processes with BPMN. As our systems, processes and the number of involved persons increased over the time (and still are increasing) we have the need for a lean, easy to understand, read and to maintain BPMN documentation. Documentation is worth another blog… J.
The core responsibilities of project leads are:
- The innovation process, i.e. the way departments work with their Kanban system developing ideas for initiatives and fastlane issues. Project leads support the departments as (innovation) process coach.
- The portfolio management process around initiatives including definition what an initiatives represents, how to manage and document an initiative within our supporting software systems like Atlassian Jira and Confluence.
- Project leads overall are responsible to drive the implementation of our strategy working with and developing our roadmap. They care for and remind that initiatives are developed, the breakdown of themes into initiatives, that decision are prepared and taken by the executive team. They ongoing develop the roadmap together with the executive team.
- Together with business analysts, project leads they care for lean goals of initiatives and the identification of measures to reach the goals of initiatives. We try to treat every single initiative as a MVP (minimal viable product) to reach the goals of the initiative. They care for that a review is done in the closure of an initiative against the goals. They care for that learnings flow back into the organization, whatever learning that may be.
- Project leads are responsible to collect the information and feedback from all participants in the demand – capacity game, so that the overall system is not overloaded and the system is balanced and healthy. This includes the preparation and proposals for prioritization of initiatives for the innovation board meetings.
And finally what is common to project leads and business analysts:
- The task of business analysis and requirements engineering is shared. All business analysts and project lead know our business processes very well. This sharing lead to some discussion until we found our common understanding (at least I believe by now we found an agreement as the discussions went down and we have a lot of coffee and fun together). In general business analysts may have a bit a more detailed functional knowledge and project leads care a bit more for the inter-department and roadmap-alignment side of business analysis. But for some initiatives a business analyst may be in the lead, fulfilling everything a project lead does; in some initiatives a project lead does nearly all of the business analysis. But this is OK and accepted.
- We both work with departments to develop new ideas for initiatives and fastlane issues. While projects leads take more the role of a (innovation) process coach and support the departments to life and adapt the process to the special needs of the department without leaving agreed common mechanisms like the two demand channels fastlane and initiative, business analyst support more on the business process side to develop and improve the business processes. But as well persons in both job positions are able to act vice versa.
- Many skills and experiences are shared in our teams. This is the lean and agile way of project management, business analysis, requirements engineering, acceptance testing, stakeholder management – many disciplines you may find in a project management, business analysis or requirements engineering book. We even share our training and education events and care for that we improve our skills on a common ground.
Reading these three bullet lists you may now ask yourself why we distinct the job positions project lead and business analyst. To be frank: This is a historical reason and the status quo is satisfying and currently works for us.
Other solutions to implement a working system are possible. For example Craig Larman and Bass Vode in their LeSS framework recommend to establish groups of competences, i.e. the testing group or the architecture group. These groups are not organizational groups, these are members of (organizational) teams that share a common competence. Jurgen Appelo comes up with a similar proposal he names guilds. A guild is a group of persons that share competences and skills and develop these competences and skills for the benefit of the organization.
We at Digitec Galaxus have a mixture. We have “guilds” for example the erp (= enterprise resource planning system) guild or the architecture guild. For business analysis and project leads we have teams as part of the organization. Both mechanisms have the goal to develop competences and skills. Potentially we could as well integrate project leads and business analysts into the other organizational units, but why should we. It would only be a re-organization.
As the current system is understood by everybody and there is currently no need for a change, we leave it as it is. Re-organizations are always something people are a bit afraid of, because personal threads and fears pop up with re-organizations. Maybe any time in the future we discover that this construct can be improved for some reasons. Well, then we will change it. Maybe any time in the future our organization is that flexible and transparent to every single employee that re-organization rather carries the attributes of new chances and interesting new responsibilities instead of threads and fears.