Tag: Stakeholder

How to Promote Stakeholder Ownership

Written by Anton Oosthuizen on July 24, 2012. Posted in Articles.

One of the first things a project manager does on project initiation is compile a project plan that contains, among other things, an RACI, which is a matrix showing the roles and responsibilities of the different project stakeholders. But there is one responsibility that is never spelled out in any document. This is the responsibility of a stakeholder to take ownership of their own decisions. Everywhere you look there are certain responsibilities that stakeholders must take ownership of, which are mostly social and moral, but for some reason it is deemed acceptable for a stakeholder on a project to neglect their responsibilities toward the success of the outcome.

Now some people will argue that these checks and balances are present during different phases of the project to enforce some sort of ownership — i.e., the approval of a specification, acceptance of a test result, etc. — but all of these are usually at the end of a phase, and as any business analyst can tell you, a lot of water passes under the bridge before this is reached.
So besides the normal approval of requirements, specifications or test plans, what should the stakeholder be taking ownership of? I believe we have all been in a situation where we are responsible for conducting an elicitation workshop and as we know one of the elicitation tasks is preparation. When the facilitator of a meeting or workshop neglects to prepare properly, the outcome is doomed from the start, but this is true for the participants as well. Participants should come to a meeting or workshop fully prepared, but unfortunately not a lot is done to enforce this.

If you have facilitated more than one session, you have most probably heard somebody say “since you are the experts you should be telling us what to do,” and this normally comes from the participant who arrives with only his mobile phone. Although there is some truth in this statement, it is too often used as an easy way out of doing anything or for taking responsibility. The ‘tell us what we don’t know’ is used as plan B whenever the stakeholder has neglected to deliver on plan A, which is to prepare.

Just like making a child eat their vegetables, there are ways to make the stakeholder take responsibility, but as with the former it is never easy and could lead to tears. This is part facilitation skill, part stakeholder management and part psychology. This is the how-to guide to getting your stakeholders to take responsibility.

Start driving home the message well ahead of time. Don’t wait for the last minute but remind participants of their responsibility to come prepared two or more weeks in advance. It is always a good idea to include anything that they should be bringing to the table in the agenda, which by the way should also be distributed early.

Ensure that any presentation material is distributed with instructions on what needs to be done, i.e., homework.

Always try to get as much input from stakeholders before the session. This will allow time to understand what stakeholders are thinking and hopefully provide valuable information on how to steer the session.

Get commitment for stakeholders about attendance and participation.

Make sure the agenda has a clear set of objectives, something that stakeholders can think about but also that is of particular value to them. You want to ensure there is a sense of anticipation, i.e., ‘they are going to be discussing this and I’m not being left out.’

Get to know your stakeholders, that way you can talk to them, ensuring they have a sense of ownership. Throwing a general statement out there has its place, but nothing says ‘you own this’ more than looking somebody in the eyes when addressing an issue.

Actively engage the stakeholders to make some verbal commitments. One of the outcomes of any meeting or workshop is an action list, but getting verbal agreement from a stakeholder in front of his peers always provides an ‘Oh #$#@# now I am responsible’ moment.

Make it about them. We all know that is why we do it, but in many cases stakeholders attend sessions because they were told to, and there is nothing worse than dealing with a stakeholder who did not buy into the idea. If they feel you are there to try to add value to the function (and not just because it is a contract deliverable), you might be surprised how they open up.

But the old adage ‘you cannot satisfy everybody all the time’ remains true. There are times that stakeholders will arrive with the gusto of a sloth on his way to his afternoon sleep and remain like this throughout, but there are always opportunities where you can awaken the beast and as a facilitator this is part of what you should be looking for.

The most important and powerful tool you have to mitigate this type of behaviour is…YOU! When stakeholders say that we [BAs] are the experts and should be guiding them, they are 100% correct. If we cannot do this then we have no place standing in front of the customer. To manage your stakeholder effectively, you need to do so from a position of authority. Contrary to popular belief, availability is NOT a skill and nothing annoys and breaks down trust quicker than a placeholder, so if you see this coming your way, run!

Don’t forget to leave your comments below.

The Power of Story in Business Analysis

Written by Jarett Hailes on June 11, 2012. Posted in Articles.

Tell me if you’ve heard this one before – you’re on a project that was thrust on your stakeholder groups from high above. They were insufficiently consulted during the problem definition phase, and they are now questioning everything during implementation. These stakeholders can’t get the project to be outright cancelled, but they can cause it to be ultimately unsuccessful if they don’t commit to putting their time and energy into ensuring that the solution being developed is appropriately used.

Sound familiar? Business Analysts can often be faced with reluctant or even hostile project participants. Sometimes this can be due to lack of sufficient involvement early on, other times it is because they do not see the value in your project. How can you work to overcome these powerful barriers and get your entire stakeholder group to work with the team to successfully implement change?

A few years ago I was working in the education space and faced this challenge. The government had decreed that a change was to occur and that all school boards within the jurisdiction needed to conform within a certain timeframe. As more boards became aware of the change and the impact it would have on their organizations, many naturally questioned why the change was needed. The project team needed an effective way to present the long term value of the change without boring people with facts or figures, or getting into long winded explanations. So we focused on the one common value driver that all the school boards had in common: the student.

We used a short two minute before-and-after video depicting a day in the life of a new student and how the change would positively impact their educational experience. Even seasoned educators had their heartstrings pulled seeing the video; they could immediately empathize with the student and recognize how the situation described was all too common in today’s world. We used this story to introduce nearly every presentation and dialogue we had with our stakeholders for several years, as it helped establish the reason for why the change was necessary and put everyone’s mindset into focusing on the common goal all stakeholders had – providing the best possible education to the student.

Stories can captivate an audience, give them the critical information they need to understand a complex problem in a concise package, and be used to get people with very different backgrounds and goals to relate to shared events and situations. Leveraging stories to engage readers is used in the educational setting to help students process new or challenging experiences. Danielle Lowe, an educator in the state of New York, has observed “story-telling is a timeless teaching tool. Expression through text offers readers of all ages the opportunity to find solutions through the characters and conflicts within a story, and thus within themselves.”

Business Analysts have several opportunities to leverage stories in their work:

Defining a business need: sometimes worthwhile projects are never started because the individual(s) who recognize the problem are not in a position to allocate resources to develop a business case. Many Business Analysts who are embedded in business units can uncover problems or opportunities that can have a massive impact on the organization. Stories can be a great way to convey the business need to potential executive sponsors and get them interested enough in the topic to have a business case commissioned.
Documenting/communicating requirements: as Scrum methodologists are well aware, sometimes requirements can be best described in the form of stories. These do not need to be long narratives, but rather simple, structured descriptions about what needs to be addressed and in some cases why. Stories can also be effective when you need to summarize detailed or complex requirements. When performing a current state analysis of an entire division, I analyzed over a hundred processes and documented hundreds of requirements. To communicate my findings, I used three simple stories to describe the main challenges the division faced in their daily operations. This gave me a starting point to show how these challenges could be addressed through changes in processes and supporting technologies.
Secure stakeholder buy-in: while this activity is not solely performed by Business Analysts (indeed, the responsibility for buy-in is usually assigned to the Project Manager or Change Management team), we often directly engage with the stakeholders that will ultimately make the solution being implemented successfully operate and realize its full potential. As a result we are the first to encounter signs of potential resistance, and can be put on the spot to justify why a project exists or receive criticism for how the project is going. BAs have an opportunity to put forward a succinct but effective description of why a project is valuable, and can use story to relay the message in a narrative that matters to the stakeholder at hand. This can be tailored by stakeholder, often by using problems that they are encountering in today’s world and describing how the project will address those issues. When working on an inventory management project, I used two examples of the biggest pain points the group was encountering to convince them that performing extra data entry up front was worth their time and effort.

You don’t need to have the skills to pen the next great novel to effectively use stories. Focus on the narratives that matter to your audience and think about what compels them to do a better job. For some groups or individuals, it’s the customer that drives their desire for doing good work. For others, it may be recognition or compensation. Like any good story, start off with a problem that needs to be solved and then have your hero (in this case, the proposed solution) save the day. Don’t over exaggerate what the solution can do for the sake of the story, or else you may lose credibility with your audience. Even if the story has a fictional character or problem situation, make sure the benefits the solution is shown to perform are something it can actually do.

Stories can be a powerful and effective tool at conveying information to audiences, and when done well can be used to give people with entrenched viewpoints a chance to look at another perspective without being bombarded with facts or differing opinions. Business Analysts can look to leverage stories to engage and expand the minds of stakeholders in working towards a common goal.

Don’t forget to leave your comments below.

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

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

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

Collect and Separate

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

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

What is missing?

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

What’s Good About It?

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

Take the Deep Dive

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

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

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

Check the Viability of the Tool or Process

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

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

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

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

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

Don’t forget to leave your comments below.

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

The Lexicon of Solutions – Down with the Customer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Don’t forget to leave your comments below.

A Collaborative Stakeholder Analysis

Written by Fred on August 31, 2010. Posted in Articles.

It can be said that a stakeholder is any individual or group with an interest in the success of an organization in delivering intended results and maintaining the viability of the organization’s products and services.

A stakeholder therefore can affect either project scope or product scope. It is our users, be they managers or clerical staff, that we depend on to determine the functionality of a system. I strongly believe in the business taking ownership for its own requirements.

Users tend to think of functionality in terms of needs. “I need the system to do this.” “Will the system ever be able to do that?” and the ever persistent “the system won’t do what I need it to do because of something.” Users drive change because they need ‘things’ to perform their duties and to make decisions.

The business analyst makes those things happen, and thus, leads the business to its own solution. This brings me to a technique which I have had much success with; a stakeholder analysis.

A stakeholder analysis can uncover so many interesting things, for example: who needs and does not need access to the system, who has overlapping responsibilities, whose goals do not align with the responsibilities assigned to them, which business processes are common and which are redundant. I could go on, but let me get right to it. I use the stakeholder analysis to determine who my users are, what needs they have, how they expect to have those needs met; ultimately, what they will do with the system.

A stakeholder analysis should be done at the very beginning of the project and feed directly into the initial vision and scope documents.

To achieve this I generally do the following:

Determine who all the stakeholders are.
Categorize them into people and non-people, users and non-users.
Build descriptions, goals and responsibilities for each.
Confirm that the goals and responsibilities are aligned.
Work with the project group, staff, SMEs and general user community to determine everything that the user needs and might need from the system.
I usually assign the above tasks to an SME or other lead. This gives me time to begin collecting business objects, rules or other requirements.
In addition to the activities/business processes, I also ask for the stakeholder’s physical location and any other general characteristics that might be important.
If there is a high volume of activities and users, I may create a matrix that associates the users to the activities. This is really helpful to see overlap, redundancies and common activities.
Where the environment is very dependent on rules, or has a highly functional org-chart, I may use a legend in the activity/user association that looks something like this:

A. Basic and persistent association.
RA. Persistent association that is based on some to be determined rule.
TA. Non-persistent association that is transient in nature. The user’s association to this activity is dependant on a condition. Once the condition is met the association is only available temporarily.

I then begin to abstract the stakeholders looking for those common activities that can be rolled up to an abstract user.
This allows me to take advantage of inheritance and is the first step to creating system actors.
Next I can begin to create an actor model, which includes inheritance between actors and associations back to the stakeholders (traceability!).
I now have a very clear picture of who needs to do what, who has access to what and who might not need access at all.
With my users associated with my business processes and my actors associated with my users, it is very easy to see which use cases I will need and how much usage those cases will have.
I then begin to translate my activities into use cases and start to determine which scenarios I will need.
If I were able to assign the stakeholder analysis to someone else, I may have an idea of which business objects and rules will fall into which use cases.
I may also know something about the business events and pre/post-conditions.
With a decent list of use cases, actors, users, business objects, triggers and invariants I am ready to begin an effective use case model.

Remember, I mentioned that a stakeholder analysis should be done at the beginning of the project.

Within a short period of time I have determined who is touching the system, how they will touch it and what their needs are. I also have an understanding of which business objects I will need, what rules will be employed and where the subject boundaries will fall.

If this exercise moved at a good pace, the project may not even be out of the inception or elaboration phase. Now that my project manager is super-impressed I can get to work on building models and the BRD. I don’t have to tell you how many artifacts can use this analysis – security models, training and process diagrams or workflow analysis, just to name a few.

I hope that this can help you in your next deliverable.

Don’t forget to leave your comments below

Perry McLeod, CBAP, PMP, EVP IIBA, is a Certified Business Analysis and Project Management Professional with over 15-years of experience in business systems analysis and project management. As a Senior Management Consultant, Perry has worked with many clients including, Thomson Reuters, Capital One and Fifth Third Bank. In addition to a strong history in business analysis, Perry is also an instructor and contributor to the IIBA’s Business Analysis Body of Knowledge. He is currently teaching Business Communication at Sheridan College and is a Technical Lead, Management Consultant for CGI. His ultimate goal is to help raise the level of maturity for his clients, building the roots for a Business Analysis Centre of Excellence (CoE). Effective planning and communication, established best practices and a well-defined risk plan are critical to Perry’s success and he stresses them for every project. As a member of the IIBA’s Toronto Chapter, Perry is committed to raising the chapter’s visibility across the GTA by helping companies understand that aligning themselves with the chapter is the first step in reaching higher levels of maturity and competence for their internal business analysis community.