Naming and Framing Processes

Every organization generates its revenue and spends its money through processes.  That’s how they conduct their business.  Therefore it makes sense that if you want to increase your revenue or decrease your costs, the first things you should examine are your processes.  Try to improve them.  Try to make them more efficient.  The best companies out there are continuously looking for ways to do their jobs better.

Most processes are undocumented.  In order to examine and improve your processes you need to understand them.  Only when you understand them can you measure and analyze them and improve them.

The first questions you should answer about each of your processes are “What starts it?” and “When does it end?”.  By definition a Process is a “series of related actions, triggered by an event, creating a deliverable for a customer”.  Let’s examine all four of these ideas before proceeding.

“A series of related actions” – Processes involve activities and decisions done in a certain order.  You need to understand the detailed work involved to accomplish the goal.

“Triggered by an event” – Something starts every process.  They don’t just randomly start.  You need to know why a process begins. 

There are 3 basic types of events that can occur in business where the response is a process.  The first is the “decision”.  Someone decides to do something and the result is a process.  For example a Customer may decide to buy a product.  A Manager may decide to hire an employee.  An Employee may decide to quit, etc.

The second type of event is the “situation”.  This means that something happens and the result is a process.  For example, inventory drops below a threshold level, product arrives on your loading dock, you receive an email, etc.

The third type of event is the “temporal”.  This means that at a certain time, or date, or based on the passage of time, some work is performed.  It might be paying employees on payday, paying approved vendor invoices, getting the mail, counting inventory, etc.

“Creating a deliverable” – A process creates something!  It provides value.  You need to know what is created for every process you or your company execute.  If it doesn’t create anything of value, get rid of it.

“For a customer” – This doesn’t mean your end customer who buys your products.  It means that a process creates something that is used by someone or by another process.  If the output of your process is not used, why create it?

Before you get into the details of each of your processes you need to:

Name it!

Determine what starts it!

Determine what it creates!

Determine when it ends!

and not necessarily in that order.

An event is a state or condition that exists that you are going to respond with via a process.  It does not involve the passage of time.  Therefore all events should start with a NOUN!  A process does involve the passage of time and involves actions, therefore a process name should begin with a VERB.  Ideally it should be a Verb Noun pair.  A simple rule, but it makes the life of a Business Analyst so much easier.

Name your process! 
The verb should describe the work being done.  Someone should be able to read the name of the process and understand what it does.  The noun should be what the process creates or changes.  Examples are “Generate Payroll”, “Sell Product”, “Buy Product”, Hire Employee”, “Pay approved vendor invoices”, etc. 

Determine what starts it! 
Identify all the triggering events that can start your process.  There can be more than one!  Document the triggering events with the process.

Determine what it creates! 
When you determine what the process creates you essentially have determined its completion.  When that deliverable is created, the process ends.  This should be the noun in your process name.

Some Business Analysts make the mistake of thinking of the work in an organization as one process.  I’ve seen process models with hundreds of tasks and decisions, that take up entire walls and take months to complete.  They are so complicated they are completely useless, and besides, they’re wrong.  Follow the guidelines stated here and you will see how the work of an organization consists of many processes, each simple on its own.

Agile Methodologies

When people read my blogs and articles, or take my courses, some respond with "We don't need to do that. We're an agile shop.". When I hear that I immediately think, "Do you know what an agile methodology is?". Look up "agile" in the dictionary. All it means is "Quick to respond".


I am a proponent of agile methodologies for software development. The classic waterfall model, as taught in a number of Project Management courses, does not work and never has. It assumes you can complete every step in a project completely and never have to revisit it. Nonsense! That's not how we build stuff. We build as a series of iterations with each iteration building upon the last.


I remember a few Project Managers from my past trying to impose a waterfall methodology on a project, and it never worked. Caused nothing but problems and unhappy customers.


The problem is that many people, especially developers, believe that an agile methodology allows them to do whatever they want, get feedback from the client and then change it, over and over and over again, until it is what the client wants. Throw Project Management out the window. Talk about the long way to get to somewhere, rework after rework after rework.


Why then do some instructors continue to teach the waterfall method as if it's the only way to develop software? Because that's what they were taught and they can't get beyond that.

I continue to teach about the Requirements, Design, Development, Testing and Deployment Phases of a project, not because they need to be done in that order completely, but because they all require different skills, tools and techniques to accomplish and have different best practices. It's just a good way to divide up the material. Don't assume it means that you must do the 5 phases in order with no overlap. Just doesn't work.

What is Business Analysis?

According to the International Institute for Business Analysis (IIBA);
 

“Business analysis is the discipline of identifying business needs and determining solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement, organizational change or strategic planning and policy development. The person who carries out this task is called a Business Analyst or BA.”

 OK, now that we’ve got that taken care of, let’s talk about what it really is and why it’s needed.

Software has a dismal track record.  Most software projects finish well over budget and very late.  A company that budgets $200,000 for a software project may end up spending a million to actually get it.  Are you into the third year of your one year project?

We need to do better.

Prior to the 1990s programmers designed and wrote software pretty much by themselves.  Desktop computers were relatively new, very expensive and there was still much resistance from business.  Users didn’t understand the capabilities of computers.  Most software projects were initiated by IT.  Techies who understood computers had the vision and acted upon it.  But like an artist, they had no idea, nor did they care, about how much or how long it took to realize that vision.  Some really great, beautiful, elegant software was created, but it was art, and very expensive art at that.

Companies started to realize that the situation was not supportable.  You have to treat software development as a construction project.  There’s only so much that you can build for so much money in so much time.  We’ve been doing this with other things for centuries.  Buildings, bridges, roads, railways...

An examination of software projects that were well over budget or behind schedule showed that the number one reason for that was scrap and rework, meaning the programmer built something, showed it to the client, was told it was wrong and had to go and do it again.  The fastest and cheapest way to build anything is to build it once.  The only way that can happen is if the person building the product knows what the client wants in sufficient detail to build it.  That is the goal of a Business Analyst.

Every software product is based on someone’s vision.  When the client looks at a piece of software and says, “That’s not what I want.”, ”That’s not what I need.”, “That’s not what I asked for.”, it’s because it does not meet their expectations, in other words, it does not match their vision.  That’s because there were two different visions, the one the client had and the one the programmers had.  The programmers obviously built to their own vision.

The goal of Business Analysis is to make sure the product created meets the client expectations.  In order to do this the Business Analyst must capture the client vision, articulate it, document, validate it and communicate it to the development team.  In other words, to make sure that the product developed is according to the client vision.  There should only be one vision and it should come from the client.

Capturing that vision, articulating it, documenting it, validating it, communicating it and validating the product created, requires skills, tools and techniques that I will expand upon in subsequent entries.