Skip to main content

Tag: BPM

Strategy Spotlight: Breaking Down 4 Process Levels in Your Organization

Everything that happens in your organization and cuts across the levels of organization can be divided into ‘big buckets’ of things that the business does.

Chances are, you have some people in charge of those buckets. Often we see human resources, financial, information technology, and manufacturing processes being part of the list. But what if your organization has other things going on? You might have a whole research and development department that has processes that cut across the organization. If you missed these in the high-level identification of business processes, you might create a negative impact for the company by not representing all the true processes that exist.

There is an impact to understanding that all organizations can be broken down into at least a four-level process model like the maturity model discussed in an earlier blog (5 Business Processes to Your Evolutionary Success). However, there are other process level models that look at the business slightly differently.

Tari Kaupapa from the project office of Massey University outlined a Four Level Process in his paper on “Process Mapping; Process & Guide.” He used the following guidelines to understand and identify the different processes in the business organization:

Level One: is the standard high level and lists the operational levels of an organization.
Level Two: depicts the end-to-end processes across the operational areas.
Level Three: shows the roles and associated steps required to complete a specific process within an operational area.
Level Four: is the documentation of instructions and procedures required to complete steps in the level three processes.

Within this model, everything must link and connect. Failing to do so could have bottom line impacts, due to cost changes and productivity mishaps. It’s also important to know exactly which level of the organization we are dealing with and when. The candid discussion happens when you review your business process maturity levels at the same time as determining what process level from Kaupapa’s model you are at. The best bet is to pick your processes and then figure out with your team what process levels you’re at, which buckets they belong in, how they link together and where improvements need to be made.

Level 2 and 3 are the tactical levels in this model. You’ll need this level information, both for strategic conversation and also to bridge the gap between the strategic and the operational. Whatever happens, level 2 and 3 in your business should be categorized and be part of the level one items–those big buckets that have an impact on the entire organization.

Level 4 thinking is in the weeds and is not for the business leader. Still, it is often customer-facing and is, therefore, important for you to know and understand, especially around how it impacts to your business. Awareness is what is important here.

Every process in your business belongs somewhere. Whether it is about finding Kaizen opportunities (7 Wastes in Your Business), applying a business maturity model (5 Business Processes to Your Evolutionary Success) or evaluating your process levels. Often it comes down to how efficient and effective your business is within the common constraints of time, money and resources, and the need to cut costs while improving productivity.

Strategy Spotlight: 5 Business Process Maturity Levels for Your Evolutionary Success

Every organization, be it a group of people, a community, a military unit, a government body, a manufacturing company or service company, is at a different level of maturity when it comes to process and productivity.

There are maturity process levels that exist in every business, just as there is a need to be lean. It’s all part of the natural business evolution. Every business and department evolves along certain maturity levels either organically or intentionally. It’s also common to become stuck in one place along the maturity continuum.

To begin the strategic planning around process and productivity, your team will need to assess your business’s level of maturity. Consider these five evolution maturity levels:

  1. Chaotic: no real structure – everything is at the 11th hour
  2. Reactive: all last minute – plan is open – when the leadership says jump, the team says how high
  3. Proactive: repeatable processes in place – managing efficiency, but not business needs
  4. Service: semi-integrated processes – able to measure business economics
  5. Value: connected processes – measured and shared

Related Article: 5 Really Good Reasons to Map Business Processes

What is your business maturity level, not only for the organization as a whole, but also its various departments? What are all your business processes? In what way does your maturity process level(s) impact your business productivity? What level of maturity do you want to be at (or need to be at)? By when can you achieve that maturity level?

These questions will help you determine your present business process maturity level(s) and your future desired maturity state. They create dialogue among your people on what improvements need to be made and the commitment it will take to make them happen. Once you’ve thoroughly explored these questions, add into the conversation the need to be a lean business environment, one where value for the end customer is considered and you now have a recipe to recreate your business process and production best practice.

Five Really Good Reasons to Map Business Processes

Process Mapping is a group activity performed by teams of subject matter experts that gather to draw step-by-step diagrams to document how work is processed (see Figure 1).  This invaluable tool is mostly used by consultants and business professionals to capture the current state of business operations in preparation for business improvement initiatives.

 However, process mapping can also be very beneficial in helping to increase productivity among staff, implementing or decommissioning systems, streamlining processes, and protecting knowledge capital.    Let’s take a look at how process mapping is used in business improvement initiatives as well as how it can be used to help in other areas of a business. 

gaillardsept 

Figure 1 – Cross-functional Process Map Example

1.Launch Business Improvement Initiatives

The strategic plans and goals of a company often drive the need for change.  But before making changes it is prudent to establish a baseline from which to make improvements.  Taking the time to understand how a process is currently working allows you to:

  • Leverage best practices from existing processes
  • Capture lessons learned – learn what not to repeat
  • Measure the effectiveness of improvements
  • Ensure that you are fixing not shifting or creating problems
  • Optimize existing processes rather than creating new processes from scratch

Look at process maps as an investigative tool helping you to understand the root causes of problems.   It also supports the transparency needed to learn about how work is completed and encourages team innovation from an “all-in” stakeholder perspective for improving processes.  If you take the time to understand what is and what is not working, you will be less likely to repeat mistakes of old.  

Related Article: How to Facilitate Successful Process Mapping Sessions

2.Increase Staff Productivity

Process mapping can help organizations eliminate confusion and chaos among staff helping to increase productivity.  A properly trained staff that operates like a well-oiled machine increases the type of productivity that leads to profits.  However, in many organizations poor processes and a lack of training and communication leads to chaos that produces poor performance and low employee morale.  

Process mapping requires a “parley” of sorts that brings all interested parties to the table to hash out how work is done.  At the table stakeholders are identified, roles and responsibilities of each group are clarified, and sequential steps of the process are documented and then ultimately negotiated to optimize work processes.  

Process maps can also be used as training aids for employees and easily converted into standard operating procedures that describe step-by-step details on how to perform each task identified.  

3.Implement New or Decommission Old Systems

Technology changes as frequently as our need for it.  Staying competitive requires that we use the latest technology to maintain a competitive advantage and carry out the strategic goals of the company.  This frequent change requires a constant need to assess the systems being used in production and to perform administrative duties.  System updates, installations, and the decommissioning of systems can be very costly if impacts to  groups and processes are not considered.  Implementing a new system without first identifying all user groups and how they use it may fail to meet the needs of the business.  Decommissioning systems prematurely can leave user groups without a way to process or produce data that could cause operations to come to a grinding halt.  

Detailed process maps can provide a deep and wide understanding of how businesses us their systems.  As processes are described, and systems identified you are inadvertently collecting an inventory of all systems used, as well as learning about who uses them and how they are used.  This information provides IT with the pertinent information necessary to meet the technology needs of a business.    

4.Quickly Streamline Business Processes

You can also use process mapping to identify “pain points” experienced throughout a business process. Tagging steps in a process about the problems that occur can help you focus on specific areas for improvement.  

“Lean” tools can be applied when analyzing maps to seek ways to streamline the process.  Lean is a business methodology that involves using a set of tools that assists in the identification and steady elimination of waste in processes.  Manual processes, redundant work, bottlenecks, and rework are just a few activities that can be classified as waste.  Process maps make it easy to identify these activities because each step in the process is documented clearly with notes and symbols of how the process is being performed.  Consideration for elimination should be given to steps that are considered waste and do not add value to the development or production of the end product   

5.Protect Knowledge Capital

Knowledge capital is an intangible asset but is just as valuable as the physical assets of a company.  The definition of knowledge capital is the skill set shared by employees on how to perform tasks or steps necessary for the support of production.  Often the details of how tasks are performed between and within groups are not documented.  Losing this vital information due to turnover or other absences could lead to work stoppages, slow production, or lead to chaos damaging the effectiveness of operations.    

Process maps capture all the vital information necessary to keep operations functional.  Functional areas, roles, responsibilities, systems and inputs and outputs of a process are documented providing clarity on how the critical processes to the operations of a business occur.  The process maps also serve as a communication tool educating staff from a 360-degree view of how things work increasing the value of the knowledge capital thus providing a competitive advantage.   In the absence of critical staff, these process maps are available to backup staff to keep operations running smoothly.

Process mapping has many effective uses, but they are most effective when used as living documents that can be reviewed and updated regularly to monitor and improve business operations.  Best practice is to learn the universal standards on how to develop process maps, document critical core and supportive processes that keep the business operational, and establish a “continuous improvement” team that can meet quarterly to continually improve processes.  This will ensure that your business is optimized at every possible level.  Happy mapping!

BA-elzebub’s Glossary – The D’s

Be sure to chip in some D’s of your own, and a few E’s for next time!

D’Oh!:  The perfect attitude to take around any requirement error.  Makes it easier to fix, especially when the BA takes it for the team.

The next three items were inspired by Ronald 2015-05-19 18:35

Data:  The facts collected in the current system – usually the root cause of the need to replace the current system.  

Data, Also:  The opinion of the sponsor about the facts and how they should be discussed by the BAs, regardless of the facts.  

Data, Choose Yours Wisely:  Grasshopper.

Data Dictionary:  One aspiration of certain social climbing Thesauri.  

Thanks to Rich Larson of the BA Times 2015-05-19 15:57

Data Model:  An activity that most BAs would prefer to the information designs they actually do.  Not all BAs – you know who you are.

Data Base:  Piccolo’s Prom dream?

DARPA:  Defense Advanced Research Projects Agency recently known for Driver Accident Reduction Pending Automation.

Inspired by Joe 2015-05-19 14:40

Deadline:  A term of little meaning or consequence.  A date picked with hope, in case hope really matters.

Thanks to to Rich Larson of the BA Times 2015-05-19 15:57

Decision:  A behavior performed too fast or too slow by somebody not yourself.

Thanks to Rich Larson of the BA Times 2015-05-19 15:57

Diagram:  What we turn to when words fail us.  Do not confuse with ViagraMan.  Not funny, unless you do it instead of me.

Decision Tree:  Analytical technique complicated enough that the sponsor might get away with the weights selected for the branches, without anyone actually checking them.

Defect:  Error NOT of design, BUT of execution, as in “That defect killed the wrong person.”

Delay:  A period of time required to complete a project, regardless of the deadline. 

Delete, CTRL-ALT:  Also know as the “three finger salute”, it is a chance for your PC to die with its re-boots on.

Delete, Create, Read, Update: Analysis technique not also known as DCRU.

Delirium:  See deadline.

Deliverable: An object substituted for results.

Deming, Edward:  Guru of quality, singlehandedly responsible for YOUR preference (yes, you do) for Japanese cars.  Famous saying:  “Defects are not free.  Someone makes them, and gets paid for making them.”

Devil’s Dictionary:  A far better read than BA-elzebub’s poor efforts, by a delightful writer named Ambrose Bierce.  Get a copy if you can.

Dirty Write:  A form of preserving data integrity equivalent to “What the heck” (see Heck in this edition of the Glossary).

Disaster Recovery Plan:  NOT “Don’t let the door hit you on the way out…”

With more thanks to Ronald 2015-05-19 18:35

Discovery:  The phase when the project team works out which requirements weren’t.

Disinclination:  One of many common reactions to working with requirements as in “It’s too much trouble to climb this inclination of mine.”

Disk Drive:  Trip taken when the operations manager realizes that the only good backup is on her personal computer at home.

Disk, Floppy:  A condition associated with OLD disks.Diskette:  A cure for floppy disks.

Distracted Driving:  Human driving.

Distributed Computing:  A form of missed requirement, as in “I thought they were doing that over there on the other system.”

Domain, Business:  The primary activities of the business, as in “Spying on do customers is do main business of FaceNet.”

Domain, Subject Matter Expert(s):  Do main person(s) whose best thinking is responsible for the current state.  Also known as “do box” one must “get out of”.

With thanks to steve 2015-06-25 06:45

Dormant:  State of requirements or expectations that sleep soundly during elicitation and suddenly wake up hungry for BA-er meat during acceptance testing or thereafter

DoS:  Denial of Stakeholder, as in “You can’t talk to THEM.”  

Dragon:  Adjective describing most meetings, not to be confused with:

Dragoon:  The goon causing the meeting dragon.

Drive, Shared:  Good luck, I’m sure its out there somewhere.

Duct Tape (aka Duck Tape):  One of the big two cures in engineering.  Unfortunately, it is completely completely useless in software engineering.  You know, “If it’s stuck, spray it with WD-40, if it’s loose…”

With more thanks to Steve 2015-06-25 06:45

Dundant: The first time something occurs.  For all the rest of the times, see redundant (and Einstein’s definition of insanity). Redundant things are superfluous, while dundant things are merely fluous.

Duplication of Effort:  A real “boy” story, used by IT to avoid extra stress (hey, give them more budget and employees before you complain too much).  Example from boy:  “Why do I have to pick up my room?  It will just get cluttered again!”  Example from IT boys:  “You shouldn’t implement that software – we will just have to replace it when we fix everything!”

Dubious Philosophy:  I once read that it was Socrates who said “To be is to do”, and Plato who said “To do is to be”, but we had to wait for Sinatra to say “do be do be do”.

Dumb Ideas:  There are none – leave your comments and thoughts below 🙂

The Business Analyst’s Accountability in Scope Creep and Changing Requirements

In my classes and consulting work I get the same complaints when I ask teams about the biggest roadblocks in requirements work: 

  • “My stakeholders keep adding features.”
  • “My stakeholders keep changing the requirements.”
  • “My stakeholders don’t know what they want.”

BAs, PMs, and even developers point frustrated fingers at stakeholders who constantly add or change requirements, priorities, features, and needs. They quickly cast blame on stakeholders who don’t really know what they want and can’t define and protect the boundaries of the project: the impulsive sponsor, assuming business manager, the indecisive subject matter expert, the ambiguous architect or the distracted CIO.

Who’s the worst offender? Who’s the biggest scope creep on your projects? Well, I am sad to say, it might be you!

No matter if you work on traditional or Agile projects, your role is to facilitate the discovery of requirements, with an approach that assumes your stakeholders do not know what they want or need. Your role is to help them figure that out. Scope creep and requirements changes often come from a lack of discovery and analysis of the originally stated requirements.

If your role includes requirements elicitation and requirements management, you may need to step back and take a long, hard look at your mindset when working with stakeholders. If your stakeholders seem confused, frustrated, indecisive, bored, unavailable, demanding, then you might be the root cause of the scope creep problem!

Do you expect your stakeholders to know their requirements? Do you expect them to know all the details, data, rules, processes, people, and systems impacted? Do you expect them to tell you all of this in an organized manner? Stakeholders have ideas visions, pain points, and needs. It is up to us as BAs to help them express and discover how it all comes together as part of a solution.

BAs and PMs often blame stakeholders for constant changes in scope and requirements when the true fault often lies in the quality of the requirements processes, tasks, and techniques. The quality of how well we elicit and draw out the very details and requirements, the quality of the dialogue and analysis we stimulate in stakeholders, the team, and ourselves later becomes scope creep and change if we do not draw out the requirements that creep up on us later.

In Agile projects, we elicit requirements based on value management principles and priorities rather than scope management. Value management principles are similar in that we need to constantly facilitate what features add the most value to the organization and prioritize the backlog accordingly. Scope management, when done well, also facilitates value management by ensuring we have analyzed and elicited requirements of the most value to the organization. These are often assumed and unstated requirements of our stakeholders.

We need to change our perspective and approach requirements differently. We need to approach requirements as a learning and discovery process. We need to help our teams uncover, discover and model scope. We need to develop and maintain our team’s shared understanding of scope, vision, and priorities throughout the project.

I see two types of scope creep and requirements change:

  1. Something external or internal to the project changes and it impacts the scope and requirements of the project and/or solution
  2. Requirements and scope are discovered as stakeholders and project team members evolve their thoughts and work together to uncover the details and impacts of the solution.

The first one is common to all projects, regardless if they are agile or traditional and we need to be ready for changes. The second type is where we can influence things dramatically as BAs.

How can you do your part to prevent scope creep and create shared understanding?

1. Check in with yourself on mindset: Are you approaching the requirements process expecting your stakeholders to tell you what they want? Or are you approaching it with a mindset that you are a facilitator of discovery? Don’t gather, elicit. There are always exceptions, but most scope creep and requirement changes are due to a “gathering” mentality instead of an “elicitation” mentality.

When a BA “gathers” requirements it implies a passive approach where stakeholders spoon-feed requirements to the BA. This passive approach, which does not include any analysis, leads to many missed requirements and fluctuations in scope.

When we “elicit” requirements, we iteratively extract and analyze stakeholder knowledge. We use probing and high impact questions and interactive elicitation techniques to help stakeholders discover and explore requirements. We use facilitation skills that promote meaningful dialogue and inspire active collaboration. Strategic elicitation minimizes scope creep by helping teams uncover assumptions, risks, and constraints.

2. Customize Your Approach. Do not assume you can use the same techniques for every project! This assumption will eventually lead to scope creep, erratic requirements, rework, defects and failed projects. Instead, be thoughtful in planning the requirements approach for your project. Every project is different. Every stakeholder group is different. Plan your approach based on what you know at the beginning of the project and refine the approach as you go.

Use powerful techniques to engage stakeholders and get them talking about the solution in ways that bring out more impacts, angles, and details. Techniques like collaborative games, prototyping, creative facilitation, and bringing analysis frameworks into facilitated sessions to bring out engaging dialogue.

Use techniques that create a framework for dialog that help stakeholders fill in the pieces that they would not have known to tell you. Techniques like Process Modeling, SIPOC, Business Model Canvas, Business Rules analysis, User Story Mapping, to name a few.

3. Focus on the Why and the Value. One of the best ways to start your scope management process is to help your team define WHY:

  • What problem is your team trying to solve?
  • What need are you trying to fulfill?
  • • What opportunity are you trying to exploit?
  • • Why are the stated requirements important to the stakeholder?

Once you create a shared understanding of why, then maintain it and use it to focus your stakeholders when defining the value the requirements bring.

4. Find the Gaps. There are always gaps! Why? Well, it’s the nature of project work. You just can’t know everything at the beginning—so keep your eyes open and help your team find the gaps. As a project evolves, gaps appear in many shapes and sizes, so challenge your team to find/uncover/unearth all: stakeholders, dependencies, constraints, assumptions, systems, processes, end users, personas, etc.

Warning: Don’t expect to locate all gaps in one big brainstorming effort at the beginning of the project. We need to approach requirements as a learning and discovery process. The discovery is iterative—it evolves over time. Be sure to systematically analyze, integrate and share each new piece that lands in the puzzle.

5. Draw Pictures. Visual models are often the best way to get conversations started and highlight gaps in shared understanding. Pictures prevent scope creep and missed requirements by providing context for discussions. They illuminate gaps and assumptions in ways that words/text can’t. Pictures also improve engagement and interaction by moving multitasking eyes away from other distractions and devices.

You can create pictures by gathering information from stakeholders one-on-one before a large group session or you can use facilitation techniques that help stakeholder groups create pictures for you. Just present a basic model or informal drawing and let the stakeholders react and learn and then update the model collaboratively.

6. Let people think. You can’t expect to hammer out solid, complete, stable requirements in a single session. Even if the session is a full day or a full week, you will miss requirements and/or you will miscalculate user needs if you do not give yourself and others time to step away and think.

Your team will make better decisions and will be able to more clearly define what they want if they get time to reflect in between elicitation sessions. They will be able to share information with their team, bounce ideas off others, and evaluate ideas in the context of their daily work, rather than being sequestered in a marathon, one-and-done workshop.

This iterative elicit and analyze approach also gives BAs the time they need to evaluate stakeholder input and refine the requirements approach as the project evolves:

Angela August 1

7. Expect Change. Here’s the bad news…change happens! Even teams with awesome collaboration, expertise and shared understanding will experience changes in requirements and scope. So, plan for it! Change will be less disruptive if it’s an expected and accepted part of your approach.
BAs need to accept at least partial responsibility for scope creep and requirement changes. The quality of a BA’s elicitation, facilitation, modelling and analysis skills has a significant impact on the project. BAs who strategically engage stakeholders to create meaningful collaboration and shared understanding will experience significantly less scope creep, requirements changes, defects and rework.