Skip to main content

Tag: Planning

Resistance as a Major Source for Requirements Risk

mm1This article recognizes resistance as a source for requirements risk. Business analysts recognized assumptions, constraints and dependencies as the major sources of requirements risk. However, in every analysis there is some level of resistance to change. This article reviews the three traditional sources of risk and makes the case for including resistance as an additional source.

What is risk?

Risk is an uncertain event that can have a positive (opportunity) or negative (threat) impact on an endeavor (1). In this context, the endeavor is developing requirements (elicitation, analysis, documenting, and validation), which may be a change to a process and/or software. The result of the development effort is a business requirement document that reflects a stakeholder consensus. Typically, the business analyst recognizes three major sources of risk in planning requirements development:

mm2• Assumptions – business conditions that if changed would affect the requirements or requirements development
• Constraints – conditions that restrict the development of requirements
• Dependencies – requirements that are dependent on other requirements

Change Equals Resistance

The business analyst is a change agent. In developing requirements, the business analyst is inherently involved with change. And, where there is change, there is resistance.

mm3• Resistance is a barrier encountered by the business analyst in developing requirements from stakeholders

Resistance comes in all forms and degrees. Stakeholders typically expressed resistance as a concern or a reservation. However, it may also be to an out-right objection. The key for resolution is for the business analyst to engage in a dialogue with the stakeholder that leads to the reasons behind the resistance (see Figure 1).

mm4
Given the above, the business analyst needs to recognize resistance as a major source of risk and manage it as in the other major risk sources. The business analyst needs to identify its possible occurrences, analyze its probability and impact, and develop a risk response. Note that risks that stem from resistance are threats. In this case, the business analyst needs to avoid, transfer, mitigate, or accept the threat (see Figure 2).
mm5

A Homestead Example

mm6Dick and Jane are a couple with a nice home and are business analysts for a large firm in a downtown business center. One day Dick and Jane decided to upgrade the single pane windows of their home. Being experienced business analysts, they first listed their major sources of risk (assumptions, constraints, and dependencies) and then prioritized their requirements.

  • Assumptions
    • Continue to live in the home for at least 20 years
    • Able to recover window upgrade cost if home is sold
    • Energy cost will continue to rise
    • Reliable contractor available
  • Constraints
    • Budget is $25K
  • Dependencies
    • Compatibility with current window security screens
  • Requirements
    1. Save energy cost with their home
    2. Easy to clean
    3. Sound proof

After shopping around for windows, Dick and Jane settled on triple pane energy efficient windows with removable sashes for easy cleaning and a laminated glass sandwich that should squelch out some noisy neighbors. They then picked a contractor that could handle the current security screens and paid the upfront capital for work to begin. All was well until they met resistance.

mm7Remember Dick and Jane live in a nice house, in a nice neighborhood, with a not-so-nice Home Owner Association. Upon the first week of window installation, they received a letter from their HOA advising them to cease all work until they submitted a request to the HOA detailing the change to their house. Although Dick and Jane own their nice home, they have come to realize there is a third stakeholder – the HOA and the HOA can be quite resistant. Lesson learned: always consider four major sources for risk – assumptions, constraints, dependencies, and resistance.

Summary

Business analysts need to manage risk associated with the development of requirements. Traditionally, they consider three major sources of risk: assumptions, dependencies, and constraints. However, business analysts are agents of change. Very few projects, if any, do not incur some level of resistance. Business analysts need to include resistance as a major source for risk along with the traditional three.

References

  1. Project Management Institute, A Guide to the Project Management Body of Knowledge 4th Edition, (Dec. 2008)

Don’t forget to leave your comments below.

Reinventing the Swim Lane Diagram. Part 1

We’ve all used the swim lane diagram. It’s simple and easily demonstrates a process, but I’ve often thought it could do more. When I document a business process, I want to show more than just who is doing what; for example, indicating which systems they are using, what kind of data they are updating, and illustrating a wider picture of the process. These are all factors that render significantly improved results and refined clarity. In this article we’ll look at some ways we can take the basics of the swim lane diagram and add some heightened functionality.

In this first part, we’ll cover a method of demonstrating process and systems interaction within the style and template of a traditional swim lane.

Let’s pause first to set the scene with a typical process swim lane for a sales quoting approval process. In this process, let’s imagine that there are four different systems: the Sales Person working in their CRM system, quoting tool and email client, Sales Management in an approval tool.

Does the swim lane below really demonstrate this clearly?

In this diagram, it’s difficult to realize at a glance, that the Sales Person has three separate systems (in many organizations this can also mean three separate logins). As a result, it doesn’t accurately demonstrate the amount of work the Sales Person might need to do to produce a quote. In fact, on the face of it, the quote approval process looks simple!

So what can we do to make it more readable? One option would be to color code the boxes to show the different systems, as follows:

 

Again, this diagram seems to work by color coding the different systems, but what really ends up happening? One might think, “Wow, nice colors, what do they mean?” So, similar to the first diagram, we are left with unanswered questions and an ambiguous picture of the process. Legends, too, seem to just add to the confusion.

Let’s look a little deeper. Colors, although effective in distinguishing difference, in the above example require a legend. If we could make more economical use of color and eliminate the need for the legend, things would be better. The diagram below does just that. By using color in the border and including a colored label, you can simply differentiate the systems (i.e., adding the system name to the label eliminates the need for the legend).

Now you can clearly and quickly see that when the Sales Person creates a quote, they have to actually use three different systems, with a fourth system used by the Sales Manager for approvals. All this is achieved without the need for a legend and I haven’t confused the reader with lots of overwhelming colors.

 

Finally, I can also annotate to add some further details. In this example, I am sacrificing some readability for a deeper understanding; however, in this case, I think it works. Using an email icon, I annotated both the Quote Approval and Email Client. The approval discount condition is also annotated.

Every diagram should have a version number, ideally a date and an author. This will ensure that when you use the diagram, in a presentation or a meeting, you can guarantee everyone is referencing the same information. A date allows you to see when the diagram was last updated, and the author serves as a reference if the diagram is used elsewhere in the organization.

 

In our company, we have set up our process diagrams using a Visio stencil, creating a template for repeated use. The parameters of the template include clearly defined color coding schemes for all major systems (green means finance, blue means sales, etc) with regular color mapping to other types of diagrams (i.e. system diagrams, data flow diagrams, etc.) Over time, business users recognize these colors, and find this an effective way to illustrate when a business process requires the use of multiple systems (as shown in the example). It also indicates where there is systems overlap between departments (e.g. when a Sales Person interacts with a Finance-based system).

To summarize, we’ve concentrated on ways to increase the effectiveness of the swim lane diagram. The sparse and efficient use of color, defining each color’s meaning, and the introduction of labels and annotation allow for a more profound exchange of information. In Part 2 we’ll start to explore further additions to the swim lane diagram for tracking the underlying data usage, and investigate methods to clarify swim lane diagrams when put into a context of the wider picture. We’ll also talk about having now set up a basic swim lane template, how we can then increase adoption and maximize the use of it.

Don’t forget to post your comments below!

 

Mark Jenkins is Manager Business Analysis Group at Websense. Mark has spent the last year establishing a formal Business Analysis Group at Websense that now plays an active role in all major business projects. As part of the development, he created new process and documentation standards, which assisted in the overhaul of IT Project processes, placing the BA Group at the forefront of the IT to business interactions. He can be reached at [email protected]

Reinventing the Swim Lane Diagram. Part 2.

Please click on any image to view an enlarged copy

This article is a continuation of the “Reinventing the Swim Lane Diagram” process. Part 1 concentrated on ways to increase the efficacy of the swim lane diagram. Methods such as using color in a sparse and efficient manner, clearly defining each color’s meaning, and the induction of labels and annotation led us to realize to a more profound exchange of information.

Before we start Part 2, let me take pause to respond to some of the feedback from Part 1.

With any diagram, standard or best practice, it is vital to ensure that whatever you use, it’s appropriate for your audience. The typical audience for my swim lane diagrams is business users. At Websense, we are lucky to have an architectural and design group to handle the technical interpretation of business requirements. My group concentrates on understanding how a process is performed today, and then working with business users to decide how it is going to work in the future, providing insight into the complexity of the process. For the business stakeholder, the system they use of the utmost importance as it is a major contributor to their success. For example, performing a process in the slick CRM system might be a very different proposition to the clunky Quote System. We use the template for both “as is” and “to be” process documentation; and we generally communicate it through an analysis review or in the context of the final requirements document, although the diagram has its own standalone value.

In addition, my goal in Part 1 was to create a mock diagram, from which you could conjure ideas for a variety uses and applications, each tailored to individual demands.

In Part 2, I’ll explore some further additions to the swim lane diagram, which will help place a process in the context of a wider business picture. I’ll also cover how to increase and maximize the use of the swim lane by creating a Visio stencil. I’ve decided to add a Part 3, where I’ll cover an effective way of demonstrating the underlying data in a simple format, which builds the swim lane further.

The finished diagram from Part 1 is used again in this article.

Scott had mentioned in his comment about Part 1 that it is important to show the inputs and outputs of a process, and I agree. I achieve this by adding “process link” boxes, again with an appropriate color and label.

In the example below, I added the start feed as well as the output. For the detail-oriented, I also updated the version number and date.

swimlane1

This diagram now easily shows a Marketing start process as well as an output order process, initiated by the sales person. You could also consider annotating the bottom corners of the process boxes with numbers, but I think it’s unnecessary unless you had multiple start points or confusing decision trees.

In order to increase and maximize the use of the swim lane diagram, I’ve found it effective to develop a Visio stencil. Creating a Visio stencil for this purpose can “template” or “palate” shapes for use in future designs, therefore drastically reducing the time it takes to create swim lane diagrams.

Make sure you have the majority (if not all) of your systems identified beforehand, this will help you when choosing color groups. If you are using a Visio stencil in group environment (i.e. a team of BA’s) then proactively meet and set up the stencil together. This should prevent divergence when you later come across a new or overlooked system. Using primary colors to designate certain system groups is also effective. For instance, you can use different shades of your primary color to indicate systems which “hang off” of a main system, as shown in the example below.

swimlane2

If your group has a team logo and/or a company logo, add this to the swim lane frame (which we also created as a stencil shape).

Another nice touch is to use the company color scheme on the frame borders and swim lane headers.

These two small points allow you to produce something that looks official, which adds major percentage points to the credibility of the diagram. You can end up with final version of the diagram that looks something like this.

swimlane3

The great advantage of the Visio stencil is that it provides a framework on which you can build tailored stories that clarify process meaning and purpose. The first step, for my group, was to consistently use, adapt and improve the stencil. At this stage, you are basically road testing, ensuring that you have included everything you need. As the diagram is used in documentation or meetings, you are generating awareness and hopefully interest in the diagram. The business users’ benefits of seeing a consistent diagram format are also significant, reducing the comprehension time of changing diagram formats.

Once you’ve ironed out the kinks, got BA’s or colleagues consistently using the diagram, and your stakeholders comfortable reading it; you can start to drive it as a company standard for documenting business processes (keeping in mind my first point: use it when it makes sense and is appropriate to do so). For my group that meant building a store of business processes that can be accessed by the business stakeholders across the company. We also published the stencil to our Sharepoint team site, with instructions on how to install and use it (this assumes that you have enough users with Visio knowledge), so anyone can create their own process flows. This sort of implementation creates a language in which all involved are fluent. There really is no more powerful tool for a BA than having stakeholders able to express themselves using BA documentation standards.

For the majority of business users, this is as deep into the swim lane as you would want to go. We’ve pushed up the boundary of what I think most users can realistically comprehend, but for BA’s and technical users, there’s even more detail we can add to a swim lane base, to track data use within a process.

A lot of information will be displayed within a single diagram, so it is important to keep in mind that when using this technique, the audience and situation must fit.

In the following example, there are likely to be alternative techniques to demonstrate data usage, but again, the goal of my article is to challenge the standard way we look at diagrams.

As you will see, a larger paper size than the standard US Letter is generally required; ledger sized paper or larger is ideal, which tends to guide usage of this swim lane adaptation for higher level focus diagrams that illustrate key, stable processes. For example, this approach is not best suited for projects “under construction,” and would be better matched for situations where you want, for example, to mount a finished document to a wall for reference.

The goal of this technique is to portray the process flow as it relates to underlying data while simultaneously identifying the primary data store. This technique facilitates business users’ understanding of report origin and process interrelations, which in turn, procures their comprehension of report generation.

Without further prefacing, let us discuss the aforementioned technique which begins by reviewing the completed swim lane, identifying data change points within the process, and then matching them to a broad-level view of the data. By broad-level view, I mean condensing relevant fields together such as Customer Address, which may be 5 or more system fields, and referencing them under a single umbrella of “Address.” Regrouping applies across all data objects; “Contact Details” may be sufficient to capture “Address,” “Phone,” “Fax,” and “Email”. Reorganizing some of the process boxes may be required, but the increased page size should allow for more freedom.

Having identified data change points, I can now annotate the normal swim lane with sections, separated by vertical dotted lines.

swimlane4

At the bottom of the swim lane, data groups are added. In this example, 3 key data points are of interest (of course there are others): 1) Account – the company a customer works for. 2) Contacts – the individual contacts who work at the company. 3) Pricing – the Quote produced by the sales person.

swimlane5

Data storage systems are now added to the intersection of data (X axis) and process sections (Y axis). I typically identify the system of record as the first system in a section. If the system of record changes, I highlight it in red in place it as the first system in the section.

swimlane6

Your final completed diagram might look something like this.

swimlane7

This article has covered a lot of detail. In the first section of this article, we looked out how creating a Visio stencil provides numerous possibilities for collaboration. In the second section, we discovered that adding further detail to a standard swim lane illustrates the underlying data usage of a process. I hope that these two articles have been helpful in lending new techniques and have assisted in the adaptation of your own diagrams.

Don’t forget to post your comments below


Mark Jenkins is Manager Business Analysis Group at Websense. Mark has spent the last year establishing this formal business analysis group that now plays an active role in all major business projects at Websense. As part of the development, he created new process and documentation standards, which assisted in the overhaul of IT Project processes, placing the BA Group at the forefront of the IT to business interactions. He can be reached at [email protected].

Mark would like to acknowledge the help and editorial assistance of Skylar Waldman in producing these articles.

Short on Time? Have MORE Meetings!

OK, before you think we have gone crazy…we recommend more SHORT, FOCUSED meetings. As project managers and business analysts we often find ourselves with pressing deadlines, frantic team members who are juggling many tasks with little time, and senior stakeholders who place increasingly challenging demands upon us. At the same time, we face unchanging statistics showing that communications issues are at the core of project failures. How do you manage these two imposing situations? Have MORE meetings, but make them count, and do them quickly. Let’s examine why we need these frequent, focused meetings, and how to best conduct them.

The type of meetings we are discussing here are usually no more than 15 minutes; on rare occasion they may take half an hour. Often they are run as daily “stand-up” meetings, in conference rooms with the chairs removed or pushed to the side of the room. This is optional, however, for some the “stand up” aspect of these meetings help keep the attendees focused. These quick meetings are usually first thing in the morning to prepare for the upcoming day, or they are the final thing done at the end of the day, to prepare for activities that will take place early the next business day. So, given this, why are more frequent meetings a useful tool?

1. Your team needs as much efficient heads down time as is possible

Rarely do any projects allow team members to operate in a vacuum. Conditions change, problems and unexpected circumstances surface. Communication from the project’s various stakeholders is virtually constant. Team members need to a) know what their mission is on the project and b) have the information they need to get their tasks accomplished in the best way possible. With this constant flow of needed data, the forum to communicate all of this information requires frequency and efficiency. The short, focused, and regularly scheduled meeting can accomplish this. The project manager can also receive information from team members relative to status, risk management and issue information in an efficient fashion as well.

2. Team members need to know about dependent tasks, and required interactions

In our formal project management training, we spend considerable time (appropriately) on risk management. Classical risk management talks about potential events that may affect the project, the completion of project tasks, or the project mission as a whole. In the fast paced, increasingly technical area of product development, it is just as important that we treat information about dependent tasks and other potential interactions with other team members, major stakeholders or vendors, like we do for risks. We need to recognize these interactions, plan what we need to do to address them, and be prepared if the interaction event takes place. These interaction events can cause us to have to review data, review status, alter our approach, or in the most significant instances, re-plan how we are accomplishing our tasks. Only through interaction with our peers and leaders, and obtaining timely information from stakeholders can this be accomplished efficiently and effectively. We don’t need extensive ‘interaction management plans” to do this; however we do need to interact frequently about the potential, so we can be prepared for upcoming project situations.

So, given these meetings are so important, how do we make them effective in both maximizing team members’ “heads down time” and preparing them for these potential “interaction events?”

1. Don’t make them mandatory – make them “conditional” and you control and communicate the attendance conditions.

The legitimate complaint that most people have about meetings is that they are a waste of time. They go too long, and they aren’t useful. We get into the habit of inviting the “standard team set” to every meeting. When your team is crazy-busy, we need to step to the plate as leaders and make the effort to determine WHO needs to be at our short, focused meetings. So, set the conditions for your team members as to who should attend, communicate those expectations, and share the conditions before every meeting so those that don’t need to be there won’t need to attend. When you first start this technique, fail on the side of conservatism and have people attend. As time progresses, and you get feedback on the usefulness of the meeting, you can fine tune your attendance condition setting. The key to this is simple…if YOU can’t identify the critical piece of information they will take away from the meeting, then they do not need to be there. If YOU need a piece of information from a team member – collect that at the very start of the meeting. Carl Pritchard’s “Wall Walk Protocol” is a great approach to doing this for larger project teams.

2. Hold more than one daily meeting – with different attendees

This might not be as efficient for you as the project manager or the lead business analyst, but this isn’t about you. It is about the productivity, effectiveness and efficiency of the team. If you do this well, and your team feels you are conducting effective meetings that are worthwhile and they get the information they need, you will benefit from a) not having to chase people down to get or share information and b) they will work with better data, which will reduce the issues that you will have to deal with. This usually saves you more time than you will spend on setting attendance conditions and holding separate meetings. Holding separate meetings – and doing this well – avoids the biggest time waster in meetings…that of having to listen to someone drone on about something that isn’t meaningful to them. Divide your team into sub-teams of people that work together often, and have separate daily meetings. To maintain “a whole team” consider having the entire team attend one of the daily meetings each week. Set the agenda for that team meeting be things of relevance to the entire team.

3. Take the meetings seriously, but don’t force yourself and your team to be serious

Efficiency not only comes from getting and giving information effectively and in a manner that is valued by team members. Efficiency also comes from team members that know and understand each other in more than a professional capacity. Take time to recognize birthdays, significant accomplishments, not so significant accomplishments, and times when you acted as a team. Bring cookies or breakfast to the weekly whole team meeting – be human yourself as the leader and encourage your team members to do the same.

4. Talk about the “elephant in the room”.

Because the group of people will be small, take advantage of the intimate size. Cut to the chase and bring up topics that might be “taboo” in a larger group situation. The more open and forthright about providing information you are, the more the team will feel comfortable doing the same. Information is key to our success and the earlier people open up to share “bits of vital information” the better positioned the project will be for success.

Don’t forget to leave comments below.

Five Ways to Know When You’re Done with What You’re Doing

If you often feel like you’ve barely skimmed the surface of what you should have accomplished on a given workday, I have a secret for you. When you learn to “know when you’re done” with projects, tasks and everything the workday throws at you, you’ll free up a lot more time to focus on those things that truly matter.

The curse for many of us modern-day movers and shakers is that we never seem to have enough time to do everything that needs doing. There simply aren’t enough hours in the workday (or even the work week!) to accomplish everything on our to-do lists. Worse yet, when we finally do get on a productivity roll, there always seems to be a distraction (or two, or three) waiting in the wings to throw us off course. But the reality is that we could actually accomplish a lot more each day if we would just learn to recognize and acknowledge when we’re done with what we’re doing.

One of the biggest time wasters we all face is spending too much time on those things that don’t require it. When we do so, we lose the time we actually should be spending on more difficult or time-intensive tasks. But when you learn to recognize when you’re done with a task, you’ll have valuable minutes and maybe even hours added back into your day.

It often seems that we put off the most important things on our to-do lists until we feel like we have the ‘time’ to work on them. When you learn to recognize when you’re done with projects, big and small, you’ll immediately find that you have a lot more time than you thought you did. Time you can use to focus on those things that truly matter.  Read on to learn more about how to know when you’re done:

Stop majoring in the minors. Many of us spend a lot of time on those projects and tasks that are easy for us. Then we convince ourselves that we “just didn’t have enough time” to get to the harder stuff. But when it comes to knowing when you’re done and freeing up time during your day, completing these easy tasks quickly and efficiently is essential.

Before you start your workday, think about what your high-leverage activities are and what your low-leverage activities are. For the low-leverage activities, force yourself to move through them as quickly as possible. With these tasks — for example, writing an email to a colleague — perfection isn’t necessary, and there’s no need to waste time wringing your hands over every word. When you can accomplish these minor tasks more efficiently, you’ll have the time you need to do those major tasks justice.

Don’t overwrite emails. Much of your time — probably too much — each day gets eaten up by email. Make a conscious effort to keep your emails as short and sweet as possible. Get to the point quickly and use action verbs in subject lines so that both you and the recipient know what needs to happen before the email is even opened. And while long emails waste the time it takes you to write them, keep in mind that the person receiving the email doesn’t want to have to spend so much time reading it either. Chances are your boss doesn’t want or need a three-paragraph rundown of how your client meeting went. He just wants to know if the client is happy and continuing business with you.

Quit over-staying at meetings and on conference calls. Often, meetings and conference calls will take as long as you’ve allotted for them. Set an hour for a meeting and you’re sure to go the full hour. Pay close attention to how much of your meeting is actually spent focused on the important stuff. If you spend 15 to 20 minutes at the beginning or end of the meeting discussing your coworker’s golf game, then next time reduce the amount of time allotted for the meeting. And always know the meeting’s or call’s objectives before you begin. That way you can get to them right away.

Set your own deadlines and stick to them. It’s very easy to get distracted or sidetracked by things you think you should do or things others think you should do. Having a self-imposed deadline will help you ignore those distractions. If a colleague calls you about a non-urgent task, you can let him know you’ve got a 3:00 p.m. deadline that you have to meet. There’s no need for him to know that it’s self-imposed! And then as 3:00 p.m. draws near, start wrapping up that particular task.

Know when it’s time to ask for help. Have you ever been stumped by a certain project or task? Did you walk away from it for a while and then come back to it hoping you’d suddenly know what to do? Sometimes knowing when you’re done is knowing when you, specifically, can’t take a project any further. You simply might not have the right expertise to finish a certain project completely. And that’s okay. Wasting time on something you’re never going to be able to figure out is much worse than asking for help!

When you put in place steps to help you know when you’re done, you’ll be surprised and pleased with how much, well, you can get done. It will truly free up time in your day that you can use to focus on areas where it’s really needed. As a result, you’ll have a more gratifying workday and you’ll be happier overall.

Don’t forget to leave your comments below.


Jason W. Womack, MEd, MA, provides practical methods to maximize tools, systems and processes to achieve quality work/life balance. He has worked with leaders and executives for over 16 years in the business and education sectors. His focus is on creating ideas that matter and implementing solutions that are valuable to organizations and the individuals in those organizations.
 
Author of Your Best Just Got Better: Work Smarter, Think Bigger, Make More, Jason shows that working longer hours doesn’t make up for a flawed approach to productivity and performance. Entrepreneurs need to clarify their habits, build mindset-based strategies and be proactive. Womack’s signature workplace performance techniques offer specific strategies to improve performance consistently and incrementally.