Skip to main content

Tag: BPM

7 Steps to Kick-Start Your Strategic Planning Process

lannon Jan28Strategic planning is an exercise in gathering and documenting information about the past, present and future of your business. Strategic planning helps determine where you want to go over the next few years, how you are going to get there and how to recognize when you’ve arrived.

One of the more common strategic planning approaches is Basic Strategic Planning (BSP). BSP uses a triangle approach and seeks to align strategic agenda items with the tactical reality of the organization.

Starting from the top, BSP includes the following steps:

  1. Identify your mission statement. It is amazing how many organizations don’t take the time to develop this statement. A mission statement is foundational to all strategic planning work. An effective mission statement describes what the company does, provides insight into client value and captures the essence of your company.
  2. Create a vision of the future. A vision statement should look to the future. After all, you can’t get to where you want to go unless you know where you want to go. Think ahead to three to five years from now and write your story. What is it that your organization has achieved? Tighten that story into a clear crisp sentence and share it.
  3. Develop core values and guiding principles. Core values and guiding principles are foundational to your entire organization. Guiding principles are a set of accepted guidelines formed by the business that capture how your people act, work, make decisions, set priorities and conduct themselves. It is imperative to set and communicate core values and principles or else they will set themselves over time through employee habits.
  4. Create long-term goals and smart objectives. Goals are general statements outlining what you want to achieve to meet your mission and vision and address any issues you are facing. For each and every goal it is important to identify strategies to achieve them. Objectives should be SMART; that means specific, measurable, attainable, realistic, and time bound. It is important that you make a distinction between long-term goals and smart objectives for those goals.
  5. Establish an action roadmap with timelines. An action roadmap is a visual representation of your strategic planning items. It includes high-level agenda items, initiatives, champions and key elements. It includes the key areas that your organization will focus on in order to achieve its goals and objectives.
  6. Build a communication plan. Communication plans should not be complicated and should be shared within your organization. It is important that time is spent determining the best approach for getting people informed as to what is planned and ensuring that they know impacts of not achieving the objectives. Consider printed plans, maps, high-level visuals, town hall sessions, etc. It is all about communication. Be visual, be creative.
  7. Establish an implementation and monitoring plan. This is important to be successful. Organizations and teams fail because they don’t assign a top-notch resource to put together an implementation plan. Consider using a highly-skilled program manager or director to translate the strategic plan into tactical reality. Ensure that the rules of engagement are established and build a strong monitoring process that engages people in open dialogue centred around the actions that must be taken to be successful.

Strategic planning is an important part of every organization’s success. There are key elements that must go into strategic planning; if you do not have all the elements to start with, then you must start with the basic strategic planning process (BSP). Everything that you do as an organization will come from your strategic plan. This includes enhanced sales, improved business processes, inventory controls, or market advancement. The list of options is huge. We don’t plan to fail, we just fail to plan.

Don’t forget to leave your comments below.

Confessions of a Legacy Business Analyst

After printing your requirements document, do you normally walk through the office looking for a heavy duty stapler or a really big punch? Or, like me, do you actually own your own heavy duty stapler AND a really big punch?

The last requirements specification I wrote was a beauty: It took me five months to produce over 300 pages of as-is and to-be business processes, describing the entire enterprise to the last detail. I couldn’t find a stapler big enough after I printed it, so I eventually split it up in eight different documents. Today, it is saved somewhere on a SharePoint folder, not read, not signed.

You see, the project changed direction during those five months, and there wasn’t enough time to keep the documentation up to date. And the stakeholders started involving some other people. People who, in my opinion at least, knew absolutely nothing about requirements definition. But I had to listen to them as the project stakeholders were listening to them even though it sounded like they were speaking a completely different language. As I was listening, things started making sense, and I began to realize that there is so much more to business analysis, that our profession is quickly changing, adding multiple new facets, and that I’m at risk of being left behind.

But at least this sad story has a happy ending. Does some of it sound familiar to you? Are you at risk of becoming a legacy business analyst?

Let’s define a legacy business analyst.

  • A “recipe” for business analysis: The legacy business analyst applies the same approach to every project. Whether it is using the same old BRS template, using the exact same format for every workshop or compiling the same set of diagrams for every project, they follow the recipe every time. On your next project, suggest to the other BAs that you don’t compile a context diagram—you’ll quickly identify the legacy business analysts from their reaction.
  • Big requirements up front: The longer the requirements phase of your project is, the greater the possibility that your BAs are legacy business analysts. The legacy business analyst has to get ALL the requirements before he (or she) is satisfied. The reality is that sometimes we don’t have that luxury. Sometimes the external pressures on a project mean that 80% or even 70% of the requirements will have to do, and we’ll figure the rest out as we go along.
  • An Agile objectionist: It’s not just Agile, it’s every new methodology. Agile is the one that everyone is talking about, and it is what the legacy business analyst is objecting to right now. But every time an alternative to traditional functional business analysis is suggested, the legacy business analyst is first to shoot it down because it doesn’t fit the recipe.

(OK, another confession. Some time ago I was responsible for interviewing every business analyst who applied for positions at my employer, and there was one question that I always asked, the question that really mattered: “What goes in the table of contents of a requirements specification?” Ouch, I wonder how many potentially great BAs I missed because of that.)

The BA’s World Is Changing

As business analysts, we can no longer depend on our traditional role as a requirements scribe to show our value to the business organization. We have to expand the range of our skills and adapt to find the best solution to each business problem we face. Because, our primary responsibility is to solve business problems, not implement technology.

I spent a large part of my day yesterday leading a workshop with a group of business users to figure out how the new off-the-shelf software they bought is going to change their business processes. As we were taking a break, a senior business manager asked me:

“What are you? A project manager?”

“No,” I answered, “I’m a business analyst.”

“But I though the business analysts are the ones that do the technical documents for IT?”

I didn’t have enough time to answer that one.

There are three alternative approaches that I currently focus on. They are definitely not the only alternatives available to business analysts, but they are the ones most applicable to me right now.

Business Process Management

Business Process Management (BPM) is not new and business process re-engineering even less so. But it seems that every time there is a downturn in the economy there is a renewed focus on BPM. Lean Six Sigma has become popular again, and businesses are looking for alternatives to technology as solutions to business problems.

The increased maturity of business architecture also compliments BPM and enables us to really evaluate the business (and technology investment in the business) critically. My favourite quote by Bill Gates is:

“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second rule is that automation applied to an inefficient operation will magnify the inefficiency.”

The approach should be to view a technology solution as the last option.

Customer Experience

The theory of customer experience is becoming very relevant with the advent of Big Data, and I interpret its impact on business analysis as “Treat your customer’s customer as if he is your customer.” You may think that this doesn’t really affect us as BAs, but here is a real life example: Quite a bit of my 300-page BRS mentioned above is dedicated to the requirement that customers must register on the website before they can purchase anything, what information they must provide, how their password resets work, etc., etc. That’s a given, right? The “other” people applied the principles of user-centric requirements (it’s not a new concept—the textbook I now have on user-centric requirements was first published in 1998). Their first requirement was that customers don’t want to register and log in every time to buy because they are used to the Amazon “1-click.” Somehow that makes sense, doesn’t it?

Going Agile

If, like me, you are not a real fan of SCRUM, have a look at Disciplined Agile Delivery, developed by Scott Ambler and Mark Lines. I think it’s time that business analysts, instead of opposing going Agile, start advocating Agile methodologies in the IT organization.

The Next Wave

What’s next? What do we have to prepare for?

Firstly, the first iPhone was released in 2007—when some of your business users were 14 or 15 years old. The big impact of smartphones and tablets on business analysis is that they change the way our users view the applications we design for them. So we have to start considering that our users will expect to interact completely differently with business applications.

Secondly, the one I’m researching at the moment is gamification, a concept borrowed from gaming platforms suggesting that users are “rewarded” for interacting with an application in the expected manner. It sounds a bit fuzzy, but the biggest investor in gamification in the world at the moment is SAP. Later this year SAP will launch its first gamification platform, so maybe it’s worth looking at.

Lastly, my son is six years old this year. I still want to be a business analyst in 15 years’ time when he will probably enter the job market. The way he interacts with technology, and is going to interact with technology in 15 years’ time, is completely different from the way I interact with technology. As a business analyst, I must never stop learning and never stop reading so that I will be prepared for that day. (If you really want to blow your mind, go have a look at Makey Makey—he’s definitely getting that for his next birthday!)

Don’t forget to leave your comments below.

Improving Your Requirements Processes

KW_Feature_Feb14Books on business analysis and requirements engineering, such as my own Software Requirements, describe dozens of “good practices” that can help any organization improve the way it develops and manages requirements for its products. Learning about the practices is one thing; implementing them and reaping the benefits is quite another. Putting better practices into action is the essence of software process improvement. In a nutshell, process improvement consists of using more of the approaches that work well for us and avoiding those that have given us headaches in the past. However, the path to improved performance is paved with false starts, resistance from those who are affected, and the frustration of having too little time to handle current tasks, let alone improvement programs. The ultimate objective of software process improvement is to reduce the cost of creating and maintaining software. There are several ways to accomplish this:

  • Correcting problems encountered on previous or current projects
  • Anticipating and preventing problems that you might encounter on future projects
  • Adopting practices that are more efficient than the practices currently being used

If your team’s current methods seem to work well (or if people insist that they do despite evidence to the contrary), people might not see the need to change their approach. However, even successful software organizations can struggle when confronted with larger projects, different customers, long-distance collaborations, tighter schedules, or new application domains. An approach that works for a co-located team of five people with a single customer doesn’t scale up to 125 project participants located in two different time zones who are serving hundreds of corporate customers. At the least, you should be aware of other approaches to requirements that could be valuable additions to your software engineering tool kit. Let’s begin our journey through requirements process improvement by seeing how requirements activities relate to various other key project processes. Changing how your projects handle requirements will of necessity affect these other processes, and vice versa. If you want to succeed with requirements improvement, you’ll need to get the owners of these other process areas to play along.

How Requirements Relate to Other Project Processes

Requirements lie at the heart of every well-run software project, supporting and enabling the other technical and management activities. Figure 1 illustrates some connections between requirements and other processes; the sections that follow briefly describe these process interfaces.

KW_Feb14

Project planning. Too often, project deadlines and staff allocations are determined before the requirements are well understood. It’s no wonder then that so many projects overrun their schedules and budgets. A more realistic approach is to make requirements the foundation of the project planning process. The planners select an appropriate software development life cycle and develop resource and schedule estimates based on the requirements. Thoughtful planning might indicate that it’s not possible to deliver the entire desired feature set within the available bounds of resources and time. The planning process can lead to reductions in the project scope or to selecting an incremental or iterative to deliver functionality in planned chunks.

 

Project tracking and control. Project tracking includes monitoring the status of each requirement so that the project manager can see whether construction and verification are proceeding as intended. If not, management might need to request a scope reduction through the change control process. If you find early on that your team isn’t implementing requirements as quickly as planned, you’ll need to adjust the expectations to reflect the reality of your team’s productivity. Sometimes this means reallocating lower priority requirements from the backlog into later iterations than planned. It doesn’t matter whether you, your managers, or your customers like this or not: that’s just the way it is.

 

Change control. After a set of requirements has been baselined, all subsequent changes should be made through a defined change control process. The change control process helps ensure that:

  • The impact of a proposed change is understood.
  • All people who are affected by a change are made aware of it.
  • The appropriate people make informed decisions to accept changes.
  • Resources and commitments are adjusted as needed.
  • The requirements documentation is kept current and accurate.

System testing. The testing and requirements processes are tightly coupled. User requirements and functional requirements are key inputs to system testing. If the expected behavior of the software under various conditions is not clearly specified, the testers will be hard-pressed to identify defects and to verify that all planned functionality has been implemented as intended. An excellent starting point is to start thinking about testing from the very beginning. Think of user acceptance tests for each requirement as you specify it. This is a great way to identify missing exceptions and ambiguous requirements.

Construction. Although executable software is the ultimate deliverable of a software project, requirements form the foundation for the design and implementation work, and they tie together the various construction work products. Use design reviews to ensure that the architecture and detailed designs correctly address all of the requirements, both functional and nonfunctional. Unit testing can determine whether the code satisfies the design specifications and the pertinent requirements. Requirements tracing lets you document the specific software design and code elements that were derived from each requirement.

User documentation. I once worked in an office area that also housed the technical writers who prepared user documentation for complex software-containing products. I asked one of the writers why they worked such long hours. “We’re at the end of the food chain,” she replied. “We have to respond to the final changes in user interface displays and the features that got dropped or added at the last minute.” The product’s requirements are an essential input to the user documentation process, so poorly written or late requirements will lead to documentation problems. The long-suffering people at the end of the requirements chain, such as technical writers and testers, are often enthusiastic supporters of improved requirements engineering practices.

The central point here is that you can’t modify your requirements practices in a vacuum. The thoughtful improvement leader will consider the context and identify stakeholders of other internal processes who would be affected by changes in the requirement development and management processes. By engaging those counterparts in a collaborative effort to improve the way your teams approach requirements, everyone will come out ahead.

Don’t forget to leave your comments below!


Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons. Karl produced this article for Enfocussolutions.

Why Business Analysis Processes are a Waste of Time

Kupe_Feature_Oct18_CroppedI recently read a sales blog post, Why Sales Scripts are a Waste of Time, where the author talked about the need for sales professionals to adapt their approach based on the customer they are selling to and not follow a standard script or process they learned through sales training.  Rather than follow a process step by step a sales professional should use the steps as a framework.

The same applies to the business analysis community and a business analysis process. There are techniques, skills, tasks and approaches you have at your disposal.  It is the collection of those that will help you adapt your approach for each project.   The projects our community works on are not to build widgets.  The Ford Motor Company requires a consistent manufacturing process. Ford wants to make sure every Ford Fusion that is built looks and acts the same.  They fine tune their manufacturing process and make sure it is as repeatable as possible. There are steps that are followed A to Z with no deviation to ensure consistency.  Yes, different lines of a model include different steps, but you get the picture. 

In manufacturing following a process step by step is a good thing. In our world this is not the case.  Following an A to Z process for every project is a bad thing.  Every project is different.  Different people, different risks, different priorities, etc.  You need to adapt your process to meet the needs of the project. With that said there are two must steps.  One, plan your approach for the initiative and two, conduct a retrospective to learn and adapt for future initiatives.  There should be a consistent start and a consistent end.  Everything in between should be flexible.

At the beginning of a project or iteration you and the team need to plan the approach.  The team needs to determine what steps you’ll take during the project.  You as the expert need to provide your thoughts and advice for the analysis steps, but you should not determine your approach in a vacuum.  Your team needs to buy-in to the approach and ensure their needs will be met to ensure a successful project. 

Things never go perfectly, so you should be inspecting your approach as you go and make adjustments.  At the end of a project or iteration you should inspect and learn to improve for your next initiative.

Let me end by stating I don’t think you should have to make everything up in between your plan and retrospective for every project.  You should have a base approach that you use as a framework.  Just use that as a starting point to add and/or remove steps to customize your approach for the specific project. 

All the best,

Kupe

Don’t forget to leave your comments below.

Why is Business Process Design the Future of Business Analysis?

BaTimes_Feature_Nov2_cropped“Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”

– BABOK V2, page 3.

In order to achieve the objective of enabling the organization to achieve its goals, the business analyst engages in Requirements Elicitation. The following is extracted from the BABOK:

“The definition of elicitation is:

  1. to draw forth or bring out (something latent or potential)
  2. to call forth or draw out (as information or a response)

These definitions highlight the need to actively engage the stakeholders in defining requirements.”

– BABOK V2 (page 53)

The implication is that requirements come from subject matter experts (SMEs) and that the BA must extract them or draw them forth. But where did the SMEs get the requirements? Did they make them up? Do they represent their personal preferences? If the answer is yes to either, then requirements become virtually untouchable statements that can only be verified by the person who verbalized them. If the answer is yes, then a requirement can change at the whim of its originator.

Requirements are not and should not represent personal preferences that can’t be independently verified. Requirements must be owned by the organization. But what do they represent? Let’s again turn to the BABOK.

“A requirement is:

  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
  2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.”
  3. A documented representation of a condition or capability as in (1) or (2).”

– BABOK V2 (pages 4-5)

The difficulty with these definitions is that they portray requirements as already existing prior to the start of the BA’s work. The BA’s challenge, then, is to somehow pry or draw out the requirement from its source-the stakeholder, the contract, the standard, or other imposed document. They imply that requirements are the output of some other process but somehow they were never properly recorded. So, in rides the BA to record them. If that were truly the case, then requirements would be captured correctly the first time, for the most part, because the stakeholders already know them. Requirements would be unlikely to change.

We know that this is not consistent with reality. Requirements are often wrong, irrelevant, or incomplete, and not because they were misunderstood. They were wrong from the start. In addition, requirements statements tend to change frequently and continuously. Why would that be? A reasonable conclusion is that the requirements that we are trying to elicit (draw out) don’t actually exist yet. It is the process of drawing them out that is making people think about them-possibly for the first time. That’s why they change so often. In other words, people are designing their process on the fly and in an unstructured and unreliable manner.

“No matter how hard individuals work, they cannot overcome a flawed process design, much less the burden of no design at all.”

Michael Hammer, The Agenda.

So what should requirements be? As per the definition, they represent a condition required to solve a problem or achieve a solution. Or they are constraints imposed from the outside. If a requirement is something needed to solve a problem, then we need to have developed the solution to the problem. In other words, we need to have gone through proper design.

This leads to an alternative way to view a requirement-as an output of process design. True Requirements can only be produced if and while a process is properly designed. That means that in order for a business analyst to achieve the intent of business analysis-recommend solutions that enable the organization to achieve its goals-the BA must engage the Requirements Team in designing the business process. Design is the activity. It must be carried out overtly and systematically and not as a side-effect of elicitation. Requirements are the output. They must be overtly documented in the form of a business blueprint.

Requirements should not be drawn forth. They should be hammered out as part of a structured process of design activity.

Process Design is the Future for Business Analysis

When the going gets tough, the middleman is the first to go. The BA, today, plays too much of a middleperson role. The future BA will be a process design master that leads SMEs and other stakeholders in process design. The endgame is a better process, not just requirements. And a better process requires a structured approach to process design.

The future business analyst will lead a structured design process that produces a process blueprint which contains structured requirements. The blueprint will represent organization needs that can be independently verified for correctness and completeness. The blueprint will separate out any personal preferences from process needs.

The separation of personal preferences is important because these account for many of the unnecessary conflicts that arise in requirements statements. Of course, in order to achieve this a few role changes are required.

The business analyst will no longer be a go-between. Instead she will lead a cross-functional team in the all important activity of designing the business. Today, the BA is master of few things. A BA knows project management but not as well as a project manager. The BA understands technology but not as well as the developer. The BA knows the target business domain but not as well as the subject matter experts. Today the BA is a jack of too many trades and a master of no particular one. This presents a clear and present danger for the BA. In the future, the BA will be the master in process design.

The process owner role needs to disappear. Firstly, few organizations have successfully implemented such a role. Think of ownership and what it implies. An owner can do what he likes to what he owns. That implies that a process owner can do whatever he likes to his process. But value delivering processes are cross-functional with functional owners. That leads to conflict. It leads to processes with two sets of owners, one for the cross-functional process, and one for each functional component. However, it is the organization that should own the business process. Process owners need to be replaced by process governors. A governor manages within a given framework. This makes more sense. The organization owns the process and defines the performance framework for it. The process governor manages that process within the given framework. He is not completely free to do whatever he wants. He must manage within boundaries.

Subject Matter Experts are not the customer. The customer does not change based on perspective. The external customer is the customer. A business process should be designed to deliver value to the external customer. The SMEs are participants of the business process. When the SME or other internal stakeholder becomes a customer, the risk is that their personal needs hijack the true needs. So SMEs,, developers, and other stakeholders become key process participants. Like the process governor, internal participants need to act in accordance with the process blueprint. That ensures that everyone is aligned to the process blueprint which represents the intent of the process.

Of what use is a business process blueprint?

“People who are aligned around a common goal but lack the discipline of a well-designed process will go nowhere … likewise the best-designed process has no chance of survival when people aren’t aligned around the process and its goals.”

Michael Hammer, The Agenda.

Conclusion

Design is the defining discipline of this decade. Structured Process Design is the new discipline whose mastery will set the business analyst apart. Process design will produce, as an output, the business process blueprint, which will contain structured requirements. These will be the foundation for developing strong and useful software applications. Process Mastery is the key future capability that will distinguish the business analyst from other roles.

Elicitation is a middleperson activity that will disappear and no one will mourn its passing. Incorrect, incomplete, irrelevant, and conflicting requirements will be dramatically reduced. Requirements will be independently verified and first pass quality will rise. More projects will be a business success and they will deliver more stakeholder value.

Roles will change to make accountability clear. Teamwork will need to rise. The BA will be the design team leader with SMEs, developers, and other stakeholders as team members. The process blueprint will become a persistent, reusable organization resource for managing process performance rather than a temporary throw-away project resource.

A focus away from elicitation to design will yield benefits for everyone. It will increase productivity and more importantly it will increase value delivered to the organization. Of course, the shift has to be driven by someone. If you like your current job as a requirements order taker, then you don’t need to take any action. But if you prefer the more proactive role of Process Design Master, then you should take the initiative in driving the future, if you haven’t already done so.

Don’t forget to leave your comments below


Angelo Baratta’s focus is advancing human mindware. Based on 30+ years cross-industry experience and over 10,000 hours of R&D comes ePPM by Design – a framework for structured process design (SPD) and requirements.

Learn more about SPD from his book “More Perfect by Design: A framework for designing more perfect business processes” available soon.

In progress is “Getting to Understanding: A framework for Structured Requirements.”

http://www.performanceinnovation.com/
[email protected]
905-270-7591