Based upon the type of analyst (business, systems, information, data, etc...) and the deliverable you are producing (Business Plan, Use Cases, Usability Tests, etc...), people associated with your project may have completely different labels. There are some guidelines and I'll attempt to float them your way in this narrative.
I’m not commenting on whether it is a good thing or a bad thing. Simply that it is “a thing” you might want to be consider in daily interactions with people. Your actual mileage may vary but I've seen this trend present in many diverse situations.
We have all been taught that, a stakeholder is anyone affected by the outcome of a project. However, you might find that using that term in that context in the business environment is cumbersome. In most conversations and documented deliverables, stakeholders will never use the system. If they will never use the system, their concern regarding how it behaves can vary wildly. They are often concerned with the costs associated with producing, deploying and sustaining the system. They may be keenly interested in the reports produced by a system but their level of system specific granularity often ends at that level.
In most circumstances, users only care about their interactions with the system. Users of a high quality system don't care how much that system cost the organization. Along the same lines, they don't really care how much the company saved by implementing a poor system. Their main focus is "the job", an aggregate of tasks they are trying to perform. The successful completion of those tasks are directly tied to their perceived value to the organization and/or department.
This is a term often associated with use cases but I've also seen it used to describe the "as a ____" in user stories. They are very similar to users but the context is about a task. As mentioned previously, a persons job is a series of successfully completed tasks. When a person is called an actor, you can associate it with a specific task that needs to be described, analyzed and evaluated.
HOW THESE DIFFERENCES MIGHT SURFACE?
usability specialist may refer to a user as a “stakeholder” in a meeting. A project manager in that meeting will immediately try to associate a stakeholder to someone listed on a project charter, business case or other formal document. So when the usability specialist said “stakeholder”, the project manager immediately associates everything said thereafter to how it will affect costs or schedules. This is the exact opposite of what the usability specialist wanted because they often think of cost & schedule as secondary concerns to how the system performs.
©2015 Dwayne Wright