Author: Fred

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.

Managing Up; Tips and Tricks for the Project-Challenged

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

Managing Up is Vital

If you are a busy business analyst or project manager or even if you combine both roles by necessity, you already know from experience that “managing up” is a big deal. Failure to influence your boss’s boss, sponsors, and anyone else more senior to you to pay attention to important project details and give you their buy-in and commitment can have very serious consequences. You, your team, your organization, and your customers risk lost time and money, scope creep, poor quality results, lower innovation, reduced productivity, and higher levels of stress and burnout causing delays and mistakes due to high turnover and absenteeism. The following six tips and tricks will to help the project-challenged who know that “managing up” is important and would like to be proactive in doing more of it better.

Managing Up is a Mindset: You are the Pilot
Imagine you are in the pilot seat in an airplane and you see a view of your project approximately 10,000 feet beneath you. Keep this “big picture” view in mind when you attempt to influence upwards.
You Have About 20 Seconds
All it takes if the first 20 seconds of a conversation with a boss, sponsor, or other individual more senior to you for him or her to gain or lose attention and interest. So use your time wisely by focusing on the most important things first, such as the outcome, risk, benefit, or issue. Leave the details for later.
Train Them to Say “Yes”
Ask questions that are easy for them to say “yes” to, such as: “Do you agree that we must meet our targets?” or “It is important that our internal customers have their requirements met, right?” When they say “yes” to questions about the big picture, you are actually training them to say “yes” later when you ask them to commit to more specific things. Gaining their attention and interest first is necessary if you want their commitment and action later.
Plan Your Message to Start at the End First
Start at the end first. State your recommendation or the results expected and identify related risks, options, or changes next. Remember that the other person is also a pilot and is looking at the project from afar. It is up to you to focus him/her on exactly what you need and want and once this is understood, you have done the ground work to address more specifics.
Train for the Marathon
If you were planning to run a marathon, you would probably not expect to reach the finish line without sufficient training and participation in shorter races. It is the same with managing up. You also need to train ahead of time to build stamina and experience. Prepare for the marathon experience of managing up by creating a managing up marathon training program consisting of short spurts of conversations that give you experience and help build confidence. Choose topics for these conversations that are not high-risk, such as asking for commitment to change a small part of a project or recommending a project change that has a positive impact on productivity or the bottom-line. Your goal is to prepare for bigger, more complex marathons requiring more stamina and confidence.
Practice, Practice, Practice!
Don’t restrict your training to actual projects. Find ways to practice “managing up” in your personal life as well. Create a list of people you can practice with, including: colleagues; friends; professionals outside of work. Try asking them for something, assuming they are senior to you. If you are a member of a professional association, club, or group, seek opportunities to influence others with more authority or seniority than you and then ask for their feedback.

Summary

Managing up is a skill as well as a mindset. It requires the perspective of a pilot, the ability to plan and deliver your key message efficiently, training yourself and others, and ongoing practice for success. Like anything else that is worthwhile, if you make the right choices about how to spend your time and energy to prepare properly, you have greater chances to achieve better results.

Don’t forget to leave your comments below

Dr. Gail Levitt is President of Levitt Communications Inc., a global organization in Mississauga, Ontario with affiliates in Vancouver, Ottawa, Montreal, and Boston. Gail is an accomplished author, facilitator, and coach, specializing in leadership communications, critical thinking, and problem solving. She has over eighteen years of success, leading and advising diverse teams in managing people and projects. Some of Gail’s customers include: RIM; Bell Canada; HSBC; Telus; ACETECH; Project World; ESI International; Sauder School of Business, UBC; ACETECH; Transport Canada; Canada Post; Toyota; Starwood Resorts International. Dr. Levitt is currently writing a book on team leadership for business analysts and project managers.