A Skill Ladder for Analysts · Business Analysis Notes

Key ideas#

The analyst profile as a traffic light#

Pererva and Ivanova picture an analyst’s profile as nested layers, from the center outward:

Personal skills (“red light”): without them you cannot succeed in the profession at all.
Professional skills (“yellow light”): what you gain by investing in yourself through books, courses and theory.
Special skills (“green light”, the color of money): what you gain only through practice and trial and error. These are what make you valuable on the job market.

At senior levels, management and leadership skills are added. The authors stress that growth is not just about adding more; each layer also becomes deeper. They also say plainly that the scale is a convention, not an industry standard.

Four levels#

Level	Professional knowledge (examples)	Special skills (examples)
Junior analyst	Overview of software development methods; basics of RUP’s requirements discipline; UML use case and domain models; basic object-oriented design	Identifying stakeholders and managing expectations; running meetings, interviews, surveys and brainstorming; setting system boundaries; classifying requirements by type; modeling behavior with use cases; tracing requirements; understanding testing; reading technical English
Analyst	GOST 34 and GOST 19 series standards; process notations such as IDEF0 and eEPC; sequence and robustness diagrams; analysis models; an introduction to agile methods	Writing a requirements management plan; knowing which model to use when; reading program code; presenting
Senior / lead analyst	Full project and product lifecycles; Boehm’s spiral model; project management standards (PMBOK); requirements engineering across the product lifecycle	Logical and data models; writing simple code; professional presentations; retrospectives on development practice; mentoring juniors; resolving project conflicts; identifying and managing risks
Head of analysis	Process maturity models (CMMI process areas such as requirements development, requirements management, verification and validation); assessing the department against them; designing the company’s own analysis method	Training and seminars; managing projects or programs; building the analyst team; improving processes; writing procedures; setting the function’s strategy; engaging top management; staff development and appraisal; running the knowledge base and quality system

On writing code, the authors’ argument is that a developer understands another developer best: if you want to speak their language, you need some programming experience.

Two exits from the ladder#

The model shows two common turns off the analyst path: at the “analyst” level, toward architecture; at the “lead analyst” level, toward project management.

Other ways to look at growth#

By background. Wiegers and Beatty classify analysts by where they come from: former users, former developers or testers, project managers, subject-matter experts and new graduates. Each brings typical strengths and blind spots. Pererva and Ivanova’s ladder is a different axis: not where you came from, but how far you have grown.
By scope and authority. The BCS book describes a business analysis maturity model with three levels: system improvement (requirements for one IT system, limited to a project), process improvement (working across functions on business processes) and business improvement (working with senior management on the business as a whole).
By clarity of the assignment. The BCS book also uses a two-by-two grid: how clear the goal is (“what”) and how clear the method is (“how”). Clear goal and clear method suit a beginner. Unclear goal and unclear method, such as “we need to cut costs”, need an experienced analyst with consulting skills.
By industry framework. The BCS book refers to SFIA (Skills Framework for the Information Age), where the business analysis skill is defined at levels 3 to 6, from contributing to recommendations up to full responsibility for analysis in a significant part of the organization.

How to apply it#

Place yourself. For the level you think you are at, tick the skills you can show evidence for. Then do the same for the next level.
Find the binding gap. Pick one special skill from the next level that your current project lets you practice.
Balance the layers. If you keep reading but rarely practice, you are building yellow-light skills only. Ask for work that builds green-light skills.
Combine the axes. A lead analyst on a single system (BCS system improvement level) has a different next step from one already working across processes.
Update the tool lists. The specific methods named (RUP, IDEF0, eEPC, CMMI) reflect the book’s era and context; substitute what your organization actually uses.

Example#

An analyst at The Workshop, a fictional chain of 12 bike-repair workshops, has run interviews and written use cases for the booking tool. On the ladder they are solidly “junior” and partly “analyst”. Next step: write a short requirements management plan for the outside development team and lead the sprint demo presentations. On the BCS scale they are at system improvement; redesigning parts ordering across all 12 workshops would move them toward process improvement.

Pitfalls#

Treating the ladder as a standard. The authors call it a convention. Use it as a prompt, not a promotion checklist.
Climbing on knowledge alone. Certificates and reading build professional skills; employers pay for practiced special skills.
Skipping personal skills. No amount of modeling skill compensates for poor listening or unreliability.

Sources and further reading#

A. Pererva, V. Ivanova. The Analyst’s Path: A Practical Guide (in Russian). Ch. 2, section 2.1 (analyst profile and qualification table).
D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010. Ch. 1 (business analysis maturity model); ch. 2 (skills analysis matrix, SFIA).
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Ch. 4 (paths into business analysis).