Have you ever heard a statement similar to “Customer service is just not like what it used to be” or “Good customer service is a thing of the past”?
Even if you have not, it’s very likely that your recent experience with some customer service representative from a business or service provider has not been all that positive. To avoid being too pessimistic, it seems that focus on the customer which should naturally be the most important part of a project, is often forgotten for some mysterious reason. In the world of project management, we often make an attempt to understand business objectives, user requirements, technical specifications, etc. in order to maximize our chances of building the best possible solution within the given constraints. However, most projects still fail. Why is that?
Regardless of the type of project you are involved in – IT solution, construction, aerospace, etc. – it is likely that this project will have many formal or informal requirements. Requirements can come from a number of different sources, such as the paying customers, actual end-users/consumers of the product, key stakeholders/investors, or important executives/management. A lot of time and money can be expended in pursuit of the “perfect requirements” that is intended to maximize the probability of a successful outcome.
Quite often, even the most thorough and detailed requirements documents can fail to meet the needs of the project due to the lack of one element: personas. A “persona” is a component of the requirements analysis process that is often forgotten because it is not explicitly called out in most formal project management publications. The PMBOK (Project Management Book Of Knowledge), 6th Edition, very briefly mentions the term “personas” within the glossary, defined as “An archetype user representing a set of similar end users described with their goals, motivations, and representative personal characteristics”. Interestingly, the PMBOK does not describe how this concept fits into the overall project management discipline, which may explain why most projects I have worked on do not allocate time to identify personas that are relevant to the initiative.
“Why is ‘persona’ important if it is barely mentioned in the PMBOK?” you may ask. My experience leads me to believe that by NOT defining personas, we miss out on the opportunity to truly understand the customer, the end consumer of the output we are working so far to deliver. The persona enables us to take the perspective of the most important role – the customer benefits most from the solution you are delivering – to gain appreciation for WHY they may choose to use your product or service instead of another competing offering. Although we need to focus on the HOW as well in order to design/build/test/deliver the end product, truly understanding the WHY can make a tremendous difference between success and failure.
In closing, next time you are on the verge of kicking off a new project, you might consider setting aside time to formulate a “persona” for each type of individual that you expect to interact with your end product/solution. You may glean some unexpected insights from this process that could shape how you plan and execute your project.