Skip to main content

Tag: Business Analysis

Business Analysts Lead from the Center

wick Aug13If I asked you to draw a picture of “leadership” what image would appear?

One image you might conjure is an org chart—the typical two dimensional, somewhat triangle-shaped hierarchy. “Leadership” is somewhere near the top.

Many BAs buy into this pyramid leadership scheme. BAs assume they are not leaders because they are near the bottom of the org chart or somewhere off to the side in a special “we-aren’t-sure-where-this-person-fits” box.

But all BAs, regardless of their level of experience, are perfectly positioned to be leaders—not leaders from the top—leaders from the center.

What does it mean to lead from the center?

Most BAs don’t operate at the top of an org chart, they operate as a hub. They sit in the center of multiple resources and pass information back and forth across the spokes.

A BA’s spokes tend to reach many teams and many levels of leadership. BAs often have a unique perspective because they see a 3D cross-section of their organization—they see the “how” and “why” that people looking down from the top of the org chart cannot see.

How do you demonstrate leadership from the center? The spokes are the key! The spokes connect BAs to their resources. They represent shared information and support the relationships between BAs and their stakeholders.

To be an effective hub, a.k.a. an effective leader, BAs need to know how to engage their stakeholders—how to get and keep their attention. 

Do you have strong engagement with your stakeholders? How can you tell if your stakeholders are engaged? How can you improve stakeholder engagement? 

Symptoms of Weak Stakeholder Engagement 

Weak stakeholder engagement stalls your career, minimizes trust, wastes money, and hinders projects and processes. Here are a few symptoms:

  • Strongly conflicting requirements between stakeholders.
  • Stakeholders are silent, roll their eyes, sigh or multi-task during meetings.
  • Stakeholders do not contribute to the project. They don’t return phone calls, do not reply to emails, do not review project documents, do not provide resources, etc.
  • Stakeholders show up late for meetings, leave meetings early or skip meetings.
  • Disparate groups do not understand other stakeholders needs and benefits from the project.
  • Progress is slow.
  • Discussions loop in circles.
  • Decisions are difficult to obtain.

Signs of Strong Stakeholder Engagement

Strong stakeholder engagement builds trust and maximizes the value of a project or process. Here are a few signs of strong engagement:

  • Stakeholders have a shared vision and can communicate the vision to their team/s.
  • Stakeholders understand their connection to each other.
  • Stakeholders trust each other and the BA.
  • Stakeholders enthusiastically participate in meetings.
  • Stakeholders make themselves and their resources available to the BA as needed.
  • Questions, discussion and meaningful debates.
  • Proactive, 2-way communication

4 Ways to Improve Stakeholder Engagement and Build BA Leadership Skills

  1. Analyze your stakeholders. Try to determine what motivates your stakeholder. What is their definition of success? Think about the project/process/problem and ask WIIFM (What’s in it for me?) from each stakeholder’s perspective. Truly empathize with each stakeholder to understand what they will gain or want they want to gain.
  2. Observe you stakeholders. Take the time to observe stakeholder behavior and interactions. Observe how they react to you. Do they share information with you openly? Do they seem bored or annoyed? When you talk about specific projects or processes do they seem excited or do they frown and roll their eyes? Also, observe how stakeholders interact with each other. Who comes into meetings together? Who eats lunch together? Which stakeholders seem to annoy each other or question each other?
  3. Boost your facilitation skills. Facilitation skills are critical for leadership and relationship building. Your meetings should be interactive, visual and physical so that all stakeholders contribute in a meaningful way. You should be able to engage SMEs and executives to generate creative ideas to solve complex problems.
  4. Boost your communication skills. Be prepared to discuss your project/process/problem with people from all parts of the org chart. What level of detail does your SME want? Your manger? Your CIO? Do you communicate visually? Can you spontaneously illustrate a process, an idea or an issue on white board during a meeting?

All BAs are Leaders

From the beginner BA to the director of the BACoE, BAs bring people and ideas together. They align organizations and pave the way for value-driven change. They bring a 3rd dimension to the org chart with their unique perspective across organizations and leadership levels. 

Maximize your influence and leadership potential by building strong relationships with your stakeholders. Connect with them. Understand their priorities and motivations. 

Be the hub. Mind your spokes. 

How do you demonstrate leadership in your organization? How do you keep stakeholders engaged?

Don’t forget to leave your comments below.

It’s the End of the Business Analysis World as we Know it? Part 5

FEATUREJuly30thBeing the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile

Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013

Chapter 5:  Wherein the business analysts encounter the Scrum Master, Scott discloses his concerns about business analysts and Verna summons

The organization was quite dynamic.  Meetings were held in the hallways and corridors of the vast headquarters on a more frequent basis than in the meeting rooms. This might be considered by some to be an agile practice since the meetings were held not only standing up, but moving along, which meant that the meeting had to be completed by the time one or more participants got to their destination or their ways parted.

Thus it was that Brian and Ann attended meetings that morning.  Brian ran into Ann as he came out of the elevators after arriving at work, his black Swiss Army backpack slung over one shoulder and a cup of coffee in his hand.  Ann had had an earlier morning meeting with Belice Despacio who was assistant to the CFO. Ann was presenting the information she had amassed on the efficacy of buy versus build decisions on the Backbone project. She considered it her ‘kiss-off’ project for the organization.

“I don’t know about you, but I’ve been avoiding people like the plague these past couple of days trying to get things in order.” Brian greeted her.

“Me, too. You mean you haven’t seen Ken or Scott?”

“Not yet.  But it looks like the waiting is over.”  Ken came down the hall toward them.

“Shall we make a break for it?  If we run in different directions one of us will get away.” Suggested Ann.

“It’s all right, kid.” Said Brian doing his best Bogie imitation. “They’d find us wherever we went. We gotta stay here and face the music.”

“It isn’t even High Noon yet.”

“Well,” said Ken with a vacuous smile. “It’s the Last Brigade, or maybe I should say Lost Brigade?  I see that you have managed to infiltrate your business analysts into the projects anyway.”

“Nope,” said Brian continuing to walk. “There are no business analysts on the Backbone project. There are new developers who used to be business analysts and there are product owners who used to be business analysts.”

“And there are impact analysts working with the product owners,” added Ann.

“Why do I feel this is a trick?  Once a business analyst always a business analyst.”

“First of all,” said Brian, putting his backpack down and facing Ken. “There is no such thing as ‘once a business analyst’. None of us were born business analysts nor did we plan to be business analysts throughout school. We all gravitated or were inserted into the position and the profession. Most of us came from other disciplines like systems analysis or engineering for which we were initially trained. Both Ann and I have done some turns as project manager. Many of us came out of school as engineers or with IT degrees. So it’s not that difficult to move back to one of our former positions. Besides, you have a lot of former Java and C++ programmers working on your dot-net and C# programming projects.  Do we say the same thing about them?  ‘Once a Java programmer always a Java programmer’?”

Ken ignored Brian and walked away.  “Good luck in your new jobs elsewhere in the organization, Allen.  But remember, the New Order of Agile is taking over.  Two more divisions have decided to also go with agile. There won’t be any place to go soon.”

As Ken walked down the hall and Brian shouldered his backpack, Ann mused, “We were avoiding that?  I wonder what he really wanted to see us about.”

“I guess I distracted him.”

“O, well, looks like today is the day.  Here comes Scott, and he looks like he knows why he wants to see us.”

Scott looked troubled.  He came straight at them like a shark after its prey. Brian could hear the Jaws theme playing in the background.

“I’m glad I found you,” breathed Scott. “Can we go someplace to talk,” he said conspiratorially looking over both shoulders. “How about a cup of coffee.”  Brian stared at the cup of coffee in his hand and then at Ann and said, “Sure.  Why not? I’m not on the clock yet anyway.”

After they got settled in a corner table of the cafeteria with their coffees, Scott leaned forward, put his glasses on the table and pushed back his longish black hair. “What do you know about Scrum Masters?”

“It’s a Zen discipline arising from the sport of Rugby in which there is both a ball and not a ball and the less you try to score the more goals you make,” offered Brian.

“My, we are quick this morning, aren’t we, and only on the first cup of coffee,” commented Ann. “We know what a Scrum Master is, Scott. What’s your problem?”

“We drafted our Scrum Masters from our developer teams. We let them volunteer because we didn’t want to impose any management selection of roles on them. These are, after all, self-organizing teams.” He paused for acknowledgment, and receiving none, continued. “Those who said they would like to be Scrum Masters were sent to Certified Scrum Master classes at our expense. So we got a number of CSMs to fill the role for the Scrum teams.  Of course it was difficult. Most of the developers did not want to give up their coding to run interference for the teams. Many also felt that the Scrum Master had to indulge in politics and wanted no part of that. “

“I’m not sure I understand,” interrupted Ann. “What ‘politics’ are they concerned about?”

“One of the primary duties of the Scrum Master is ‘removing impediments to the development team’s progress’ * and another is working with the organization to promote and promulgate Scrum: ‘The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t’ And these things mean that you have to deal with the rest of the organization and that means politics.”

“Isn’t that what you and Ken are doing?” asked Brian.

“Yes. And we take seriously those edicts. And we are ‘leading and coaching the organization in its Scrum adoption’. But that is beside the point. And the point is that we don’t have enough Scrum Masters, and those we do have are not working as well as they should.”

“Didn’t they go to class and get certified?” Asked Ann.

“Yes. I said that. And the certification is two days of class followed by an exam. And it’s a fairly easy exam, too.”

“You passed it?” asked Brian.  Scott didn’t pick up the sarcasm. He continued: “And they tell you what to do, but there is no real training in how to do it. And, for example, in one of my teams a senior developer is somewhat arrogant and is shredding the new, young product owner. She has left the room in tears as a result of his questions.  And all he says is ‘there is no crying in software development’. And I have no experience in dealing with such things, since I am basically a developer.”

“Once a developer, always a developer”, chided Brian, only for Ann’s benefit as Scott was oblivious.

‘As I recall,” Ann tried to bring the conversation back to the point. “The Scrum Master also “Leads and coaches the organization in its Scrum adoption, causes change that increases the productivity of the Scrum Teams, coaches the development team in self-organization and cross-functionality’ *, and so forth. Those are high expectations for a developer, or anyone for that matter. Was your plan that they should be able to do these things with a two day class?”

“No. In agile it’s about learning. Each of the Scrum Masters would learn how to deal with people and learn how to play their Scrum Master roles.  But they are not learning fast, and some don’t seem to be able to learn, or want to learn. And I’ve had three tell me they don’t want the position anymore. And the others on the team see that happen and they don’t want to step in. And I think we are discovering that learning soft skills is not as easy as learning a new programming language or hardware platform.”

“It seems to me as though the Scrum Master job description was written as an inducement for organizations to bring in experienced, qualified consultants. I recall one of the tenets says the Scrum Master ‘coaches the Development Team in organizational environments in which Scrum is not yet full adopted and understood,’ and ‘Helps employees and stakeholders understand and enact Scrum and empirical product development’. So why don’t you just bring on the consultants?” Asked Brian.

“No can do.  I think we oversold the simplicity of the Scrum concept to Carl and Vince. And they won’t pay for consultants. They say the self-organizing teams should be able to handle it themselves. And they were willing to allow for a ramp-up time and the classes. And they expect that since the developers are able to talk directly to the business now that they should be able to do the Scrum Master roles as well. So, no consultants.”

“Yes,” agreed Brian. “It would seem contradictory to the concept of simplicity to have to bring in a high paid consultant to get things started. But what about the project managers?”

“Ken didn’t want any of them around. He wasn’t sure they could successfully drop their authority around the team. And even if they were able to stop managing and start coaching, the teams would still see them as project managers and that would make them ineffective. And, besides, Carl grabbed all the good project managers and assigned them to other projects in the organization and let the others go.”

Ann sat back and sipped her coffee. “Hmm.  OK. Sounds like a problem. What do you want us to do about it?  Offer suggestions?”

“Actually, I’m looking for advice, and maybe a little help.  One of the aspects of business analysts I have admired is their facilitation skills: they seem to be able to enable discussions and get people involved. And, like you two guys, you seem to be able to get things done when you’re on a project, especially outside the project boundaries, working with other projects and business areas.” Brian and Ann exchanged glances, both with raised eyebrows “And I am thinking that we might be able to co-opt some business analysts into being Scrum Masters. For example, Shelly. Shelly is able to make a meeting work well. I go into a meeting and have no idea why I am there. And even when there is an agenda, all it does is list the attendees and none of us know why we are there. But a meeting with Shelly always goes well. And when any of us walk out of a meeting that she attends we know exactly why we were in the meeting and always feel that we spent our time well. And, she, like, asks questions and gets the attendees to come to conclusions, even when the meeting isn’t hers.  And she seems always to be able to resolve conflict among the attendees if there is any, even among developers, and sometimes even before it starts.  And I’ve seen you two do this as well.”

“Well,” replied Ann.  “That could be arranged. We can send a few of our remaining available business analysts to Scrum Master classes and they can be Scrum Masters for your teams.”  Ann hid her delight at having this solution drop into her lap. 

Brian on the other hand had another question. “Scott, you seemed to be totally against business analysts.  And now you are singing our praises. What gives?”

“I am not singing the praises of all business analysts.  I’ve been in meetings with the users and your typical business analyst. And I’m there in the meeting for technical support and half the time I just sit there and daydream or wish I could open my laptop and do some coding. And the business analyst just sits there and takes notes. And whoever it is says that they are there to get the requirements and then records what the users tell them. Sometimes I have to ask questions when the users ask for something outrageous. And the BA takes everything down, you know?  And it all ends up in the requirements document. And the BA tells us, ‘it’s what the customer wants.’ I mean, we could do that, and we’d spend more time asking questions  And then later we find out that it’s not quite what the customer wanted because the user forgot to mention something or didn’t state it clearly. And the BA complains about the customer changing their mind or never knowing what they want.  And, I mean, we could do it, you know?  And, even if we did the same thing, which I doubt, at least we’d be getting the straight scoop, and getting it earlier. And the business analyst just does not add value to the exchange.  Present company excepted, of course.”

“Of course.” Said both Brian and Ann together.

So it was agreed. Shelly and Juan and a couple of others would start work as Scrum Masters applying their business analyst facilitation skills to ‘facilitating Scrum events as requested or needed’ *. They could use their influence, negotiation, mediation, and conflict resolution skills to support the teams and the projects as Scrum Masters. Scott and Ann would schedule them into Certified Scrum Master classes as soon as possible.  Scott agreed that both Brian and Ann would make excellent Scrum Masters, just as they might make excellent Product Owners, but they had been business analysts too long and the imprimatur of their role and their reputations in the organization would act against them in being successful as servant leaders, just as the former project managers would have run into difficulty. “And besides, there’s Ken standing in the way”, concluded Scott.

“Well, that’s it,” breathed Ann as they left the cafeteria. “Looks like we did it. That’s everyone accounted for. ”

“Except us,” said Brian hoisting his backpack on his shoulder.  “However, that is all the meetings, right?  Everyone who was looking for us found us.”

“Not everyone.” Ann was afraid to say the name. Just then Sandra, Verna’s Personal Assistant, rounded the corner and headed straight for them with Ken at her elbow. Ken looked like he remembered why he had been looking for them.

Was Ken in Cahoots with Verna?  Had he swung Verna over to the New Order of Agile Development?  Would this be the end of Rico?  And do we have to hear Scott say ‘and’ one more time? And where is Cahoots, anyway?  Tune in for the season finale where we find out what happens to the last two stalwart business analysts in the organization and finally meet Verna although like the Sopranos, the screen may go blank when we do.

* Quoted from Schwaber & Sutherland, “The Scrum Guide, the Definitive Guide to Scrum: the Rules of the Game”, published by Scrum.org, July 2011

Don’t forget to leave your comments below.

How Do You Manage an Offsite Business Analyst?

Do you, as a manager, actually know what your employees are doing on a day by day basis on client site? Are you aware, until their performance appraisal, of what projects they are working on and what tools they’re using to get the job done?

I am in a situation faced by thousands of consultants around the globe. How do you fairly represent your day to day job to your manager? I either end up:

  • ‘Bigging myself up’
  • Talking my achievements down

And always…

  • Getting positive but mostly useless feedback from clients

Let’s address them one by one.

Having worked on one or more projects for months, a BA (should) know each and every one of them inside out. A BA (should) know all of the things that went right/wrong, hopefully produce a lessons learned report that you (should) be able to recite in your sleep. So when describing your role in this project of course you’re going to sound knowledgeable, efficient, and demonstrate a level of understanding that would make the Dalai Lama feel queasy.

But is what you achieved as impressive as it sounds?

At this point it’s down to the manager to delve further. They have most likely been a BA at some point in their career and should know how to make you squirm!

But this is a performance review, not an interrogation!

Of course it’s not… that is why it shouldn’t come to a performance appraisal for you to know what your employees are doing. Even if you’re based in a different county you should still be able to pick up the phone at least once a month. This not only helps employees ask that annoying question about timesheets, but also feel a bond to the ‘mother ship’ and discuss that Christmas Party (did you hear what Lisa did in the boardroom?!).

At the end of the day, there is no point in exaggerating. Your manager should have regular enough contact with both the consultant and the client in order to understand what is expected of both the project team and individual employees. The same should apply for ‘talking yourself down’… there is no place for modesty in a performance appraisal. Unless you don’t like pay rises of course…

What about feedback?

It’s so rare for your own colleagues/manager to provide honest feedback why should your client? If you’re not up to the job they can just send you back to the dogs bench.

Unless I ask for feedback on specific areas I would generally receive a paragraph saying that I turn up to work on time, I do everything that is expected of me and I have a great relationship with stakeholders. Oh, and I’m really good at organising people’s leaving presents…

Surely companies should have a template for feedback provided to clients to enable them to answer honestly and fairly about the consultant? Or is it up to the consultant to have enough common sense to do it themselves?

For each of the consultant’s project related SMART objectives there should be a measure which a client can comment on. The feedback can then be sent to the manager, the consultant or both.

How many requirements document did Lisa churn out in 2013? Who’s Lisa and what’s a requirements document? Oh dear Lisa, I think we need to talk…

This all boils back to the way that your company performance manages you and your fellow employees… I just hope for your sake you’re not your company’s version of Lisa.

Don’t forget to leave your comments below.

Business Rules – Seriously?

As a consultant I see a variety of templates at different client sites for documenting requirements or use cases. Many of these include a section for recording business rules. Like many BAs I have a basic intuitive understanding of what a business rule is, but as I ‘know a guy’ I decided to catch up with the latest and greatest thinking in the business rules domain. I’m a firm believer in “it’s not what you know, it’s who you know.”

My ‘guy’ (a woman actually) is Keri Anderson Healy. She is the Executive Editor of the Business Rules Journal. She kindly shared with me her slides from a presentation she gave last November. While I can’t share the slides themselves, I can share what I consider the take-away points.

Point #1 – Under business jurisdiction”

Business rules are rules that the business enacts, and has the power to revise or discontinue. A business may be constrained by external factors such as the laws of nature or government regulations. These are considered rules, but not business rules (unless of course your business is governing (or you are Mother Nature)).

Point #2 – Detailed enough to produce a consistent result

A well-defined business rule should be sufficiently detailed and precise that any person expected to conform to the rule can apply it effectively and consistently in relevant circumstances.

In contrast to the level of detail needed for a well-defined business rule there is the related concept of Policy. Where a business has policies defined these can be sources of business rules. Keri’s example of a policy was “Safety is our first concern.” This policy acted as the basis for the example business rule “A hardhat must be worn on a construction site.”

The level of specificity between policy and business rule strikes me as somewhat similar to the relationship between high level requirements and detailed requirements.

Point #3 – Behaviour-related business rules

Business rules fall into one of two categories – behavioural and definitional. Behavioural business rules are intended to affect people’s conduct or actions. The idea is either to get a person to do something or prevent him/her from doing something. The hardhat example above is an example of a behavioural business rule worded to get people to do something (i.e. put on a hardhat).  Funnily enough the same rule could be worded from a preventing perspective – “No admittance to this site without a hardhat.” 

Advice is another concept in the world of business rules. Rather than restricting, advices are the business expressing explicitly what is permitted or not restricted. “No smoking, except in designated areas” is a behavioural business rule restricting people from smoking in undesignated areas belonging to the business. “Smoking permitted in this area” advises that people who want to smoke, can within the posted area.

Point #4 – Definitional business rules

Behavioural business rules are established by a business to get people to act in specific ways. Those rules ideally will be followed, but may not be by everyone, all of the time. Definitional business rules establish what is ‘true’ within the context of that business and remains true for the business as long as the rule stands.

The following examples are definitional business rules within the context of a car rental company:

Example 1 – A Driver is a person that has proof of a valid driver’s licence.

This rule ‘defines’ the concept driver within the context of this business. If this were a golfing business the term would likely have a very different definition. The trick with defining one term is that the other words/terms used in the definition need to be ones that are understandable to business people.

Example 2 – A rental agreement is not complete without identifying at least one driver.

This rule is about one specific status value of a rental agreement. Similarly to how behavioural business rules can be about preventing rather than doing, there can be definitional business rules about what is not true. That is the case here. The rule is stating that the status cannot have the value ‘complete’ under conditions defined in the rule.

Example 3 – A rental spanning seven or more days qualifies for weekly rates.

The third rule defines the conditions under which it is valid to utilise a particular set of rates. The specific rate value from within the set that applies cannot be determined from this one rule. There must be other rules defined that would work in conjunction with this one for identifying one specific rate that is applicable under those combined conditions.

As stated above, definitional business rules state what is or should be true within the context of this business (or what is not true within the context of the business). As the business operates there can be cases where what the rule states is not as it should be. For example, a person renting a car using a forged driver’s licence. While this violates the rule it does not change the definition of what a driver is for that business. Similarly, a rental agent might let a customer have a weekly rate on a rental of less than seven days, but that does not change the rule / definition of what it takes to qualify for that rate. Definitional business rules are what the business intends to be ‘always true’.

Point #5 – Context is everything (and language is a bitch)

We saw above that the term driver had one meaning in the context of car rental and another one in the context of golf. The good news is that the context of business rules is always the business or organisation managing its rules. The bad news is that one term does not equal one business rule. As seen in the examples ‘stating’ a business rule involves one or more sentences, those sentences containing a number of nouns and verbs in whatever language is being used (e.g. English). But that’s not all. Sentences, in addition to nouns and verbs utilise a number of qualifier words such as must, greater than, not and many more.

The objective of business rules is to get consistent behaviour or results. That involves consistent understanding of the terms used to express the rules, with sentences constructed in a way that the combination of terms is understandable to all involved.

Business rules – seriously?

Show of hands – who thought the three example business rules presented in Point #4 were ‘well-defined’ business rules? Prior to undertaking this article my hand would have been raised. But having ‘looked under the hood’ at what serious business rule people do, I know a lot more about how much I don’t know. Ideally the take away points from Keri’s presentation will have raised your awareness about business rules and the complexities of defining them well. For those of you that seek more on this subject there is a document Keri was involved with titled Semantics of Business Vocabulary and Business Rules (SBVR). It includes a meta-model of rule-related concepts and a case study showing many good examples of well-defined behavioural and definitional business rules. The document is downloadable at http://www.omg.org/spec/SBVR/1.0/PDF.

Where to from here? Personally I do most of my business analysis at the IT Project level. Serious business rule analysis is supposed to take place at the business level, independent of any IT projects or solutions. When necessary I will use those existing templates and do my best to represent business rules within the context of the project, incorporating what I learnt from Keri’s slides and numerous emails exchanged with her while drafting this article – thanks again Keri!

Don’t forget to leave your comments below.

Break Down the Business Analysis Boundary

kupe July23I seem to be getting inspiration from police departments lately. Stick with me, it is just a phase. Over the past six weeks, my city has been hit with a greater number of burglaries and robberies than normal. This rash of crime caused our small community to push our elected officials and police department for answers and accountability. To meet our needs for more information, the police chief agreed to meet the neighborhood at a monthly community meeting. The chief not only came with a few of his lead staff, but was also joined by representatives from two adjoining police departments. Since criminals do not see borders, the three police forces have come together to stop the crime in our area. 

What sparked my thought for a blog post was the willingness of the three police departments to share evidence and plan their approach to stopping the crime as one—not three separate—entities. If you know anything about police work in the United States, you know jurisdiction is typically a line that does not get crossed. Information is not shared freely between police departments. The attitude has historically been we will deal with our cases and you can deal with yours. If a crime was committed in our jurisdiction we want to catch them and convict them.

A similar attitude can be found on project teams. In many corporate environments individuals have the attitude of boundaries around one’s role. I’ll do my job, you do yours. The goal of individuals is doing their job well. If they do their job well then they think they are OK. If someone does not do their job well then it is their fault. The same is true from project team to project team.

What my local police and the other departments did is decide to focus on results and remove ego. The police departments don’t care who makes the arrest, just as long as the arrest is made. They shed a lifetime of a “this is how it has always been done” attitude and came up with an approach they think will work to address the goal. As a tax payer (stakeholder) I applaud my police department for looking for better ways to address our current issue. I think better of them for using this approach rather than one of isolation, even if they caught the criminal(s).

You and your team members have to do the same. Forget about titles and focus on the goal of the project. Your focus should not be about you. Do you think your stakeholders care if the business analysis was done well and the project failed? In the end all they care about is the project results taking care of their needs. They want you to do a good job, but more importantly, they want their issue resolved.

Most likely your teams are decided for you. You don’t get to pick and choose all the people you want to work with. The skills of the team members will include programming, business analysis, project management, quality assurance, database administration, subject matter expertise, etc. Your team has to come together and outline the tasks required to meet the goals of the initiative. Together the team needs to assign tasks based on expertise of each individual regardless of title. The team needs to be accountable for delivering a successful solution. In the large scheme of things, doing well on part of the project means nothing. A perfect example of this is if the business analyst does not have direct responsibility for project scope. If they just take the scope as is and don’t make sure there is a clear understanding of the business goal to be addressed, they are a bad team member. The fact that they did a great job with the functional analysis gets discounted if it was based on a bad scope. This may result in the true project needs not being met. A failed project and an individual failure.

This can’t happen without a culture shift and redefining how the team is rewarded. The days of collaboration are here and they are here to stay. Specialized work is still needed in some areas, but not all. Team members need to be rewarded for team results and behaviors that produce successful solutions. With my team I try to be clear on the goal of an initiative then leave it up to the team to determine the best approach. I reward open communication, collaboration, taking risks, the “I’ll take that on” attitude, failing fast, and owning up to mistakes. Smart, passionate team members truly collaborate, perform, and show results.

Don’t define yourself and others by their job descriptions. Focus on being a high performing team member and not just a high performing Business Analyst.

Communicate. Collaborate. Succeed.

Kupe

Don’t forget to leave your comments below.