Managing stakeholders through persona

Revision as of 08:23, 5 April 2023

Abstract

This paragraph is still to be written.

Introduction/Summary

In 1983 Allan Cooper was the first to implement the use of Personas in a Software Development project and popularized it in his book “The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity”. The project participants quickly saw the potential in using these “Personas” and naturally began referring to them during their project work as a reference to the users (The Cooper Journal: The Origin of Personas, n.d.). The method “Personas” is mainly used in design projects and the project participants together create a fictive profile to represent the stakeholders. This helps to ensure a user centric perspective and to humanize the design process when doing design projects. However, the method can also be applied to project management and facilitate ease of managing the many stakeholders and improve the communication, when using personas as a boundary object (Martin & Hanington, 2012). This article will first describe the idea behind the personas tool/method and how it can contribute to project management, then a guide of how to apply it in projects and finally the limitations involved when using personas.

The idea Behind Personas

But what is a persona and what are the benefits of using them?

A persona is usually a one-page description of a fictive character, representing an important stakeholder in the project and it typically includes the following:

• A bio with basic information such as: name, age, education and occupation.
• Illustration of how the person could look. Often a stock photo of sketch, to avoid any connection to a real identity person.
• A quote summarizing some of the main points about the persona, for an easy reference.
• More in depth description about life situation, goals and behaviour (Martin & Hanington, 2012).

What is a stakeholder

But before going into to much detail with personas, it is firstly important to understand what a stakeholder is. In the “Standard for Program Management – Fourth Edition” a stakeholder is defined as the following.

“A stakeholder is an individual, group or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program or portfolio” (Standard for Program Management – Fourth Edition).

Stakeholders can be many different people, both intern and extern to the project and have different influence and impact on a project. Therefore, it is important to consider which stakeholders that are most important and has the highest impact when developing personas, since they won’t all be equally relevant for the project and it is generally suggested to only develop a few personas. (Standard for Program Management – Fourth Edition).

The benefits of using personas in project management

Personas are used to create project targets based on individual stakeholder needs. When developing a persona, the behavior pattern amongst an individual or group is observed through research and the main needs, behaviors and goals are then defined. When narrowing down the most essential points in personas, it’s easier to ensure that the correct requirements are being prioritized, for the most valuable stakeholders within the project (Martin & Hanington, 2012). The initial main goals when developing personas can be narrowed down to the following:

• The personas are relevant to your project and your business goals
• The personas are based on data or clearly identified assumption
• Engaging, enlightening or even inspiring to your organization (Adlin, T et. al., 2010)

Other than ensuring that all stakeholders are understood and rememberd, it’s also important that the different motives of the stakeholders are understood and that the Project Manager is aware of of the stakeholder motives. The personas can make it easier for the project manager, to manage all the stakeholders and get an overview of their different goals.

“The program manager should be the champion for change in the organization and understand the motives of each stakeholder who could attempt to alter the course of the program or intentionally derail it and prevent the program from realizing one or more of its intended benefits or outcomes. ” (The Standard for Program Management – Fourth Edition)

By applying personas to a project, one can ease the communication between the project participants. Personas are often used as references, when communicating research summaries to clients, which makes the results seem more persuasive (Martin & Hanington, 2012). Furthermore, the personas can act representative for the absent stakeholders in a project. This ensures that despite the absence of the stakeholders, their most prioritized values are still being considered when making decisions (Woods et al., 2017). Overall the use of personas can help the Project Manager make better decisions, as it is stated in The Essential Persona Lifecycle: Your Guide to Building and Using Personas.

“Although having personas participate in discussions may feel a bit forced and awkward at first, this technique ensures that you never stray too far from the customer data that serve as the lifeblood of good decisions” (Adlin & Pruitt, 2010).

Other similar methods in project management

As mentioned above personas are mostly used in design projects, but a similar tool is used within project management, which is why adding the persona perspective wouldn’t be too unfamiliar for the project manager. Within project/program management a “Program Stakeholder classification” and a “Stakeholder register” is a common known tool and this tool contains many of the same elements as a Persona. A stakeholder register is develop using the following table.

INDSÆT BILLEDE AF TABELLEN

If the project manager was to include personas in a project, they could be viewed as the “Other charatersitics”, but with a more in depth and personalized description of the stakeholder. This tool does argue that the implementation of personas representative for stakeholder would be relevant to implement, since the PM’s does benefit from using a similar tool. (The Standard for Program Management — Fourth Edition).

Time and resources when developing personas

An important part of defining a persona is to remember only to include the information, that is relevant in relation to the given project. The information should be kept short and to the point, to ensure that the most important points stand out. A key rule is that the text amount should be kept to a one eye span, so that the information easily can be captured (Lidwell et al., 2010). When forming one or several personas, it’s important to do the correct research for the foundation of the persona. The information needed for the person can be through achieved through both qualitative or quantitative data in form of interviews, observations, focus groups, demographics or questionnaires (Fuglerud et al., 2020).

Developing personas is time demanding and can in some cases take up to one moth to develop. It is important that the personas are developed early in the project and that they are continuously updated and improved throughout the project as more knowledge about the stakeholders is gained (Lidwell et al., 2010). Furthermore, it’s important to remember that personas are created for a specific project, so they are not supposed to be reused for other projects. This means that when a new project is started, both time and recourses have to be allocated to the development of personas (Fuglerud et al., 2020).

Application of Personas

The development of personas can be hard and confusing, but it is possible to break down the process and make it more approachable. There are many different approaches and suggestions for how this can be done and not one can be marked as the correct on. In this article I have chosen to follow the structure described in “The Essential Persona Lifecycle: Your Guide to Building and Using Personas by (Adlin & Pruitt, 2010). This structure describes both the development and the application of the personas in a project. Through the description will I also include other literature references to ensure at holistic view on the process. How to apply the use of personas can be divided into the following five stages. However, it is important to remember that this structure is a suggestion and that it should be adapted to the resources that is available within the specific project.

• Phase 1: Family planning
• Phase 2: Conception and gestation
• Phase 3: Birth and maturation
• Phase 4: Adulthood
• Phase 5: Lifetime achievement and retirement (Adlin & Pruitt, 2010)

The rest of this paragraph is still to be written. The set up of personas – design . Here I will include examples of personas.

Limitations when using personas

One of the main limitations when using personas, is the reliability of personas. How do we convince other people that the personas are based on actual research, when they are only displayed for a small amount of the data. How do we ensure that the personas do capture the most important points from the stakeholders? It is an ongoing discussion if personas do meet the standards of the industry in relation to accountability. This is something to keep in mind as PM and ensure that the personas do appear reliable and credible (T. W. Howard, 2019).

Another limitation when using personas, it that it can take many years to master the tool. This means that it is not always beneficial the first time the tool is used and there is a risk that the tool will only be used this one time. Mastering the tool can take many years, but the more the tool is use, the better an understanding and value from the tool will the PM gain. This means that using personas comes with a risk of failure, especially the first time the tool is used. This can be failure in two different ways: Forgetting to use the personas during the project or developing non-useful personas, where creating non-useful personas is the biggest risk (The Cooper Journal: The Origin of Personas, n.d.).

When developing personas, a large amount of data has to be condensed into a few personas. Here there is a risk of developing a so called “Frankenstein Persona”. A non-representative persona, that does not describe any actual stakeholder. This means that the project team will be aiming towards the wrong target according to their stakeholders, which can in worst case lead to project failure (Fuglerud et al., 2020).

Another element that should be considered when applying the use of personas to a project, is that the personas should not be taking too much focus away from the actual stakeholders. Personas can not be seen as direct representative for a stakeholder, they can not contribute with all the same things as an actual stakeholder can. As mentioned above personas are a very condensed representation of something far more complex. Therefore, it is important to continuously involve the actual stakeholder through the process and get their feedback on the work. If the stakeholders are not involved there is a risk that they will lose interest in the project and the outcome doesn’t end as intended (Fuglerud et al., 2020).

Finally, it is important to state that personas never will be universally loved and respected amongst the people involved in a project.

“Although your personas can capture the attention and imagination of your organization, some of your team members are going to resist them. Personas will not appeal to nor be useful to everyone” - (Fuglerud et al., 2020).

When using the tool in a project, it is important to not force the project members to constantly use the tool and to accept that it at sometimes will be forgotten. It is important to evaluate the specific project and the context and not to force the application of the tool (Fuglerud et al., 2020).

Bibliography

• Adlin, T., & Pruitt, J. (2010). The Essential Persona Lifecycle: Your Guide to Building and Using Personas. Elsevier.
• Fuglerud, K., Skeide, Schulz, T., Janson, A. L., & Moen, A. (2020). Co-creating persona scenarios with diverse users enriching inclusive design. 48–59. https://doi.org/10.1007/978-3-030-49282-3_4
• Lidwell, W., Holde, K., & Butler, J. (2010). Universal Principles of Design.
• Martin, B., & Hanington, B. (2012). Universal methods of design. In Choice Reviews Online (Vol. 49, Issue 10). https://doi.org/10.5860/choice.49-5403
• The Cooper Journal: The Origin of Personas. (n.d.). Retrieved February 11, 2023, from https://web.archive.org/web/20101116073351/http://www.cooper.com/journal/2003/08/the_origin_of_personas.html
• Woods, L., Duff, J., Cummings, E., Walker, K., Woods, L., Duff, J., Cummings, E., & Walker, K. (2017). The Development and Use of Personas in a User-Centred mHealth Design Project. https://doi.org/10.1145/3152771.3156186
• “The Standard for Program Management — Fourth Edition, Standard for Program Management.” Standard for Program Management — Fourth Edition, Project Management Institute, 2017. https://findit.dtu.dk/en/catalog/5c45c08ad9001d2f38206ba6
• T. W. Howard, "Extended Abstract: When Is Persona Design Accountable?," 2019 IEEE International Professional Communication Conference (ProComm), Aachen, Germany, 2019, pp. 139-140, doi: 10.1109/ProComm.2019.00031.