Tag: Best Practices

Business Analyst Says: Let’s Pretend We’re Secret Agents

“Please don’t call me by my real name, it destroys the reality I’m trying to create.”

–Wallace Ritchie, “The Man Who Knew Too Little”

Back in 2009, I presented at an education conference that had as its theme “CIA — The Not Secret1So Secret Service.” All presenters were to incorporate a spy story or approach within their presentations to support the theme. My topic — an introduction to business process mapping — was by request so I welcomed a little extra inspiration to heighten my own interest.

While most people went the route of James Bond or Jason Bourne or the like, I was drawn to a favorite, little-known 1997 movie “The Man Who Knew Too Little.” In this movie, the lead character, Wallace Ritchie (played by Bill Murray), flies to England to spend his birthday with his brother James. James, however, has a business engagement is not too keen to have his brother involved with it. Instead, he signs Wallace up to participate in the “Theatre of Life,” a role-playing exercise that promises to treat the participant as a character in a crime drama.

Things go off the rails early when Wallace answers a phone call intended for a hit man, and he is mistaken for a real spy. Wallace becomes tangled up in a plot to kill Russian and British dignitaries on the eve of the signing of an important peace agreement between the nations. For Wallace it’s all an elaborate act; to the men who want a second World Cold War, Wallace is public enemy number one.

While I found the film entertaining, I also found it informative in respect to how I conceive of my business analyst dealings. I often feel like a secret agent when embarking on a new project or rather a new stage within the “Theatre of Life.” Walking onto a new stage means coming into contact with a new configuration of players, some of whom have been patrons of that particular theatre for many, many, many years. It means entering an evolving story, one that has characters entering and exiting stage left and right, up, down and center. It is our challenge as business analysts to infiltrate this story, flush out the secrets and motivations of the characters, survey the stage for dangers and allies, and ultimately fulfill our mission.

In a nutshell, we are secret agents.

Literature and cinema have schooled us well that all secret agents are governed by two sets of rules of engagement: those laid out by the boss and those learned on the job. I recently re-watched this movie and found myself yet again inspired by its entertaining and informative applications to my business analyst career. So I decided to start sketching out some of the various rules of engagement I have learned thus far on my secret agent missions. Presented here is a sampling of these rules, as identified in collaboration with this particular movie.

Play the role that fits the situation

There is no law that a business analyst must play the same role in every situation. Thank goodness! One key characteristic that separates good business analysts from great ones is the ability to assess a situation and take on the role required. You are always ‘you,’ but sometimes a little play-acting is necessary to get done what needs to get done.

Wallace: You’ve got a great accent, are you from here?

Wear the appropriate uniform

Pretty simple rule — match your attire to the role and to the situation. If you are working in an environment that is t-shirts and jeans, don’t show up in a suit and tie. And vice versa. You are revealing your status as a secret agent otherwise! Respect the situation and it will respect you.

Lori: Do you think I look silly in this outfit? I could take it off if you like.

Always carry the right tools

You need a solid set of tools for whenever you enter a new stage. Be selective with what you choose to put in your toolbox; you can always pick up other items along the way. I always have a white board pen, a little squeezeable toy and a rotation of three favorite necklaces. These items become my indispensible project assets. The pen lets me draw/write things down almost everywhere (all you need is a glass surface), the toy helps me alleviate frustration and the necklaces, well, just make me feel good.

Wallace: Conveniently found a mallet outside but I’m gonna swap it for this one, ok?

Never give up on you

Being a business analyst is hard, dirty, exhausting work. Don’t try to tell me anything different; I know of what I speak. Expect some bruises, some scarring on your missions. But don’t just give up when things get tough. Giving up on yourself is to allow external forces to become more powerful than your own will. Draw on your strengths even more readily to push through the negative, and remain confident that you can achieve success no matter the obstacles being faced.

Wallace: Hang on Bill, clench your buttocks.

Stand by your principles

Adapt to the situation but do not adopt it. Be authentic. Do what is right and not what you are told is right. Comprising your principles is akin to sacrificing your arm. You risk the quality level of your produced work and of not being seen as standing for anything.

Wallace: And I want a stairmaster, I want a juice master, I want a thigh master, and I want a butt master. And if you can’t give it to me, then I’m going back to Des Moines.

Don’t get boxed in

Believe it or not, you are paid to be creative, to think outside the box, to even blow up the box if need be! Being analytical does not mean following every prescribed rule or template out there. It means learning from these entities and assessing how best to apply them to the box so that you can do your absolute best. There may not be an ideal solution for any given situation; you need to be innovative and individualistic and creative enough to when/where/how to deploy your skills to the greatest effect.

Wallace: It’s for allergies — actually, it’s a powerful agent that sharpens my senses, yet deadens my emotions.

Know what works

Textbooks, training courses, templates, etc., are great starting points when embarking on a new mission, but that is all they are: starting points. Don’t be brainwashed into believing that there is a single right way of doing anything or that the same approach is applicable to every situation. Wrong! Learn the methodology and methods but always assess each unique situation to determine what will work and won’t work.

Wallace: They pay all your expenses, you’re licensed to kill, but there’s a downside. Torture.


Take the shot

You will encounter people who throw roadblocks your way occasionally; accept this. But if the roadblocks are not constructive or serve to satisfy individual agendas or hamper your work in any way, be direct as to the potential damage the blocks may be inflicting on the project. Be as polite as possible, but don’t be afraid to exercise some strategic confrontation in order to set up the tactical shots.

Wallace: Yo matey, you just stabbed me with your pen.

Question those in charge

In theory, a business analyst needs to question everyone and everything. What often happens though is that access to the higher end of reporting channels is blocked from your reach. Don’t accept this if you know or even suspect that the answers you seek are behind that block. You need to get at agendas and biases earlier rather than later. Continuously seek more answers for your questions rather than settle for the ones received.

Wallace: Time out. Uh, I hate to break out of character, but, you cannot shout into a person’s ear. It does damage. The spitting I don’t mind…

Team does so have an “I”

Yes, yes it does. Being on a team does not negate your individuality, nor does expressing your individuality within a team equate to being an egoist. You still need to look after you; it is just that now you need to figure out a way to translate that need constructively into the team narrative. You have uniqueness, a distinctiveness that should not be stripped or hidden away in the name of achieving a false ideal of what it means to be part of a “team.” It should be privileged, maybe even exploited a little.

Wallace: Well what about our story? Are we just a doomed couple, do we have to be Bonnie and Clyde? Can it be like The Getaway, couldn’t it be like that?

Have a signature drink

Or dessert. I much prefer the idea of a signature dessert.

Now your turn: what secret agent rules have you discovered through your missions?

Don’t forget to leave your comments below.

Teri A McIntyre, MA, CBAP, is a principal at Charann Consulting, providing business analysis and project management services to public and private industry. She is a Libra/Tiger, which scares and pleases her and her clients simultaneously. She adores analytical work and getting in front of the clients but rebels against putting a pre-conceived box around how such activities should be completed. Personal philosophy: Why should a painter paint if he is not transformed by his own painting? – Michel Foucault

A Dressing Down for Business Analysts

FEATUREJuly11BA: “They didn’t participate in my workshop. Again.”

Mentor: “You must be mortified.”

BA: “Seriously, they come up with these lame excuses: they don’t understand that computer stuff, they’re too busy, or they think it’s a waste of time. One even told me to just get it done and let him have a look when I’m finished. How must I fathom the requirements myself? And they call that idiot a professional.”

Mentor: “You sound like a stuck record. Every other week you stomp in here ranting about the users, the stakeholders, the so-called professionals who waste your time. You always blame everybody else.”

BA: “So now it’s my fault?”

Mentor: “When I was a green analyst I had the same problem. You know what I did?”

BA: “Hired Chuck Norris?”

Mentor: “I went back to basics – I started planning properly.”

BA: “Planning? First it’s my fault and now I did not plan! Well I did plan. I planned for all those morons to attendmy meeting this morning – I even bought muffins, for goodness’ sake – and none of them arrived. By the way – you want a muffin?”

Music to a BA’s ears

If I had 100 dollars for every time I heard a BA complain about the stakeholders not participating in  their meetings I would have – and I am not making this up – exactly 87 bazillion dollars and 50 cents. The big problem with people not participating in your meetings is that by the time you see a room full of empty seats it’s too late. The damage is done. You see, getting stakeholders to your meetings starts long before you even call a meeting.

In fact, it begins with a classic film: “The Sound of Music”. “When you read you begin with A, B, C. When you sing you begin with Do-Re-Mi.” And then you have the lines, “Doe, a deer, a female deer,” and so on. The point is that you begin at the beginning and the beginning of any BA project is planning.

So, as my fictitious friend asked earlier: What does planning have to do with putting people in the seats? For starters most BAs I come across don’t do enough, if any, planning, yet the Business Analyst Body of Knowledge (BABOK) clearly has an entire chapter devoted to it – Chapter 2 to be precise. Some of you may argue that you do plan. You create lists of stakeholders, you assign roles and responsibilities. But, on closer inspection, most BAs think that copying and pasting a list of stakeholders from some other project is a substitute for planning. It isn’t. There is no way around it. If you copied and pasted then you did not plan.

The list is important because it is the very first step the BA, that’s you, takes in understanding who does what, when, how, where and why. And if you don’t know that then you cannot convey any sense of understanding, relevance, or importance to the stakeholders. And without those only the soft-hearted will attend your meetings.

The BA communications plan describes how we will communicate with the stakeholders. Any stakeholders on the list that have an RACI “C” next to their name must become part of the elicitation process. Most often we will “C”onsult with them in a requirements workshop. We have to inform them of when we would like to “C”onsult with them and exactly what we will need from them.

It all makes perfectly good sense because you are ensuring that the right people are involved and that they know what is expected of them. The next thing you do is get their consent, their approval, because that leads to buy-in. You’ll need them to agree to what must be done, when it must be done, and who must perform each activity to gather all the requirements. There is also an implied contract that the BA needs those people to do their work for the sponsor and, if they don’t pitch, they are wasting the sponsor’s money. One way of getting that message across is through the content of the invitation to the workshop. Suggest that the participant’s involvement is crucial to the success of the project and that the sponsor is aware of this. If the sponsor has any organizational clout, it’s the added incentive stakeholders need to be there and be on time. In other words: wag the big stick.

The BA and the Paperwork

What you’ve done by ensuring only the right people attend the meeting is that nobody’s time is wasted. You don’t have people sitting around wondering why they never said a thing, never contributed to the proceedings. That quickly annoys people, particularly the busy ones These same people are the oneswho are important to the project at some point, if not right then. Having only the right people at meetings also makes the meetings move along more swiftly. Shorter meetings leave people more inclined to attend future sessions. More focused meetings with only the necessary people in attendance, also finish more quickly because everyone is driving to the same clear goal. So where do you find the required participants? You go back to your stakeholder list and communications plan, which should identify who should be present for the process under scrutiny and it’ll be correct because you didn’t just copy and paste.

The next item on your busy agenda is language. Imagine the conversation at the beginning of this story being between a BA speaking Russian and the mentor speaking Cantonese. They’re probably going to get things a little muddled and may even end up becoming frustrated with each other. By the same token you need to speak the language your stakeholders understand. If every other word you use is  jargon that only BAs understand, then your stakeholders will quickly get bored and start imagining the fantastic little getaway they’ve arranged for the weekend..

Context is king. Put the meeting in the context of your stakeholders so that they can understand the reasons why they are there in the first place: “I know you have customers and they place orders; tell me more about what you do when you receive a customer order.” It focuses the workshop immediately, the participants feel you understand what they do, and it shows you value their time enough to have done some groundwork.

If you do all of these suggestions,  through careful up-front planning to obtain a focused, contextualised outcome, then stakeholders will quickly feel appreciated and relevant and possibly even enthusiastic about your meetings. OK, maybe not always enthusiastic. But you will be able to imagine a completely different conversation to the one that opened this story.

I always say: If you can show business real value in what you do, then business will start to really value you.

Don’t forget to leave your comments below.

The Role of the Implementation Consultant – 3 Things You Must Know!

Congratulations! You’ve just won your first large client and you are being chosen to play the role of the Lead Implementation Consultant for the engagement. You are being chosen because you are, at your core, an excellent BA and have a very high level of expertise about the product or solution that has just been sold. You will now be the one chiefly responsible for understanding the client’s requirements and , as far as possible, addressing gaps so that the solution or product that has been sold will meet your particular client’s needs.

 While the role of an Implementation Consultant sounds (and in fact is) very exciting, there are few things you must know before you dive head long into the shoes of an Implementation Consultant. It is obvious that knowledge of business analysis is critical to succeed at this role. However, this article is not about the art or techniques of how effective business analysis is performed. There are far too many guides, models, and other bodies of knowledge that cover these essential tools.

What then are the other things any Implementation Consultant should be aware of? The things you should pay heed to and have a strategy for comes from a finer understanding of the role of the Implementation Consultant itself.

The Role of the Implementation Consultant

Typically, the Implementation Consultant is hired by the product or solution provider; and while they may consult with the client or customer for the duration of the Implementation, they most probably will return to their employer to be staffed on some other engagement once the current implementation consultancy is done. In terms of long term association and who is responsible for job security, the employer has the upper hand.

As a consultant to the client however, the Implementation Consultant needs to build strong and lasting relationships with the client. The Implementation Consultant will be one of the major representatives to the relationship the client will have with the provider. The key to any strong relationship is trust. Essentially, the Implementation Consultant has to perform his/her role by staying true to the client’s interests, and thereby build a relationship built on proven good faith and trust.

While this may sound relatively easy, it can be very tricky, meeting both your employer’s and customer’s goals and meanwhile doing what’s right for the role itself. However, by bearing in mind these important keys to the trade, you will find yourself far better equipped to perform effectively, rather than if these situations catch you off-guard.

Handling Conflict – The Implementation Solution Roadmap

While managing conflict sounds easy, most conflicts arise when what the customer truly wants would involve extensive changes which they believe cost relatively nothing. In return, the provider would like to propose alternatives that might meet certain parts of the requirement but probably wouldn’t agree to do exactly what the client wants or has requested.

 In liaising between the two, the conflict often lies in whether the Implementation consultant should be true to his/her employer, recommending what they would prefer, or honoring the trust based relationship they have established with their customer.

However, the best way to handle conflict is to study the requirement and determine what’s best for that particular implementation, irrespective of what the customer says they want, or what the provider says they can (or are willing to) offer.  This involves understanding true business value and clarifying these concepts into measurable processes or results.

For example, while the client may want a user interface for entering batch data (multiple rows), the customer might provide an interface to accept data one record at a time. The true solution to the requirement might not in the end be either what is requested or offered! The Implementation consultant should investigate the source of the data, the volumetric data involved, the business process and goal, and offer a solution based on these aspects of the requirement. For example, it is very likely that the implementation consultant might suggest an EDI file upload, which would bring immense value in terms of reducing data entry effort, face to face time with the system and increase the ability to perform a key function more quickly and easily.

Configuration Vs Customization

In terms of their responsibilities, the Implementation Consultant is in charge of understanding the client’s requirements and suggesting how best these requirements can be met by the proposed product or solution. While every proposed product and solution will have gaps, over-architecting the means to address gaps can be the biggest pit an Implementation Consultant can fall into.

In such situations, the goal of the Implementation consultant should be to address all gaps via “configuration” rather than “customization”. Configuration level changes are made to settings that do not require the code to be rewritten and the executables to be rebuilt. Customization, on the other hand involves changes to the code which are custom built or specific to this implementation.

Confining most changes to the Configuration realm will allow quick and effective changes to the product or solution rather than long drawn out changes which will require time, effort and money! This strategy also allows the client to get the best out of a ready to ship product or solution where their time to market is minimized.

Industry is recognizing the importance of this principle and it has resulted in the popularity of the widely hailed “SaaS” or Software as a Service model. Most organizations follow the 80-20 rule where gaps which can be addressed by customization up to 20% of scope is acceptable, beyond which it’s not advisable and would tend to reduce the benefits you get from a proposed product or solution.

Changing the Business Processes

Every product and solution will have a logical process that runs through the lifeline of the product. When a customer purchases a product or solution, most want to have the product or solution changed to match their business processes. In fact, most customers will realize value by changing the way they do things to match the inherent process present in the proposed product or solution.

While I’m by no mean suggesting a major change to a business model or making an existing business process ineffective, quite a few business processes in use in an organization have evolved as a result of the demands of the current infrastructure. A typical example of such a process would be how a particular department processes dividend payouts which would involve steps such as recording the dividend announcement, the dates and the rates, isolating the qualifying payees, calculating the amounts, clearing payments, reconciling differences and finally processing payments. The order that an organization performs these steps could very well be a dictate of how their current solution processes this task.

Rather than carry these types of processes forward to the new implementation, however, it is absolutely essential for the Implementation Consultant to explain what business process the proposed solution expects and encourage and drive change within the customer’s organization to suit it. While regulatory processes, for example, will not be subject to change, certain other processes such as the one detailed above should be redesigned based on how the new solution works.

In Summary

All said and done, the role of the Implementation consultant is tricky, complex and very influential. How well this role is played out can make all the difference between a successful implementation that is the canvas for a case study and one that turns out to be a disaster,  retold for years to come about how things can go wrong.

Every Implementation Consultant has to play the base role of a Business Analyst over and above which they have to manage the direction of the implementation. Being aware of the 3 key aspects of implementations we’ve talked about will help guide your implementation down the right track, and ensure your customer gains the maximum benefit out of their investment in your solution.

Don’t forget to leave your comments below!

Remzil Kulkarni has over 15 years of experience in technology enabled business transformation focused on Insurance, Telecom and Finance. She has a Masters degree in Engineering Management from Southern Methodist University, Dallas TX and is President of the IIBA Pune Chapter. She is a certified Prince2TM Practitioner and a Fellow of LOMA ( FLMI ). She currently heads the Business Analysis Centre of Excellence at Mastek Ltd., where she has worked for the last 5 years. 

Business Analyst Says: Do Something Worth Remembering

All I did was create some pretty-looking clouds. You would have thought I invented clouds.

 “Do something worth remembering.” So said Elvis Presley, who did many things worth remembering, like his infamous pelvis shake and those peanut butter-banana-bacon sandwiches. But how often do we take the time to recognize whether we have done something worth remembering in our careers?

As practicing business analysts we do ‘things’ every day. The requirements are gathered. The stakeholders are identified. The documents are written. The hands are held. This is all expected work, rote work if you will, of a business analyst. And certainly we love what we do, routine or not; we remember all of it. But is any of what we do in the daily grind worth remembering once the project is over, once the deliverable is delivered, once the milestone is achieved?

I go with “No.” Many a project has crossed my desk over the years, and mostly they stand out now as comprising lines on my CV. I don’t want to give the impression that I move on and forget everything that came before. I do remember all the projects I’ve worked on and often refer to past work as part of a future project. However, it is on the rare occasion that I can narrow in on some accomplishment or action which bookmarks a project as being unique and worth remembering beyond the advantages of a new career experience. We should strive to do something worth remembering, not just something that can be remembered, to give those experiences a little extra ‘oomph’.

I’m talking about the things that become humorous anecdotes relayed to friends over drinks or creative examples provided to a potential employer in an interview. These may be big ticket things but often these are the little things that get overlooked in the daily grin, that get lost in the purgatory heat of getting the job done and getting it done well.

One such bookmark for me centers on the aforementioned pretty-looking clouds. They started as a quick means to an end and wound up being something worthy of remembering not only for me but more importantly for my client.

It all started innocently enough.

I participated in a large-scale corporate website renewal project last year. By the time I was assigned to the project, the organizational unit owning it had already solicited two external reports on what needed to be addressed with the renewal, completed an RFP, and hired a consulting firm to complete the design by the time I arrived. This all sounded great until I started reviewing the consultant reports and the RFP. It became clear almost instantly that the scope and requirements for the project were ill-defined. Not only was the cart put before the horse, but the horse was completely absent from the landscape.

Never one to back away from a challenge, I furrowed my brow to figure out how to quickly elicit the missing business requirements to fill in the blanks. What I knew from the RFP and the project sponsors was that the organization needed a new website and that it was going to happen. Not a whole lot of insight there. I also knew from these two sources that I couldn’t re-interview or meet with the stakeholders regarding the requirements; these individuals had already been through two rounds of interviews with the consultants and had participated in multiple in-house discussions before my arrival. They were agitated by the lack of project progress, and it was strongly advanced that if I went the interview/discussion route again the project could collapse.

I heeded the advice wisely and devised a tactical plan of attack. After all, one reason I was brought into the project was to diffuse this agitation not exacerbate it. Luck was on my side when one of the project sponsors casually mentioned that the consultants had provided the interview transcripts along with their final deliverables. I combed through this source material and determined that the business requirements could be synthesized into five major themes. With this step complete, I took those themes and broke them down into accompanying requirement groups or business functions that would prioritize the functional and content requirements work later on.

While this achievement was thrilling for me, I knew no standard template or approach was going to work in the presentation of this information. I needed a hook, something creative that would grab the attention of these disgruntled stakeholders and keep it long enough to peek my head through opened door and win their preliminary support for further requirements work.

In a late-night rush, I decided to (a) present a picture of the themes (themes were limited to titles of three words each), (b) present one quotation culled from the interview transcripts for each theme, and (c) present the picture as a cluster of clouds to represent my own brainstorming activities on the project. There were three reasons informing my decision:

  • It was a website project so the stakeholders were open to a ‘non-traditional’ approach.
  • A picture would represent to the stakeholders an investment of my time and effort in understanding the project.
  • The text quotations would demonstrate to the stakeholders my investment in listening to what they had to say.

Portraying the latter reason was critical – I needed to present their words back not only to demonstrate my investment but to also attune them to understand that they were invested in the project too. For as disgruntled and unhappy as they were by that point, they needed to be reminded of their initial investment and enthusiasm for the project. This meant finding the right quotations; I couldn’t just pick any collection of words that fit the theme. They had to resonant as much as the visual, if not more.

I’m now irrevocably associated with “the clouds”.

Well, to say that the clouds were a success would be a serious understatement. I created the one-page picture and sent it to the project sponsors first. Unabashed glee may not be the best description of their reaction but it is darn close. Excitement for the project ratcheted up immediately within the project team and I was off and running. I presented it to the stakeholders next and the response was just as positive. I had hit the nail on the head.

The effort spent on the quotations paid off too, as people embraced the exactitude and simplicity of the words I presented back to them. They started trying to figure out who said what, sometimes even mildly arguing over credit. Through a single afternoon discussion we all arrived at the project muster point I desired: it didn’t matter who owned the quote, what mattered was the depth of commonality across the entire stakeholder group in understanding what the project needed to achieve. It didn’t matter that Person A said the words; it mattered more that Person B through Z also agreed with the words.

With the commonality recognized and accepted, great things started to happen. Those stakeholders that were still in the project, but were ready to bolt, started voicing their frustrations constructively and engaging with the project in a more active and optimistic fashion. In fact, the one stakeholder I was told would never get on board became one of the project’s biggest supporters. As well, those that were still engaged but with low enthusiasm started increasing their engagement as well and translating their increasing enthusiasm into actionable tasks and positive commentary.

That one-page document with the pretty-looking clouds became the lynchpin for the project. Whenever the project appeared to stall or lose some momentum, out came the clouds. Whenever an external party questioned the work and scope of the project, out came the clouds. Out came the clouds everywhere. It became a punch line of sorts; “remember the clouds!” was a familiar refrain throughout the early weeks. One of the project sponsors even talked about having a t-shirt made with the clouds that she could wear to executive meetings and presentations!

With these pretty-looking clouds, I did something worth remembering without any expectation of doing so. A creative, tactical gamble paid off more than I anticipated. For me, the clouds got the job done; for my clients, the clouds got the job done well. I won’t be remembered for the deliverables or the content audit or the many other routine tasks I completed to successfully implement this project. I may not even be remembered at all in five years’ time. But those pretty-looking clouds will be, and it is satisfying to know I played a central role in their creation and longevity.

So, do something worth remembering. And not just for your clients or for a promotion or some reward, but do it for you. Go outside the boundaries for the standard rules of engagement. Take risks if the circumstances warrant it. Make it a habit to reflect on your work beyond what you needed to accomplish and take stock of the worth of your contributions. Such reflection will make you a stronger business analyst and reveal opportunities you may not have conceived of as being possible.

 Don’t forget to leave your comments below.

Teri A McIntyre, MA, CBAP, is a principal at Charann Consulting, providing business analysis and project management services to public and private industry. She is a Libra/Tiger, which scares and pleases her and her clients simultaneously. She adores analytical work and getting in front of the clients but rebels against putting a pre-conceived box around how such activities should be completed.  Personal philosophy: Why should a painter work if he is not transformed by his own painting? – Michel Foucault

So How’s That Working for You?

Often while teaching business analysis, students ask me, “Why should our business adapt any of these business analysis techniques?  We don’t use these techniques because they take too much time.”  My initial response is always, “So how is that working for you?”  This open question requires not only an elaboration, but some thought and not just a quick response.  It is also an effective question that allows me to start a dialogue with the student rather than a discussion defending the use of business analysis techniques. 

The word dialogue in Greek means to “talk through” as opposed to the word discussion which is derived from the Latin root meaning “dash to pieces” (1)

As the students ponder, I follow-up with some more focused questions to “pull” information from the student rather than immediately “push” my opinion onto the student.  “How are your projects performing today?  Are your expectations being met?”  These questions, of course, assume that they are tracking projects via measurements.  And by measurements I am not just talking about being on schedule, within budget, and delivering the stated scope.  I’m including the delivery of the benefits and/or compliance issues as stated in the project business case (discretionary and nondiscretionary projects). 

Often, project benefits are not realized until after project closure; therefore, they need to be tracked at the enterprise level. 

Continuing with the follow-up questions, “Does your business actually audit the business results?  Or does your firm declare victory upon the completion of a project and then move its attention to the next endeavor without any reconciliation of the business needs actually being met?”  Unfortunately, many firms only measure the project level “triple constraint” (time, cost, scope) while the tracking of the business results at the enterprise level goes unrecognized and unrecorded.

Success is not gained from the project execution, but in the business result it provides. 

Using active listening, I gain a better understanding of the students’ experiences.   Typically responses to my initial question are the following:

  • “Our project performance is good; our projects generally come in on time, within budget and deliver the committed scope” or
  • “Not so good. We have experienced some challenges in maintaining project scope along with unclear business results.”

With the former response, I advise the students if they feel project results cannot be improved then don’t change.  Of course, in reality there is always room for improvement; it’s just a matter of cost vs. benefits.  Along with this, I recommend that students consider benchmarking their results with other firms in their industry to ensure they are not missing an opportunity.  Competitors may have found ways of achieving better results, not only lowering cost, but gaining new revenue and deteriorating your firm’s market share.

Those who do not monitor their competitors soon find themselves working for them.

With the latter response, I advise the students that business analysis techniques lower the risk of maintaining project scope and ensuring business results.  These techniques are best practices and as best practices, they are proven to be effective and efficient in analyzing business requirements and process improvements.  Some of these are: 

  • Using the diagnostic approach
  • Modeling the current (AS-IS) and desired (TO-BE)
  • Determining root cause of problems
  • Measuring performance via metrics
  • Involving users
  • Building a business case
  • Defining and validating requirements iteratively
  • Tracing requirements back to the business need

I suggest to the students that they have before them the opportunity to help explain to their firm how business analysis techniques at both the project and enterprise level can improve their business results.   Their first step is to list the threats and opportunities for their business.  They can then gain support by developing stories that predict both positive and negative results for their firm.

Business analysis techniques lower the risk of maintaining project scope and ensure business results.

This means, of course, that their firm must change their current posture and adopt business analysis techniques at both the project and enterprise level.  Unfortunately, history shows that human beings typically are not motivated to change until they reach a cusp of a crisis.  Hollywood portrayed this behavior recently in a dialogue between an outer-space alien and an earth scientist on changing the nature of human beings to save the environment of their planet (2).   In this context, the key is for the firm to change prior to the demise of the business.

For change to happen, a sense of urgency needs to be established.

So in conclusion, “How is that working for you?”  If your answer is “not so good,” then you have an opportunity to take the Kotter’s first step in changing the organization – state a sense of urgency (3).  Start a dialogue on addressing the business threats and loss opportunities of not achieving business results (i.e., a business case).  After you have established the urgency (As-Is model), establish a team, define a vision (To-Be model), and conduct a gap analysis on how to make the transition using those business analysis techniques.  Yes, business analysis techniques do take time, but in reality they are time savers and saviors of the business.

Pay me now during the project or pay me much more later during the business.   

Don’t forget to leave your comments below.

Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University.  He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials.  He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business.  Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].


(1) Cracking Creativity: The Secrets of Creative Genius by Michael Michalko, 2001
(2) The Day the Earth Stood Still, 20th Century Studio, 2009
(3) Leading Change by John P. Kotter, 1996