3 posts tagged with "business analysis"

Functional programmers prefer data to calculations and prefer calculations to actions. Similar wisdom applies to project management: understanding stakeholders must precede planning, which must precede action.

The Genesis of a Stakeholder Mapping Tool​

While working on a recent UI Systems Design project, I found myself struggling with the stakeholder analysis phase. Identifying key players and their relative influence often became a complex, subjective exercise consisting of scattered notes and mental models. As a Business Analyst specializing in UI Systems Design, I'm always searching for tools that bridge the communication gap between business and development teams, especially in our remote work reality.

The inspiration struck from an unexpected source: the host attribute management system from HBO's Westworld series. In the show, character designers adjust personality sliders across various categories to shape host behavior. I immediately saw the parallel - what if we could visualize stakeholder attributes with the same clarity?

Adapting the Westworld Matrix for Stakeholder Analysis​

The Westworld attribute matrix provides an elegantly visual way to adjust and understand relationships between different personality traits. For our stakeholder mapping tool, I adapted this concept to focus on two critical dimensions: power and interest. This classic framework helps categorize stakeholders into four actionable quadrants:

1. High Power, High Interest - Manage Closely
2. High Power, Low Interest - Keep Satisfied
3. Low Power, High Interest - Keep Informed
4. Low Power, Low Interest - Monitor

But I didn't stop there. The tool needed to visualize relationships between stakeholders and provide meaningful insights. Working collaboratively with developers, we designed an interactive application that transforms abstract stakeholder data into tangible visualizations.

Coding for Clarity​

Similar to my approach with Robustness Diagrams, I wanted the code structure to reflect clear, logical thinking. Taking inspiration from functional programming principles I'd learned from "Grokking Simplicity," we developed a modular architecture separating:

• Data (stakeholder information)
• Calculations (analysis of stakeholder relationships)
• Actions (UI events and visualizations)

The modular approach allows developers to easily understand, maintain, and extend the code base. By classifying code into these three categories, we created a system that's both robust and flexible.

// Example of how we separate concerns in the stakeholder tool
const StakeholderApp = {
    // Data model
    data: {
        stakeholders: [],
        relationships: []
    },
    
    // UI Module (Actions)
    UI: {
        updateStakeholdersList() { /* ... */ }
    },
    
    // Visualization Module (Calculations)
    Visualizations: {
        renderPowerInterestMatrix() { /* ... */ }
    }
};

Beyond Static Mapping​

The current implementation is just the beginning. The next evolution of this tool will track stakeholder satisfaction throughout the project lifecycle. By recording and visualizing satisfaction levels at different project milestones, teams can:

1. Identify trends in stakeholder sentiment
2. Proactively address declining satisfaction
3. Celebrate improvements in stakeholder engagement
4. Document the journey for retrospective analysis

This longitudinal view transforms stakeholder mapping from a one-time exercise into an ongoing dialogue. Much like how the hosts in Westworld evolve through their experiences, our understanding of stakeholders should develop throughout the project.

Why Stakeholder Mapping Matters​

In today's complex business environment, successful projects depend on more than technical expertise. Stakeholder dynamics often determine outcomes more than any other factor. A well-executed stakeholder mapping process:

• Prevents unexpected resistance by identifying influential players early
• Optimizes communication strategies for different stakeholder groups
• Prioritizes efforts based on stakeholder power and interest
• Creates a shared understanding among team members

As I experienced on my recent Enterprise Application project, light-weight workshops using these visualization techniques dramatically improved team alignment and expectations. The diagrams served as both documentation and communication tools, much like my adapted Robustness Diagrams.

Try It Yourself​

I've made both the tool (Alpha Release) and its source code available to the community:

• Live Demo: Stakeholder Mapping Tool
• Source Code: GitHub Repository

Feel free to use this tool for your own projects, and contributions are always welcome. The repository includes detailed documentation on how to set up and modify the application to suit your specific needs.

Moving Forward​

As we continue refining this tool, I'm excited to see how it evolves to meet the needs of different project teams. The core principles remain the same: visualize complexity, document relationships, and use technology to enhance human understanding.

Whether you're managing a small product team or coordinating a large enterprise initiative, stakeholder mapping provides the foundation for strategic engagement. And with interactive tools like this one, the process becomes not just more effective, but more insightful as well.

Like the hosts in Westworld, our tools should adapt and learn as we use them. This stakeholder mapping tool represents just one step in that journey – from static documentation to dynamic insight.

Working as a technical consultant across various organizations, I've observed patterns in how companies scale and specialize their roles. These patterns remarkably mirror concepts from evolutionary biology and systems theory, which I discovered while researching organizational design methodologies.

Breaking Down Organizational Evolution​

Just as we can break down software into Actions, Calculations, and Data, we can classify organizational evolution into three key aspects:

1. Structural Evolution
2. Functional Specialization
3. System Integration

Let me share how I've adapted these concepts in practice.

The Single-Function Phase​

In early-stage organizations, like in primitive organisms, we see a pattern I call the "single-function phase." Here's what it looks like in practice:

Early-Stage Organization
├── Generalist Roles
│   ├── Sales/Marketing
│   ├── Product Development
│   └── Operations
└── No Clear Specialization

During this phase, team members handle multiple functions, similar to how single-celled organisms perform all life functions within one cell.

Specialization Patterns​

Through my work with scaling companies, I've observed that specialization typically follows this pattern:

Specialized Organization
├── Core Functions
│   ├── Sales
│   │   ├── Field Sales
│   │   └── Inside Sales
│   ├── Engineering
│   │   ├── Frontend
│   │   └── Backend
│   └── Operations
│       ├── Customer Success
│       └── Support
└── Specialized Units

This structure emerges naturally when:

• Team size exceeds 25 members
• Product complexity increases
• Customer needs diversify

View the code examples and diagrams on my GitHub: github.com/izzi-ink/scaling

Example: BA Role Evolution​

Let me illustrate this with a real-world example from my experience as a Business Analyst. Here's how the BA role typically evolves:

Initial State:

BA Role (Generalist)
├── Requirements Gathering
├── Process Modeling
├── UI Design
└── Testing

Evolved State:

Specialized BA Roles
├── Technical BA
│   ├── System Requirements
│   └── Technical Documentation
├── Process BA
│   ├── Business Process Analysis
│   └── Stakeholder Management
└── UI/UX BA
    ├── Interface Design
    └── User Research

Systems Integration​

The challenge isn't just in creating specialized roles but in maintaining effective integration. I've found this template useful for documenting role interactions:

Cross-Functional Process
├── Input
│   ├── Source Role
│   └── Data/Requirements
├── Process
│   ├── Primary Role
│   └── Supporting Roles
└── Output
    ├── Deliverable
    └── Stakeholders

Practical Application​

Here's a simple checklist I use when advising organizations on role specialization:

1. Monitor these triggers:

   • Team size exceeding capacity
   • Quality issues
   • Delivery delays
   • Communication overhead

2. Document current state:

   • Role responsibilities
   • Process flows
   • Communication patterns

3. Plan transition:

   • Identify specialization needs
   • Define new roles
   • Create integration points

Learning From Nature​

The fascinating part about this approach is how it mirrors natural evolution. Consider these parallels:

Biological Evolution      |  Organizational Evolution
-------------------------|-------------------------
Single-cell organism     |  Startup (generalist roles)
Cell specialization      |  Role specialization
Organ systems            |  Departments/Teams
Nervous system          |  Communication channels

Implementation Notes​

When implementing this approach, I've found these principles crucial:

1. Start with clear documentation of current processes
2. Identify natural breaking points for specialization
3. Maintain strong integration mechanisms
4. Monitor system health through regular feedback

Interactive Visualization Tool​

I've developed an interactive visualization tool that brings these organizational evolution concepts to life. This tool allows you to:

• Explore the progression from startup to enterprise across all three dimensions
• Adjust organizational attributes and see their impact in real-time
• Receive automated analysis of potential growing pains and integration challenges
• Compare different organizational configurations side-by-side

This visualization can help leadership teams identify where their organization currently sits in its evolutionary journey and anticipate the changes needed for healthy scaling.

Try the live Organizational Evolution Matrix!

Credits and Further Reading​

This approach draws from several key sources:

• Systems Theory in Organizational Design
• Evolutionary Biology Principles
• Modern Organizational Design Frameworks

Tags​

#organizational-design #systems-thinking #role-specialization #business-analysis #evolution

Note: This post reflects my personal experience and adaptation of these concepts. Your mileage may vary based on your organizational context.

Functional programmers prefer data to calculations and prefer calculations to actions.

Grokking Simplicity is the title of a wonderful book, published in 2021, to teach an approach to software development, specifically functional programming. I discovered the book while attending Chris Ferdinandi's Vanilla JS Academy, and soon found myself moving away from my Java trained OOP approach and learning to think like a functional programmer. This book teaches an approach to problem decomposition, and introduced me to classify code and problems into:

• Actions
• Calculations and
• Data

Adapting what I learnt​

Because I am a Business Analyst, who specialise in UI Systems Design, I am tasked with documenting wire-frames from low-fidelity to high-fidelity, and naturally I use UML diagrams to document my system design and requirements. But remote work can make it difficult to collaborate with developers therefore I am always looking for ways to improve the communication between the business and the development team.

The more I used the Grokking Simplicity methodology, and tasked with doing both the technical and UI design, on a particular project, I chose to use Robustness Diagrams to communicate these designs. Robustness Diagrams are a type of visual modeling technique, normally used in software engineering and system analysis to 'analyze and design the structural and behavioral aspects of a system'. They are primarily used within the context of the ICONIX process, a streamlined, use case-driven software development methodology.

I adapted hacked Robustness Diagram notation by extending the symbol for the controller object to represent either calculations or events (actions). I appended the controller symbol with the letter ‘e’ for event and ‘f’ to depict make a function. The letter 'l' is used to extend the symbol used for a boundary object, or user interface. This indicates that an event listener is coupled to a particular UI component, in our example below, a checkbox.

Example​

I chose a very simple function that toggles the visibility of a password field, as example to illustrate how this notation can be used to document a UI design.

User Story​

As a user, I want to be able to toggle the visibility of my password so that I can see what I am typing.

Wire-frame​

Robustness Diagram​

It’s a relatively simple diagram and once the engineers can read and interpret it, it serves a dual purpose such that it teaches sound programming principles as well as clear specifications.

More experienced developers and architects should be able to document and adopt this notation and generate designs that originate from UI mocks.

I have used this notation to document the entire system design of a fairly complex Enterprise Application. This was done through light-weight workshops with the development team, and the diagrams were used to document the design and requirements and design together.

It is important to note, that one typically would not document UIs at this level of detail in a Robustness Diagrams, but I found it to be a very effective way to communicate the design and requirements to the development team.

Code​

//
// Variables
//

// Get the password toggle
const toggle = document.querySelector('#show-password');

// Get the password field
const password = document.querySelector('#password');


//
// Functions
//

/**
 * Toggle the visibility of a password field
 * based on a checkbox's current state
 * 
 * @param {HTMLInputElement} checkbox The checkbox
 * @param {HTMLInputElement} field The password field
 */
function togglePassword (checkbox, field) {
  field.type = checkbox.checked ? 'text' : 'password';
}

/**
 * Handle change events
 */
function handleChange () {
  togglePassword(this, password);
}


//
// Inits & Event Listeners
//

// Handle change events
toggle.addEventListener('change', handleChange);

View the code in action on Code Pen

Credits​

• Grokking Simplicity
• Robustness Diagram
• Vanilla JS Academy
• Kieran Barker
• Chris Ferdinandi