Skip to main content

Tag: Competencies

A Journey of Discovery – I Know What I Want

Throughout my career, I’ve experienced a number of situations where issues are not always apparent at first glance. Many times, superficial observations belie a fall sense of calm, while, in some cases, problems are known to exist, but still overlooked. These are some of the starting points of requirements analysis process:

  1. I know what I want.
  2. I know what the problem is.
  3. I know the problem and the solution.
  4. I do not know what I want.
  5. I know there’s a problem.
  6. I know there’s a problem, but I am not sure what it is.

Knowing exactly where your stakeholders stand is, in my opinion, the starting point towards eliciting and understanding requirements.

Even when the stakeholders claim that ‘I know what I want,’ to assume that these so-called ‘needs’ are valid and known would be naïve. A Business Analyst should be aware that the needs expressed by the stakeholders are not always exhaustive, valid, and will not necessarily lead to the right outcome.

What Happens When A Stakeholder is the “Know What I want” Type

A few years ago, I had an opportunity to work on a project where the client was the ‘I know what I want’ type. They were quite sure that all they needed was to modernize their IT platform, retire legacies, and introduce new capabilities to improve process efficiencies. Quite predictably, they insisted on building the project with the focus on these ideas. The entire requirements analysis were based on the idea that ‘I want to modernize the technologies I use.’ The analysis of the requirements and implementation of the solutions, from end to end, cost the company close to $50 million.

We delivered state-of-the-art solutions and implemented them successfully. However, when the company ran a benefits tracking activity to see how the modifications fared, it was found out, quite surprisingly, that the benefits were not fully realized. As for the improvements in efficiencies, there wasn’t much to speak about, either.

Related Article: Process Approach to Requirements Gathering

As analysts, we were again asked to assess this situation. This time, however, the stakeholder’s stance was ‘I am lost.’ The first instance of the project implementation was thoroughly based on the stakeholder’s suggestions, and it was assumed that the ‘requirements’ as the stakeholders saw them, were the only ones and the correct ones. In the second instance, however, we began from scratch to make the voyage from the unknown to the known. What we found had little to do with the needs that the stakeholder had insisted upon being delivered in the first instance:

  1. The organization had deep-rooted cultural problems like:
    1. Dissatisfaction among staff
    2. Rifts among senior management
    3. Power struggle across the organization
  2. Relations between business functions were either absent or dysfunctional.
  3. Communication across multiple channels was broken and was often ineffective and insufficient.

As it turned out, modernization was indeed necessary, because the organization was carrying the risk of working with outdated legacy systems. The processes, too, were overdue for a review and possible re-engineering. However, these weren’t the only requirements. The organizational and cultural issues needed to be resolved before handling the technical issues. The root causes of inefficiencies were fundamentally cultural. The unbiased process of requirements analysis unveils the true problem.

What Was Learned

Never take for granted what stakeholders assume to be requirements. What the business user expresses is just one piece of the puzzle. There are unknowns that need to be discovered and put in front of the stakeholders.

Unfortunately, there is no single formula that would apply to every situation. However, there are requirements analysis principals that can be used to bring objectivity to the process.

  1. Do not mistake what your stakeholders are telling you for the absolute truth. The truth has multiple versions. A Business Analyst has to discover every version of the truth to reach the absolute truth.
  2. Be skeptical. Go above and beyond expectations, do your homework, investigate, and gather information in a structured manner to determine the accuracy of the stakeholder’s perceived requirements
  3. Never leave any room for guesswork. Rely only on facts and evidence.
  4. Data is of utmost importance. Try to collect information from every plausible source.
  5. To counter biases, use multiple sources of information.
  6. Never reason from insufficient data.
  7. Every situation is different. Use your intuition.

We are called ‘analysts’ for a reason! When Sherlock Holmes walks into a crime scene, he does not solely rely on the questions ‘What has happened?’ He goes above and beyond. A Business Analyst always needs to know that the ‘needs’ expressed by the stakeholders are not always exhaustive, valid, and they will not necessarily lead to the right outcome.

How to Stop the Long-Winded: With Class

I was on a call the other day with people from around the world. Usually, these calls are awesome. The fact that I get to work with people from Australia, New Zealand, Canada, Italy, and beyond is amazing to me. Life is not always awesome, though.

This last call was not fun. Apparently I was one of those long-winded people. A reaction from the meeting chair ended up hurting my feelings. I felt shut down. I stopped sharing my ideas. Some of you may be saying, “good, you and the other long-winded people need to keep quiet for a while.” Maybe you have a point. The short term goal of shutting me up moved our agenda along. The long-term impact was I stopped providing ideas in the meeting. That is not a good thing.

What happened was we were discussing a topic and asked to provide questions if we had one. I had a question, so I started in. My question was not yet well formed. I started talking trying to formulate the question. I am an extrovert, so I talk to think. At some point during my dissertation, the chair of the meeting piped in “Kupe, Kupe, Kupe!” I don’t know maybe there were 10 Kupes before he got my attention. I was trying to talk fast so I could get to my question. I was not rambling for the sake of rambling, I promise! I finally stopped and he said, “Kupe, you are going on and on, do you have a question? WHAT is your question?” That’s when my feeling got hurt, that’s when I stopped talking out loud and said “whatever” in my internal voice. I think I even threw up the “Whatever” sign. You know, making a “W” with your 2 hands. We didn’t have video, he couldn’t see me. I’m 44, but I can still act like a child! I ended up asking a question. But you could hear a new tone in my voice. I became disengaged. For the rest of the meeting, I shut down.

I know some of you are saying to yourselves, “jeez Kupe, man up. We need to have thicker skin than that.” Believe me, I know. I do have pretty thick skin. My kids say that they love that I don’t care what others think. The context there is I do goofy things trying to embarrass them. Needless to say, I am very comfortable with who I am, my thoughts and beliefs and don’t get my feelings hurt often.

The point is, even people with the thickest skin can get their feelings hurt or get defensive. You need to make sure you are facilitating meetings where people feel they have input. Where they feel comfortable sharing their thoughts. The goal is buy-in. I talk about this more in a post titled “Your goal is not to shut people down just for the sake of sticking to an agenda.”

Related Article: It’s Time to View Your Role as a Communication Expert

There is a real problem here. You need to make people feel comfortable sharing their thoughts. You also only have so much time. The long-winded are a challenge. The ones that don’t speak are a challenge too, but they don’t take up any time. What are you to do?

In a face-to-face situation, peer pressure comes into play. When you have a long-winded person going on and on, people start shifting in their chairs, looking at their phones, etc. People start to see their team’s reactions and may adjust. In a remote session that peer pressure is gone. Many people are on mute and you don’t see anyone. It actually makes the long-winded even longer-winded because they are not getting feedback. In my case, I was not sure people on the call were understanding where I was going with my thoughts, so I kept going. That is until the rude “KUPE” to the tenth power came from the chair.

Some would say, it’s all about relationships. If you have a good relationship with the people you work with, then you can be less politically correct. I am a huge believer in relationships and promote it all the time. Even if you have great relationships with others, you need to be careful. I have a great relationship with the chair of this meeting. I have a really good relationship with the others on the call. In my situation, the chair did need to stop me. In hindsight, I was really long-winded. In many of your meetings there may be a person or two that needs to be stopped.

Is there a better way than coming across as abrasive? Is there a way to do this without hurting others feelings? More importantly, is there a way that does not stop engagement from others?

My tip is don’t leave it up to the person running the meeting. That puts all of the pressure on one person to keep a meeting running smoothly. Eventually, that person snaps and comes out with a statement that can shut down the talker. It needs to be clear in the meeting that everyone has the right/ability to get the long-winded to wrap up. Come up with a code word or sound. When that sound is made or word spoken the talker needs to wrap it up. This can be used for face-to-face meetings too, although it is critical for remote meetings. Make sure everyone knows it is not personal. It’s about making meetings more efficient.

Don Palmer from The Dallas Federal Reserve Bank recently told me about an analogy he used to show his executives the effect of showing displeasure when project managers present project status reports that included issues. He refers to it as hitting the goalie. Don explained there is a rule in hockey that prohibits players from hitting the opposing team’s goalie. This originates from not having many people want to play goalie. Kids want to play offensive, goal-scoring positions. So, there were not a lot of goalies out there from which to choose. If a team hit the goalie and the goalie was injured, teams would have to go to a backup goalie. Then if the backup goalie was injured, there was no one else left to play the position. This would completely alter games. In the project status world, Don explained if you badgered the project manager for bringing up issues during status reporting, PMs would begin to present all positive results during the project. Then in the end the projects would fail because they were hiding the truth all along to avoid the public badgering. This behavior did not allow executives to make decisions along the way to get the projects back on track. Don explained that badgering a PM is like hitting the goalie and pushed to have a “no hitting the goalie” rule. Now in status meetings if one executive is badgering a PM, another executive will say, “you are hitting the goalie.” I think this is brilliant. This is now a term that everyone understands and respects. It also results in PMs sharing the information as it is and not sugar coating the status of their projects.

There is no silver bullet. Feelings will get hurt. Your goal as a leader is to work consistently towards obtaining full participation. The outcome you are looking for is buy-in from the group. You gain buy-in by allowing the team to share their thoughts.

To not hitting the goalie,

Kupe

The 7 Wastes in Your Business – Finding Kaizen Opportunities

As a business, you are either efficient and effective, or you are not. It’s quite likely that there are things in your business environment you’d like to see work more smoothly, more efficiently. There are many reasons for poor processes and less productive business environments ranging from:

  • Lack of clarity on the part of the business leadership and senior management,
  • Performance management system structure and the way people are rewarded,
  • Poorly implemented initiatives, and
  • Business leaders who micro-manage (not letting people under them do their thing and make decisions).

Any one of these can be affecting your process and productivity. One helpful way of looking at process and productivity is in terms of finding Kaizen opportunities. Kaizen refers to a philosophy or practice that focuses on continuous improvement of working practices, personal efficiency, similar ideas. 

When applied to the workplace, Kaizen involves all employees from the CEO to assembly line workers and refers to activities that continually improve all functions. It also applies to processes such as purchasing and logistics, which usually cross organizational boundaries.

Related Article: 7 Candid Questions That Need to be Asked

Generally, Kaizen looks at waste in some key categories with Seven Lean Approaches. These include:

  1. Waste of Motion
  2. Waste of Waiting
  3. Waste in Transportation
  4. Waste in Storage
  5. Waste in Defects
  6. Waste in Processing
  7. Waste in Over Production

There are many examples of where the Kaizen approach can be applied from a staff driven perspective. From the manufacturing line of bottle cap disposal, making toast in the kitchen on a train, the health x-ray requisition approval process, to the location of office supplies storage. All these can be streamlined and standardized.

By improving standardized activities and processes, Kaizen aims to eliminate waste, thereby making your business more productive. And, as the Kaizen approach seeks to improve processes, productivity then is the yardstick by which you can measure your success.

If you can find ways to improve your processes, to become more efficient and effective, you will be more successful in your business.

Question: What work process can you focus on to improve to create better flow and enhance productivity?

5 Key Soft Skills for IT Business Analysts

Business analysts play a critical role in the project management life cycle. Especially when the projects being managed are technical in nature. Success or failure of the project manager and team sometimes relies on the skills this individual brings to the table and the way they can interact both with the technical project team and the project client.

What soft skills does a technical business analyst need to help ensure the success of the project engagement? It depends, of course, on several factors. The needs and experience levels of the project manager and technical team members. The needs of other key project stakeholders. And of course, the needs and – most likely – the technical skill level, understanding and competence of the project customer with regards to the solution that is to be delivered. Often the business analyst is that final interpretation and documentation point of those critical project requirements. The business analyst should be at the middle of the definition of those key requirements.

Let’s examine what I consider to be the top 5 key soft skills of IT business analysts when working on technical project solutions with the project team and customer.

Negotiation. The art of negotiation. It’s not an easy one and it’s not for everyone. It takes confidence, connections, proactive thinking, and a solid understanding of the other party’s needs. That’s where the technical business analyst needs to thrive. As they are continually working through the technical side of the project with the project client – acting as a constant interface to the client and as a liaison to and interpreter for the tech lead and development team as well as a administrative support role for the project manager (yes, that is three hats on most projects), they have the best understanding of client needs vs. delivery team capabilities. That’s where negotiation comes in. They need to be able to see where new business might be negotiated with the project client as well as where project changes may need to be negotiated to combat scheduling conflicts.

Meeting management. As with any professional position, the business analyst will be well served to be a good meeting manager. Besides participating on regular project status meetings led by the project manager, the BA will be conducting many project meetings throughout the project engagement. These include meetings to discuss and define design and planning issues as well as functional design and project requirements with the client. They will also be conducting many team meetings with the developers as they transfer and translate ongoing customer needs and requests. Efficient and effective project meeting management will keep attendees coming and keep meetings productive.

Conflict resolution. Hopefully this skill isn’t needed often, but that always depends on the team and the project – and possibly the customer. The complexity of work can bring conflicts on the team. The business analyst who can work cohesively with the project team can help wade through the conflicts and help project team members realize they are working on a common project goal and keep them focused on that.

Listening skills. Listening skills are critical for the BA. Both in terms of dealing with the wants, needs and requests of the project client and listening to the concerns and needs of the technical project team members. Proper understanding of client processes and needs is critical to proper documentation and understanding of those always important detailed project requirements – and the BA’s listening skills are at the heart of that understanding. Requirements are the lifeblood of the project – poorly documented or understood project requirements have doomed many a project. Success is hard enough as it is – listening skills are critical for the BA to avoid this potential pitfall.

Communication. Finally, communication. I realize that listening is part of communication, but here I’m talking about the other side. The business analyst needs to be a master at interpreting what they hear and accurately relaying it to those with whom they are connecting. The BA is often a go-between on many aspects of the project as already discussed. If any of that critical information falls between the cracks, it can lead to nightmares, missed deadlines, re-work, and budgetary issues. And, likely, ultimately project failure and delivery of a solution that doesn’t work for the client’s end users.

One other key communication point is how the business analyst communicates with the project customer. Communication throughout the engagement can determine the customer’s ongoing confidence in and satisfaction with the delivery team’s work and ability to deliver on the project. A BA who is only working closely with the project team and project manager may cause concern with the project client. A technical BA who is “on it” and shows great understanding of the client’s needs, concerns, and requirements keeps the project customer’s confidence high, their satisfaction at a desirable level, and their readiness to continue to do business on other work with the delivery organization likely. In reality they are an extremely critical interactive position with the project customer and the area of communication is of utmost importance. I always say it is Job #1 for the project manager. Likewise, I believe the same of the business analyst. It is an absolutely must-have soft skill for a BA on projects of any complexity.

Summary / call for feedback

I’m not saying a project can’t survive without a skilled business analyst. I am saying that I would not want to be leading a project of significant size and complexity without an experienced technically skilled and knowledgeable business analyst working alongside me helping me lead the project and engage the client.

How about our readers? What are your thoughts on the soft skills of the business analyst? Does this list work for you? What other items would you add to it that you see as key tools the business analyst needs to bring to the technical projects they are working on with the project team? What role are business analysts expected to play on your project management teams? How much interaction with the project customer and how much technical acumen is expected of this position?

Dear 007, Am I Finished?

Sometimes I get questions from BAs and PMs, and when I can’t answer them, I pass them on to CBAP 007. With an IIBA license to drill, no business analysis issue is too big or too small for this experienced professional. Here is one from July 2015:

Dear 007:

My project manager tells me to “finish the requirements”, but no matter what I turn in, she says it is not finished. When I ask what else she wants, she says she wants everything. When I suggest that everything costs infinity, she says I have an attitude.

She is right (about my attitude). What should I do to “finish” the requirements?

Signed,

More Finished Than She Thinks

Dear More Finished Than She Thinks:

I assume that you, like most BAs, understand that requirements are rarely “finished” in the sense of being complete to the satisfaction of every stakeholder.

The most complete requirements ever written for a cell phone did not include the contingency factors inherent in a pair of boot-cut Calvin jeans worn two sizes too small and stuffed with an understructures oversize phone chassis.

Don’t even ask about rubber gasket temperature requirements for Space Shuttle boosters – they WERE included as requirements, but ignored by project management in spite of their completeness (“But Reagan is sending a teacher into space and giving a big speech – it’s a deadline!”). Deadline, indeed, but not a requirement.

SO, I assume that the words “finished” and “everything” means something different to your PM than they do to you. Let’s try a few definitions – if one of these fits you may realize what to do.

Does finished mean? :

  • I (the BA) can’t tell that anything is missing
  • She (the PM) can’t tell that anything is missing
  • We (the other Business Stakeholders) can’t tell that anything is missing
  • They (the Implementation SMES) can’t tell that anything is missing
  • It (the solution as implemented) can’t tell that anything is missing (everything” works)
  • Notice that none of these definitions involve anyone saying “I can see that X, Y, Z are missing” which would be more helpful.

Now for a definition that helps. Completeness is best defined at a GIVEN LEVEL OF DESCRIPTION. In the BA profession, we look to BABOK for the correct categories and levels of description. In this case, requirements have the following levels of description:

  • Business Requirements (High-level statements of key business needs, approaches and strategically justified capabilities that must be met regardless of stakeholder wants)
  • Requirements[Stated] (stakeholder wants and concerns not necessarily analyzed)
  • Solution Requirements (functional, work to be done)
  • Solution Requirements (non-functional, qualities of any solution to be implemented)
  • Transition Requirements (temporary needs and efforts, until “full” implementation)

“Our business has a need to deliver legal documents to its customers every day on less than one hour’s notice,” might be a COMPLETE business requirement. Make sure to comb your requirements and collect all the “high-level” actual business needs (as opposed to personal preferences, see below). You will discover some “low-level” requirements that imply high-level requirements, and vice versa. Separate them (analysis) into their own groups, rewrite them to fit their level and category. THEN IT BECOMES EASIER TO SEE WHAT IS MISSING AT THE HIGH-LEVEL. This is where MOST IT project mistakes get made and is the most important to get complete.

“I want a car so I can make those deliveries for the business” is COMPLETE in the sense of being a stakeholder requirement [stated, not analyzed]. Make sure that you comb your “requirements” and collect all the “not-really requirement” statements and put them into an “elicitation” document for further analysis. The “requirements” are not finished, because they are not analyzed, but COMPLETE in the sense of being everything the stakeholders said).

“Bicycle couriers average 12 miles an hour in city deliveries, vs. 7 miles an hour for cars. Feasibility ANALYSIS suggests outsourcing delivery to couriers (or we can buy the stakeholder a bicycle instead of a car).” This might be a COMPLETE solution requirement (functional) – DELIVER LEGAL DOCUMENTS. Collect all the actual work functions implied in all your requirements, and list them in one place. It becomes easier to see what is missing (e.g., PREPARE PACKAGE WITH CORRECT DELIVERY INFO, and CONFIRM TIMELY DELIVERY WITH CUSTOMER). To be complete, list all the IMPORTANT business processes, and let the less important arise as needed (e.g., we need to ASSIGN DELIVERY TO COURIER SERVICE as a critical business function, but we can decide to implement this assignment via text message as we negotiate with the courier service. Is the requirement complete, if this “text message” spec is unresolved? Not really (see the beginning), but it is LOW risk and focus belongs on other higher level issues (e.g., how to MEASURE delivery performance objectively, once assignments are made).

“Delivery in less than on hour” was already stated as a business requirement – it is (for this simple example) the COMPLETE solution non-functional requirement – a service level guarantee. Can you think of any functional requirements that would help guarantee that service level? Put those above – group like with like.

Finally, transition requirements. Who has to be informed, trained, won over? Do we have to convert data from the secretary’s Rolodex to a label print system for the courier packages? What is the implementation plan (oh project manager mine). The project plan (think about it) is largely “transition requirements”, and should lump upon the head of your PM as much as on you.

IN short, if you use BABOK categories, you avoid level mixing, confusion, and you gain the ability to see what else belongs at that level. If you do it right, you will perceive redundancies between levels. This is normal, and shows traceability and shows that requirements are related across levels (that is why it is so easy to mix them up and get confused about how complete they are). An example of a seemingly redundant requirement was “Delivery in less than an hour”. At the business level, it is a service strategy defined by a performance level. At the non-functional level, it drives measurement, verification and other functional requirements. By putting it in both places as appropriate, COHERENCE is achieved, which helps stakeholders in perceiving completeness.

ALWAYS START BY FILLING IN THE HIGH LEVELS TO MAXIMUM COMPLETENESS. IF there is no time to “finish” a lower level, you might not even start it. Don’t spec the detail steps of MANAGE USER PRIVILEGES just because you can – stick with high value high-level critical business processes such as VERIFY TIMELY DELIVERY, and try to “complete” the success scenarios. If you have time, go for the top 3 alternate scenarios. At each step, decide how much you can accomplish and put BABOK boundaries on the work so the completeness can show.

THEN when your manager says to “finish” the screen color requirement, you know which requirement and what is missing.

Je suis finis – et vous?

Please comment below – let me know what you DIDN’t get, so I can finish it 🙂