Tag: Communication

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

Written by Jason Womack on March 26, 2012. Posted in Articles.

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.

The Missing Link to BA Competency Development

Written by Angela Wick on March 19, 2012. Posted in Articles. 1 Comment on The Missing Link to BA Competency Development

When I think about what it takes for BAs to be successful, it always comes down to the same thing: Using hard skills and soft skills together strategically to get results and engagement from stakeholders. When I think about what it takes to execute on any BA activity or technique and to be good at it, it is rare to find a scenario when both hard skills and soft skills are not needed. This may not be new to anyone as underlying competencies (many of which are soft skills) are foundational to performing the various BA tasks. Where we fall down on this is in executing this concept well in a variety of situations and complexity levels and showing the path to truly deepen these competencies.

Why is it that we rarely look at the path to developing skills in underlying competencies in the context of BA tasks and techniques? Or when they require an elevated and advanced level of complexity to execute well?

I would like to look more closely at these skills in additional dimensions.

For example: It is easy for someone to say they have been trained in facilitation, and may have some successes and good experiences in facilitation, and therefore they feel they are a great facilitator. But what does it really mean to be a great facilitator? Are those learned skills and experiences really enough to succeed in new and more complex situations? Would they really be successful in facilitating a highly complex topic while working to build consensus with a group of executives?

A BA organizes and facilitates a meeting with a group of stakeholders to review the future state of a business process. The process flow being reviewed was technically correct and the facilitation methods, tone and techniques were flawlessly used. However, the meeting still failed to achieve a desired goal of reaching consensus from a group of executives on the future vision of the business process.

What happened?

This was an opportunity to strategically use the skills of facilitation and process modelling together aligned to the purpose of the meeting. In this example, what gets missed is thinking about the goals and purpose of the meeting as well as the audience, and thinking about how to use these hard and soft skills strategically for the purpose. In many cases like the scenario above, the process flow and meeting planning were thought of as needed together, but not strategically planned and executed together; they were performed as separate tasks in the same meeting. There is an opportunity for the meeting goals, agenda, and expected participation to drive the level of detail that the process flow is presented at. The review and discussion, along with expectation setting with the participants on the level of detail is critical to the success of the meeting. This was a missed opportunity to engage executives in the facilitation techniques used by modelling at a higher level appropriate to the ways they engage.

The soft skills needed to be a great business analyst are difficult to develop. It is hard to find resources, mentoring, etc. that really help develop these skills in the context of being a BA in a variety of contexts, situations and different stakeholder groups.

We hear from our leaders about how important soft skills are, and are usually trained on them separately from BA tasks, activities and techniques. It can be a challenge to apply what is learned to the BA context. Rarely do we discuss or hear about leveraging them together. This makes it difficult to grow and apply the skills and build awareness of when to use soft skills. Some would say it is intuition, and either you have it or you don’t. I believe there is some truth to that, but that much can be learned through developing experience and awareness.

My callout to the leaders of BAs:

Give mentoring and feedback that shows the context and linkage of soft skills and hard skills together to your BAs in the context of business analysis. Help your BAs build an awareness of situational complexities.

My callout to BAs:

Seek feedback in specific situations on a variety of soft skills and how the situation and tactical activity could be improved through soft skills.

Focus more on developing these skills together and seeking feedback on how we use these skills together.

Truly bringing tactical and influence skills together by thinking differently about how we plan and execute our BA activities and technique usage is key to developing strong competencies as a BA.

What are your thoughts and examples of how BAs can leverage tactical hard skills with influential soft skills?

Don’t forget to leave your comments below.

Dealing with the ‘How’ When You are Looking for the ‘What’

Written by Bob McGannon on March 19, 2012. Posted in Articles.

It is the classic problem facing business analysts and other project team members who are collecting project requirements – when asking “what needs to be done?” the responses from stakeholders invariably describe ‘the how’. Many requirements collectors overlook the value of this input, as it can be used as a springboard to more complete, valid project requirements. Here is how you can take this ‘how’ input and extract the most value from it as you create your requirements documentation.

Collect and Separate

Rather than reject the input that describes how to accomplish something, versus getting details on what needs to be accomplished, capture the input as valid and characterize it. As you listen to your stakeholder and record their input, use a flipchart with two columns: one marked ‘What’ and the other marked ‘How’. Recording instances where the stakeholder has shared ‘the how’ allows you to recognize their input as valid, and pursue the requirement further with questions such as “What would you do with this tool if it was available to you today?” Through this questioning, you can ascertain ‘the what’ behind ‘the how’. According to Mindavation staff member and business analysis expert Haydn Thomas, “Sometimes ‘the how’ reflects the essence of the way your stakeholder understands their requirement. Capturing it, and asking further details, not only validates the stakeholder’s need, but it gives you additional understanding as well.”

Utilizing this technique also serves to reframe the thinking of your stakeholders, which can yield additional requirements. As the stakeholders see the project team member sorting the requirements into the ‘what’ and ‘how’ it is likely the stakeholders thinking will mirror this approach. Lastly, when repeated, the ‘what’ and ‘how’ separation technique will help instill better habits amongst stakeholders as they will see the focus on obtaining and understanding the ‘what’, and will display a greater tendency to present requirements with a focus on what they are trying to accomplish.

What is missing?

Projects by definition create change in an organization. From the stakeholder’s viewpoint this change could a) fulfill a gap, b) add capability and/or c) increase their productivity or accuracy with the work they perform. If this is true, then something is missing in the existing processes and systems that could enhance their job. A good requirements gatherer will utilize a sense of curiosity to find out what that missing capability is, and what will be required to provide that capability. In addition, characteristics of the missing capability can be explored with the stakeholder to ensure the requirement is fulfilled in a pragmatic, easily acceptable manner. This can be done while still focusing on the ‘what’ – and separating the ‘how’ – should it surface. In instances where an existing system or process is being altered, stating ‘the how’ can be the best way to understand and capture the requirement into a ‘what’ format. This alteration usually reflects the need of the stakeholder, and describes how a new capability can be incorporated into a current environment without requiring substantial new tools or processes.

What’s Good About It?

Often stakeholders will share ‘the how’ by actually asking for a process or tool with which they are familiar. This is human nature at work; often stakeholders view this as ‘the what’ when they are actually conveying ‘the how’. They do this because they know of no other example or means of conveying their requirement. If a tool is not mentioned by name, ask for specifics so the tool can be investigated. From there, move on to probing questions about what the stakeholder liked about the tool or process, what they didn’t like about it, and how it changed (or enhanced) the way they completed their work. From this, the requirements gatherer can extract ‘the what’ that is needed to complete project requirements documentation.

Take the Deep Dive

The process of requirements gathering starts with a collection of organizational needs. Ultimately however, detailed requirements including functional requirements, process steps, business rules and performance criteria need to be captured and documented. Although many business analysts are not accustomed to ‘flip flopping’ between high level and detailed requirements gathering, this approach can be effective. With stakeholders that have a definitive ‘how’ in mind, a discussion involving detailed requirements is another way of extracting the ‘what’. This approach can also develop an understanding of the way in which the stakeholder prefers (or needs) to work.

Questions that recognize the tool and process the stakeholder is promoting, yet lead to viable detailed requirements gathering include:

When would you use the tool or function?
Are there instances when the tool or process you are using had to be augmented by a manual process? If so, when and what was the manual process?
In a perfect scenario, how would the tool work?
What degree of authority do you have when you use the tool? Could that degree of authority be varied? In what instances would your authority change?
What decisions do you make yourself, what decisions are made by the tool or process, and should the decision making approach vary? If so, how?
What are the exceptions to the process that require approvals or variances to the normal process?

Check the Viability of the Tool or Process

Many inexperienced business analysts either a) accept the ‘how’ as the requirement or b) ignore the information and fail to recognize the value in the ‘how’ input they receive. It is important to keep in mind that, in the mind’s eye of the stakeholder, the ‘tool’ they are proposing is their understanding of a requirement. Proper, balanced and open minded investigation on the part of the analyst is appropriate to understand the stakeholder’s requirement. A great deal can be learned from this investigation, including:

Verifying if there is a tool or similar process that is already available within the organization
Discovering functionality that might be beneficial with other stakeholders or on other projects
Developing a greater understanding of the process(es) the stakeholder is expecting to utilize
Understanding if cross functional relationships between processes or tools exist that might increase organizational efficiency

Care should be taken when investigating these tools or processes however. Common items that should be noted and probably avoided when moving to the solution stage of the project lifecycle are:

Stakeholder enthusiasm due to familiarity with a tool. Other tools might be as good or better and not known to the stakeholder
Influence from marketing. Effective marketing of a product, tool or service can make it appear there are few or no other choices in the marketplace. Careful scrutiny of these stakeholder requests should be applied
Holding on to the current state. Many ‘requirements’ come from an unexpressed desire to minimize change in the stakeholders approach to work. This is not always prudent.

Requirements gathering is a fine art. Successful requirements gathering is best performed by taking full advantage of all the input received from stakeholders. Sorting the ‘how’ from the ‘what’ and investigating appropriately is an important means of validating the expressed requirements, yet staying true to the business analysis objectives.

Don’t forget to leave your comments below.

Bob McGannon is a Founder and Principal of MINDAVATION; a company providing program and project management training and consulting, leadership workshops, keynotes and project coaching worldwide.

The Lexicon of Solutions – Down with the Customer

Written by Steve Blais on March 13, 2012. Posted in Articles.

Well, no not really. Not the customer him or herself, although I’m sure there have been many times when that phrase was uttered in frustration within the comfy confines of the war room. No, I’m talking about the label “customer” that we might want to consider eliminating as it refers to the internal organization people we in IT work with.

Back in the day (I won’t get into exactly when in modern history the phrase “back in the day” refers to), the customer was the one who paid for the software development regardless of whether the customer was involved in what was requested. The “customer” was clearly distinguished from the sponsor, or the users, or the other stakeholders. After all, the definition of a customer is “a person who purchases goods or services from another.” (Note that a colloquial meaning of customer is “a person one has to deal with: a tough customer.” This may more accurately reflect some people’s concept of customer.)

Nowadays the customer refers to anyone who has a request, and/or the primary point of contact, and/or people who use the system, and/or just about anyone in the business community who is involved with the project. We’ve probably all worked with projects that have had several “customers,” most of whom better fit the colloquial definition above. Some IT departments tend to reference anyone in the business as their “customer.” And this is OK since from some perspectives everyone requiring services from IT, whether it be resetting passwords or developing a brand new accounts payable system, meets the colloquial criteria that defines a customer.

Back in the day (same timeframe), no one outside the organization, certainly none of the organization’s customers, saw the results of IT projects. This meant that confusion about the customer was minimal. IT’s customers were internal and those customers provided a barrier between IT and the “real” customers of the organization.

However, today, since a much greater percentage of our systems are aimed externally, the term “customer” brings about confusion. Suppose we have a project that creates a new portal to increase our online sales. Our “customer” is marketing who is defining the content, functionality and appearance of the portal, but we are creating the portal for existing and potential customers of the organization. You see the issue. Which customer has precedence? Are we satisfying the internal “customer” or the external “customer”? (Of course one would assume that by satisfying the internal customer we automatically satisfy the external customer. But then, ignoring the cases where that is not true, why have two “customers”? Why not have everyone focus on the external?)

So I’m thinking that it is time we retired the term “customer” from our IT vocabulary at least as it refers to someone in the business and reserve it specifically for those to whom the organization provides goods and services.

In essence, there are four reasons to stop using the term “customer”:

“Customer” is ambiguous. To some in IT, the customer is the person in the business who has the problem they are solving while to others that is an SME. To some the customer is the one who pays the bills and everyone else is a user. Even within a single company the meaning can change project to project and person to person. The term can also get personal and possessive when business analysts and others refer to “my customer.” (At times I wonder about the connotation of that possession. Does it mean the same as “my client,” or perhaps “my spouse” or maybe “my pet dog, Jackson.”) And then you get into conflicts between or among customers for various projects.
“Customer” is no longer truly applicable. At one time we could call the business person with the problem a customer and there would be no confusion with the organization’s customers. We simply did not do systems that involved people outside the company. Those customers, the ones who bought our products and used our services, were a distance away from the accounts receivable, and inventory control and accounting systems we were creating and maintaining.

Nowadays, most of our systems are externally visible to the real organization’s customer. It is probably time to start focusing on the organization’s customers. We all serve the same customer: the person who buys our products and services and keeps the organization alive.

The term continues the chasm between IT and business. Customers are always on the other side of the counter, usually separated by money from the person waiting on them. It is hard to imagine full collaboration with a customer (the kind of collaboration we would like to have) who is paying the bills and has the power to pull the plug. Moreover, the term perpetuates the barrier between IT and the organization’s real customers by continuing the belief that the people we have to satisfy are those within the organization as opposed to those who are supplying the revenue to keep the organization going. Focusing only on one “customer” means that the business and IT can forge a collaborative relationship to enhance the experience of the organization’s customers.
Customers can go elsewhere and buy their desired goods and services from another source, say a different store or supplier. Internal customers are stuck with us. We have a monopoly for the most part on their IT service needs.

What term to use instead of customer? “Partner” might be applicable since the goal would be to partner with the business person to develop systems that better serve the organization’s customers. But “partner” is already reserved for the organization’s compatriots and supply chain members. Besides, there is an implication of lawyers, which we don’t want to get into.

How about “problem owner”? They are coming to us with a problem and we are helping them solve it. They must stay in the loop and collaborate with us to make sure their problem truly gets solved. Together we can solve the problem. It may be an accurate term, but it sure sounds negative and ominous. There are probably many people who would not want to be labeled a “problem owner” even in a friendly way.

One alternative to “customer” is “product stakeholder.” The “product stakeholder” refers to anyone who has a stake in the result of the project — the product. So anyone making requests of the product might be termed “product stakeholder” rather than customer. We can then separate product stakeholders into those affected by the problem and those impacted by the solution for purposes of elicitation and delivery.

What do we call the upper-level manager who controls the purse strings? How about the old stand-by sponsor? Or if the purse string controller is actively involved in the project, how about the Project or Product Champion? These are older terms that may be worthwhile to recycle for clarification. (Note that the definition of “champion” in days gone by identified the person from the business community who most wanted the product implemented, for whatever positive or personal reason.)

There may be a better appellation for IT “customer” that removes the ambiguity and confusion and describes the collaborative partner we want the business to be. Do you have a suggestion?

Don’t forget to leave your comments below.

Meet Your Business Analysis Influencer

Written by Kupe Kupersmith on March 6, 2012. Posted in Articles. 1 Comment on Meet Your Business Analysis Influencer

My goal in life is to meet everyone in the world. I know that goal is not SMART (specific, realistic, etc.). It is not reaching the goal that is important; it is the effort I go through to try and meet the goal that counts. The goal goes deeper than just “meeting” people. I try to meet everyone I can and establish a relationship. Building strong relationships is a constant, consistent goal of mine. Some grow deeper than others, but I don’t discriminate. I meet and engage with people sometimes without knowing how I will add value to that person or how they will add value to me. For some this is a hard concept to grasp. Some feel so busy and can’t fathom spending time getting to know someone new without knowing why you should get to know them.
We work in a highly collaborative work environment. You don’t have to do everything on your own. If you build strong relationship people are more willing to help you. So if you are too busy to build relationships it is because you are not building relationships.

If you still need some convincing regarding building relationships, here is one big reason you should bother. Build relationships to ensure your message is delivered. This thought popped into my head after seeing an interview with Bono, lead singer of U2. He is a huge advocate to reduce or eliminate the AIDS virus. He has helped raise money and awareness that is dramatically helping the cause. But Bono is not a doctor. He does not work for the Center of Disease Control. He is not trained to do the research, administer tests or provide medicine to patients. What he does do is use his influence to help raise money to support the cause. He uses his influence to convince lawmakers they should allocate funds and resources to support the cause. He delivers the message.

I speak with many BA professionals that get frustrated when they can’t convince their management that they need more focus on the BA practice. I speak with many BA professionals that realize projects are not going well, but are not sure how to get their message to the right person. Sometimes you don’t have the influence necessary to get your message across. Does that mean you should stop? Of course not. You need to detach the message from the delivery of the message. The point is not who delivers the message; the point is that the message gets delivered.

Most likely Bono won’t be stopping by your office anytime soon trying to convince your management that they need to fund your effort to start a Business Analysis Community of Practice. Go out and meet some new people in your company at all levels. Who knows, maybe they’ll be delivering a message for you.

Don’t forget to leave your comments below.