Tag: Learning

5 Key Soft Skills for IT Business Analysts

Written by Brad Egeland on August 27, 2015. Posted in Articles. 1 Comment on 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?

Written by Marcos Ferrer on August 20, 2015. Posted in Articles.

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 🙂

Leadership Lessons – Problems! Glorious Problems!

Written by Peter de Jager on August 17, 2015. Posted in Articles.

C. K. Chesterton penned a quote that I’m especially fond of, “It isn’t that they can’t see the solution. It’s that they can’t see the problem.” It’s one that constantly reminds me that there is always, without fail, an opportunity lying around somewhere. I just need to find a way to find it.

That wasn’t a typo, I meant to type ‘opportunity’, I didn’t forget that this discussion was about ‘problems’. A problem is an opportunity disguised as a thorn in your assumptions. Fix the problem and you’ve moved yourself forward in some manner, large or small.

Because of how I earn my living, I get lots of feedback – more than a person normally gets in other lines of work – file folders filled to overflowing with feedback. The good feedback is great, I love it (great reading when I’m down in the dumps), it’s what keeps me motivated to keep going. But it’s the negative feedback when people point out a problem, that’s the true treasure. Becoming aware of new problems, if we have the motivation to respond to them, is what motivates us not only to keep going but to start going in a new and improved direction. Problems are always doors to something better.

Organizations don’t like problems. We shy away from them; we shoot messengers who bring them to us, we surround ourselves with 800lb gorilla problems no-one dares talk about. We have terms describing cultural approaches to problems – ‘wilful ignorance’ comes to mind- and we have to legislate whistleblower laws to protect those who make problems public. Organizations let problems fester until there is no other option but to lance them like boils.

When I originally wrote this article, Wikileaks announced that in January 2011 it would release documents disclosing a pile of ‘problems’ in a major US bank. Of course, every ‘major’ bank worried that their ‘problems’ would see the light of day and scrambled to either hide these problems more deeply or hopefully fix the problems as soon as possible.

The irony is that whatever organization got their knuckles soundly rapped by Wikileaks… all of the organizations knew of these issues before Wikileaks, before someone else decided to take action. Organizations ignore problems that obviously need fixing until they are forced to act.

Not all problems fall into the category that Wikileaks exposes. Most of the organizational problems that readers of this article might encounter are more mundane, with less serious consequences. More in the line of “our projects are always delivered late; it takes an inordinate amount of time to get things approved; our meetings are a waste of time; our customer service needs improvement etc.”

Even these can become so much a part of the work environment that we become blind to them, hence my fondness of Chesterton’s quote. We are typically blind to most of the problems around us. We need some way to heighten our awareness of the invisible problems so that we can then, if we choose, correct them. If only we could place a bounty on problems, and in so doing, get everyone looking high and low for them!

Many organizations have some type of suggestion program where they always encourage, and then sometimes reward, employees for bringing new ideas, usually in the form of ‘solutions’, to management’s attention. It’s a step in the right direction of constant improvement, but this strategy contains a hidden flaw. It usually, not always, requires that an individual identifies a problem and then comes up with a viable solution – often on their own. That’s a lot of work for someone who’s already overworked in these tough economic times.

Here’s another idea – instead of requiring a solution – how about just identifying a prominent problem? The individual tagging the problem doesn’t have to solve it, just recognize that it’s worthy of solution. The problem is then passed along to a group of people who love solving problems, people like myself who see all problems as a personal challenge, even as an affront to our sense of order in the universe.

The challenge is still the fact that many problems just hide deep inside the “we’ve always done it that way!” bushes. It takes either a new set of eyes to see these opportunities, or a quickly annoying habit of constantly, incessantly, persistently asking “Why?” about every business process until inefficiencies (if they exist) are exposed.

Borrowing a new set of eyes isn’t too difficult to arrange. Just make it part of the organizational culture to have people from one department work in other departments for short periods of time and report back what they see. The hurdle is for everyone to grasp that the observations, while they will sound like criticisms, are intended – from the very outset – as a way to get better at whatever it is we do for a living.

As to the Why? Why? Why? Why? Why strategy? That requires someone with a peculiar personality. They must have both an analytical mind and a very very good sense of humour. The Why? Why? Why? Why? Why approach – especially about things that everyone takes for granted, takes some getting used to – a sense of humour can take the edge off just a little bit.

Leadership Lessons – Change in Seven Questions

Written by Peter de Jager on August 4, 2015. Posted in Articles. 1 Comment on Leadership Lessons – Change in Seven Questions

What must we do to bring about a Change initiative as smoothly as possible? Communicate! Communicate! Communicate!

How much, and for how long do we do this? Until we get sick and tired of the sound of our own voice – then we take a deep breath and a drink of water, and we start all over again.

Communication isn’t something that stops and starts; it’s a constant activity before, during and after any Change initiative.

This isn’t exactly news. We sort of get this. Ask any audience to tell you the secret to good Change and they will repeat back “Communicate, Communicate, and Communicate some more!” as if it was forcefully injected into their cerebellum. The problem arises when the questioning becomes a bit more detailed, “What exactly should we communicate?”

The response to that question is usually either a blank stare or the reasonable recitation of the reporter’s standby; Who, What, Where, When, How and Why. Not a bad start. If you’re writing a news article, then these are good solid questions. The Change Management problem requires all of those, and a few others besides. It’s not that the reporter’s questions are a poor tool; it’s just that they don’t address the peculiar psychology of the Change challenge.

For what it’s worth, here’s a carefully selected list of questions specific to Change Management. If we take the time to answer these, then we’ve covered the bulk of the key concerns of those facing the Change we’re contemplating.

1) Why?

This is the winner, the key question; it’s almost the only question worth discussing. If someone asks me to move from one side of the room to the other, or to stop using system ‘X’ instead of system ‘Y’, my response is always the same. “Why?” Understanding why a Change is necessary is the most important question we have about any Change. Without a good answer, we’re reluctant to do anything different.

There are lots of good answers to the “Why?” question. One good one is “Trust”. If I trust you and you ask me to do something, my trust in you might be sufficient to prompt me to Change. If that trust doesn’t exist? Then the reason for Change had better convince me, or I’m not moving from where I am.

2) WIIFM (What’s in it for me?)

The fly in the ointment for many organizations, “It’s not about you!” they cry as they bend over backward to avoid answering this question. Here’s the newsflash, as long as they are concerned about the WIIFM question, they don’t pay attention to any other information. More precisely, until that WIIFM question is answered, they can’t pay attention to anything else.

The best way to think of the WIIFM question is as a nasty, vicious guard dog, blocking the gate to our attention. Until that dog is thrown a bone, no information about the Change, sometimes not even the answers to the “Why?” question, is getting through to our reasoning process.
Even if we honestly have no information about the WIIFM question we must still acknowledge that the question exists and that as soon as we do have more information, we’ll get back to the audience.

3) Monday?

Assume, for the moment, we have returned from our strategic planning weekend with a wondrous, phenomenal vision of the future of our organization. Also assume, for the moment, that our ability to convince everyone that this is indeed the direction in which our organization should move, is up to the task. Assume that we’re silver tongued devils and get everyone on board, on the bus, bought in and generally all fired up. With me so far?

Now they have a question. What do we do differently, specifically and precisely on Monday (or next Friday…or next month… ) to start moving us towards the promised land of milk and ever flowing honey?

It’s a fair question. If we want people to Change, we must describe what they’re going to do differently in terms that everyone can understand. If we can’t, then we go back to the drawing board, our vision is flawed and unattainable.

4) Won’t?

What won’t Change? What will remain the same during this Change?

The problem here is that when we face a Change, all we see are the unknowns, we lose sight of the fact that only one ‘small’ part of our status quo is going to flux. That the rest of our surroundings will likely remain the same.

For example? When the accounting system is going to Change, we’re still going to report to the same boss, earn the same paycheque, receive the same benefits etc. In fact, most of our status quo will remain the same. This works for nearly all Change, the only time everything Changes is when we die, and then? It’s not our problem anymore. In nearly all other cases regardless of the size of the Change, nearly everything else remains the same.

5) Might?

What might go wrong during this Change? And what contingency plans have we put in place to mitigate those risks?

The worst thing we can do when heading into the uncertainty of Change is to insist that nothing can go wrong. That’s not only asking for the Gods to pay attention to us, but it also communicates to those around us that we haven’t really thought this through. Although if we’re looking for a sure-fire way to lose the trust of those who follow us, insisting, “Nothing will go wrong” is a wonderfully effective strategy.

6) Will?

What’s going to hurt?

Change hurts. That’s almost the ‘First Law of Change’. If we’re doing something significantly different, then we’re going to be at the bottom of the learning curve. Even if we pay close attention to training and support and fall back positions, we’re going to make mistakes, production will decline, and we’ll get things wrong. If we pretend that the Change will be painless, that it will be “transparent to the user”, then people will know we’re lying, or at least overly optimistic.

7) Signposts?

Change doesn’t always happen quickly, sometimes it’s slow, almost glacial in nature – we need some way of measuring our progress towards a goal. Without feedback we lose both the motivation and the will to make sacrifices to move forward. The question on the table is, “How do we know we’re succeeding in our efforts?”

These aren’t the only questions we need to answer during a Change, but they’re crucial ones and if the answers aren’t forthcoming, neither will the Change. Stick them on the wall in front of you when crafting a Change message and ask, “Am I answering these? If not? Why Not?”

Leadership Lessons – When Were you Last Engaged?

Written by Peter de Jager on July 31, 2015. Posted in Articles.

No. That isn’t a question about your personal life, it’s a question about your work life. Are you still engaged? Or has the passion for your work worn off? More to the point? Are our staff still engaged? Do they look forward to arriving at the office, or are they regularly having to buy new alarm clocks because the old ones don’t hold up to the Monday morning mauling to shut them up?

The issue of ’employee engagement’ has become a bit of a trend lately. Head to Google Trends (www.google.com/trends) and type in ‘Employee Engagement’ for a visual representation of that trend based on Google searches. (Compare it to how my specialty of ‘Change Management’ is trending. Oops. Do I need to change my topic?)

The first thing we need to do is define what we’re talking about. What is ‘Employee Engagement’ and then, why should we care about it.

Here’s a definition I use that’s in synch with what I’ve seen as common usage;
“ an employee who is engaged with their job feels a certain amount of ownership in the outcome of their actions, they care about their work, they show initiative when something needs doing, rather than waiting for someone to point them in the right direction”.

Why is it important? Consider yours truly, the writer of this column as an absurd example. I’m a one man company. I must be engaged in what I do, not necessarily all of what I do, but at the very least with the core of what I do, otherwise there are ugly consequences.

I could not care less about ‘accounting’, yet it must be done – so I outsource that administrivia, and several others, to someone else. Problem solved.
But, the core of what I do is ‘take the stage’. The instant that becomes a chore, something I do on autopilot because I have to? Then I am on the fast path to being an ex-speaker.

In a typical office, the consequences of lack of engagement are similar, but they are easier to hide, or at least to ignore. A single unengaged employee out of a staff of 5 or 10 might be regarded as not much of a problem, but if 50% of staff are unengaged, then productivity and quality begin a precipitous drop.
If all of our staff are disengaged from what they do, then who owns all that which needs doing? Who cares about the deliverable? Who takes the initiative? If ownership, caring, and initiative is all falling to a handful or even a single individual? Then we have a serious problem. Especially when increased ownership, caring and initiative without recognition and/or reward is a very good reason to stop caring… anyone for a good game of domino effects?

When employees become disengaged, then even day-to-day operations require conscious effort to drive them forward, an effort that might be better used thinking about tomorrow.
So why do we disengage? Here are five possible reasons – there are others.

Not enough feedback.

We’re simple creatures. We like to know how we’re doing. Without feedback? We have no clue if we’re going in the right direction. Feedback is food that feeds our motivation.

Lack of opportunity to grow

We also don’t like standing in the same place, at the very least most of us find that boring. Even if there are no new positions to move into, are there at least new things we could be doing?

Lack of recognition

This boils down to a simple question? Do you care that I care? Not everyone is ‘self-motivated’, many us, make that nearly all of us, appreciate being appreciated.

Here’s a challenge. I dare you to do this. One Friday afternoon. Order in a few pizzas, some cans of pop, some dessert. Call everyone into your office and tell them, “I know you’ve all been working hard. I just wanted to say. “Thanks!” You don’t have to say anything else. Just ‘Thanks!’ This works even better if you’ve never done such a wild and crazy thing, especially if your organization has banned office celebrations. (This must be the case, because office parties have become a rare beastie.)

Let me know what happened. My e-mail is at the end of this collection of articles.

Lack of Trust

I don’t think anyone needs to spend much time elaborating on this. Nobody cares to put extra effort into an organization they no longer Trust. On a scale of 1-10… how much Trust is there in your organization?

Stress-Burnout.

Things are tough all over and getting tougher. If you want to muse something over on your own? Go back to Google Trends and do a search on ‘Recession’…. compare that chart to the one you got when you searched on ‘Employee Engagement’.

Not all of the above are solved easily, some are, others are way beyond our scope and powers. The problem of employee disengagement is a real one. If allowed to grow (or encouraged to grow!) then sooner or later the organization is coasting (grinding?) to a halt. The first step in solving it is accepting that it is a problem… and with that? Here’s the closer;

Here’s a personal question.. What do you do on autopilot at work? What have you disengaged from? What have your staff disengaged from? What’s that costing your organization? Do you know? Do you care? (Careful with that last answer… it’s a doozie)