can’t live with them, can’t live without them
At some time, most project managers, at the peak of frustration with a user or group, have concluded that without users, our projects would be perfect. Unfortunately, without users, there wouldn't be a project. If you “can't live with them, can't live without them,” then what?
What/Who is a User?
Did you realize that in general conversation the term user stands for drug addict? Some of us might think our users were on drugs—or wish we could put them on drugs…But alas, this is “Project Management” (said sternly, with conviction), and users in my context work with a computer application, and are any or all of the following:
• Workers who will use the project once it is done
• Management, who may use the software, or delegate its use to someone else
• Project Team participants (user representatives) who help specify, test, and accept the system
• Eventual “hands-on” people who will rely upon the fully deployed application to do their job.
This definition doesn't include the customer, sponsor, or any project management counterparts. Their role is to facilitate getting the project done, but they will not necessarily be its users. It is important to know the difference: the customer may be happy, but the resulting project a waste of time if it doesn't address the users' needs.
People, particularly the users, can be one of, if not the most, challenging issues for a Project Manager. Users generally do not have any reporting relationship to the Project Manager, do not automatically trust them, and do want to be involved—but not blamed if things go wrong, and the project is just one of their responsibilities.
As the Project Manager, in your role as leader, establishing expectations of the relationship the team is expected to have with the users is critical. While you always want to control scope and key decisions, a vast amount of detail on requirements and specifics needs to be shared with the users. Without direct team member contact, but funneled through the project managers, this information is potentially delayed, incomplete, and/or just inaccurate.
The tools and actions to establish expectations are inherent in the project management life cycle. From the initial definition of goals and scope, which help the team understand the context in which to make day-to-day decisions, through the responsibility assignments, and development of an overall project plan that integrates the user's contribution, the team has the foundation to understand where the users fit into the picture. Your subsequent leadership and reinforcement of that involvement throughout the project (actions always speak louder than words), sets the tone for the team.
Your team can't deal with two “bosses”—so as part of establishing the expectations on dealing with users, they also need to know the “bounds.” These are the points that you expect them to alert you to issues, seek approvals, or otherwise defer decisions. As a team member, it gives them an easy out for dealing with hard issues. They do not have to be the “bad guy.” My belief is that as the Project Manager, when a “bad guy” is needed to say no, that falls into your responsibilities. This protects the relationship your team has with the users, and you are in the position to assess overall impact and consequences of unpopular decisions, and deal with them accordingly.
The user's preconceptions of working with a project team—be it an internal IS department or an external consultant—are generally based on their previous experiences, as well as some factors that are outside of the project team's hands, such as perception of fair price for value and management forcing the application upon them. These user perceptions of the project team can span the gamut—from an open arms welcome and let's work together attitude, to outright hostility and sabotage.
Conversely, the project team's perception of the users can be equally broad ranging, and just as critical a factor in how the relationship comes together. As Project Manager, the team will take its cues from you—whether they see a sense of frustration, impatience with users, or a healthy respect that focuses on understanding users' needs and working cooperatively.
Exhibit 1. User Types
My recommendation on dealing with preconceptions is to acknowledge and discuss them. As project manager, this sensing and managing the relationship is part of your task—and can be critical to setting up the enabling environment to let the team take care of the individual tasks and work products.
As Project Manager, you need to watch for behaviors and patterns that indicate trouble—both in the project team and with the user. Starting first with your project team, any one of the following is a warning, and more than one would merit investigation:
• Team tells you they don't want to work with a particular user
• Team relies on only one special user for answers—any others are “discounted”
• Team spends hours discussion/debating what the user meant or wants, but doesn't contact the user for clarification
• Team starts to document every user conversation and send confirming notes on all decisions
• Team never talks with the user via phone or in person, but relies exclusively on written documents
On the other hand, similar user behavior may indicate potential issues:
• User comes to you concerned with progress or lack of knowledge about status
• Users make comments such as “whatever you think,” and “you know best”
• String of messages on simple issues don't seem to reach resolution
• Users spend hours documenting what they want, with multiple memos and correspondence
• Multiple versions of specifications that don't reach closure—major issues identified with every review
Characteristics and Types of Users
Think of your users with respect to two primary characteristics:
- Knowledge of the subject matter
- Desire to exert control over the outcome
With this in mind, consider the grid in Exhibit 1. There are two coordinates: knowledge of the subject matter, and desire to exert control over the outcome. Depending on the user's ranking on these, they can be seen as a continuum ranging from Pawn to King, and Novice to Expert.
The extreme combinations of these characteristics as shown in the four corners are generally trouble—except for the Visionary. There is one issue with Visionaries however: they are usually moving so much faster than the rest of the team, that they need to be “grounded” in the scope of the current effort so as not to leave everyone else behind as they continue to move the target.
User Subject Matter Knowledge
The Novice level of expertise, with respect to the subject matter is problematic. Unless this person is exceptionally skilled in soliciting, gathering, and passing on user needs from those with more expertise, the project team has little to no hope of learning what they need to know. Sometimes the assignment of a Novice reflects a lack of project importance to the organization, or to some portion of it. Sometimes it reflects a lack of understanding of the importance of the lead user's role in a successful endeavor. In any case, the project manager needs to assess the situation, and may either attempt to have another user designated, or if that isn't feasible (people, politics), work with the user to help them plan and involve the necessary expert users in the process.
The Expert level of user knowledge is generally seen as desirable in a project. This person can bring a wealth of information to the table. Unfortunately, for some projects, particularly those that require integration, taken in the extreme, this user becomes uncompromising and fails to build consensus among their constituents. I've seen instances when the expert moved on to another position that the remaining users didn't feel the system met their needs, as they were never consulted or involved in the process. Even if the system actually meets their needs, the lack of involvement will prevent acknowledgment and agreement.
A middle of the road set of skills, coupled with recognition that one person doesn't have all the answers, and a willingness to involve others, seek their input and bounce ideas off them, leads to a more well-rounded and organizationally accepted solution.
User's Desire for Control
Irrespective of knowledge, the user's desire to control has a significant impact on the team working relationships and dynamics. That desire can range from none—the Pawn, to total dictation—the King. Desire for control is neither good nor bad in and of it-self—it's the consequences that count.
The Pawn, who refuses to make decisions, or stick by decisions once made (“whatever you say”), isn't doing either the users they represent or the project team any favors. The team needs a user that has a stake in the outcome and is willing to stand-up and be counted. Although on first blush, the pawn may appear to be the easiest user to deal with—tell them what to do and they do it, I submit that they are the true time bomb in the mix. If anything goes wrong, these are the first to say, “I just did what they told me to do (even if it was stupid).”
At the other extreme, the King, or user who seeks complete control may be unrealistic and unwilling to compromise, which is always necessary at some point in the project. While difficult to deal with, since this user expects to receive whatever they want when and how they want it, these can be some of the best relationships. As a project team, you aren't left to guess what is expected—you will generally know. By having expectations up front, you can then deal with them head-on.
The Pawn needs to become convinced that they care (or if they truly do not, then replaced), while the King needs to understand that others may bring valuable information to the table and have alternatives that should be considered.
Based on the combinations of these characteristics, the users can be classified into types:
• Visionary—out front leading the rest of us along
• Nuisance—doesn't contribute, just there to trip over
• Dictator—in the nastiest sense of the word, who wants everything their way, but doesn't have any grounding in reality on what is needed
• Saboteur—knows what is needed but refuses to share
• Partner—the middle ground and the most desirable (and common) situation.
Circumstances may cause one or the other characteristics to dominate a situation. Recognizing these basic types can help the team formulate project plans with appropriate actions to manage the user as well as the work.
Other characteristics important to understand about users include their background, communication skills, style preferences, and social skills. Sometimes harder to identify, is understanding from a career point of view how this project fits into the user's goals. For instance, if the role requires the user to forego assignments they see as critical to a promotion they've been working toward for three years, the likelihood of enthusiastic participation is pretty low. On the other hand, if this has been set as a clear goal in the steps of that promotion, you will feel the pressure to help them succeed (and hence, your team succeed).
User Life Cycle
The “user life cycle” starts with the project birth (that first all-important meeting, maybe even before the “kick-off”), through project closeout (hopefully a successful implementation), with a model of helping the users mature in parallel with the project work and demands. Keys to building good user relationships include:
• Awareness: knowing who the users are and acknowledging their presence/importance
• Desire for a good relationship
• Ongoing care and feeding—keeping it on the radar screen.
First, if the team doesn't understand who the users are, what their job function is, as well as their role in the project, then there is not a basis for the relationship. This knowledge and understanding is not automatic. It takes conscious action to clarify and explicitly state that relationship. It is like the woman who isn't sure if the salesman asked her to lunch as a date or in an effort to understand her company and gain more business. Ask. Put the question on the table, and gain mutual agreement. While it may be embarrassing to ask, imagine how much worse it is to find out later. It also says that you and the team cares. If the user spends 90% of their time on the road, and then meets with you the other 10%, acknowledging that with appreciation can go a long way to establishing good working relationships. On the other hand, if the user is supposed to be working full-time on the project, and the team rarely wants to deal with them feeling that they are intruding on the user's time, then the message the user gets may be one of rejection, rather than scheduling sensitivity.
The care and feeding of the relationship is the day-to-day interaction, as well s the occasional frank discussion of the process and how people are working together. For instance, asking “how is it going”—open ended, not just “where do you want this on the screen,” can lead to timely feedback and course corrections, before the relationship is lost in the woods.
Consider a user life cycle on the project to mirror a real life: from birth—that is identification for participation in a given project, through maturity and wisdom (we're hoping to avoid “death”) at the project completion. When successful, the user is engaged from the project initiation, grows through the full life cycle and involvement in appropriate process steps, and by conclusion is that “super user” that acts as a disciple of change, marketing agent, and general repository of wisdom on how to the make use of the new system or project product. This process, much like successful projects, teaches our teams to be better, while building users with skills to be ever more knowledgeable and effective participants in our mutual efforts.
Consider a simple project life cycle: initiation, requirements and design, development and testing, implementation, and then support. The user involvement can be parallel and is described for each.
Initiation collapses the birth through dating phases of life into one short phase. General information is shared, and mutual expectations developed. A level of compatibility is achieved, or the relationship ends. Phase transition occurs at the marriage or contract—when the project moves on to the next stage of the cycle.
During requirements and design, much like the first couple years of a marriage, the relationship is truly put to the test. Determining what each needs from the other, and how the work is done, is just as important as what work is done. This phase will set the tone for the future, and it will be very difficult to vary significantly from this pattern in later stages of either life cycle.
Development and testing can be likened to those middle years of a marriage, or the ones devoted to raising kids, making a career. The relationship can take a back seat to the work, but the fundamental soundness of that relationship is tested and relied upon to handle the various issues that arise. The relationship continues to need care and maintenance. Trust needs to exist before you get here: much of the project work becomes invisible for a period, and the user needs to have confidence that the right things are being done well, or the building stress can explode.
Implementation is when everything comes together. The results of your child rearing are tested as they leave the nest, or you hit that age where realistic expectations about career height are staring you in the face. The users see the results of the team's effort, including their contribution. Just as marriages that survived strictly for the sake of the kids fall apart, so do user relationships that weren't solid, and the results to the final project deliverable can be devastating for all—user and team. On the converse, in those cases of a job well done, with solid relationships, this becomes a time to celebrate and everyone reaps the rewards.
Support is the last step, and mirrors retirement in our life. The forethought that went into the years of savings lead to a lifestyle of comfort, or one of constant struggle to maintain. Be careful here not to confuse the normal evolution during this phase—new functionality and changing business needs—with a problematic core. Analysis of the activities can easily differentiate the two. There is one significant difference here than in real life. Successful teams and the learning from them should be recycled into subsequent projects, with everyone able to build upon that learning experience.
An essential component of the user/project team relationship throughout this life cycle is communications, and what I'll refer to as the 4 C's: Clarity, Correctness, Consistency, and Completeness.
Let's look at each in turn.
Clarity is whether the message and content is clear, unambiguous, and understandable. Clarity of documentation means that it must be written in such a manner that the users can understand, comprehend, and reasonably be expected to grasp not just the highlights but also the details. As most project professionals know, the details count. Clarity expands to encompass not just the message, but also the context for the message—why does the user want/need to know? Where does this fit in the process? What should the user expect to understand as a result of a review? Why does it matter? Without that context, the message may be clear to the receiver, but have nothing to do with the intent of the content.
Correctness is next: is the communication accurate? Information can be inaccurate for a number of reasons—misleading, vague, or just plain wrong. The wrong information has a tendency to live longer than correct information, often leading to festering issues. The time it takes to ensure correctness is repaid exponentially over the course of a project. It also sets an expectation of trustworthiness—what you say can be believed and counted upon.
Consistency of content, format, and presentation style support and reinforce the message. Users get accustomed to dealing with the format and information, knowing what can be found where. To help their understanding, the team should establish both actual and operational standards, with consistency of form and structure. This also applies to language: if a set of choices is called a “list of values,” that should be a constant term, and not used interchangeably with “choice list,” “selection list,” or other attempts at creative writing. While the thesaurus might have improved a grade back in English class, in the context of specifications it just increases the likelihood of confusion when applied for no reason other than variety.
Finally, consider completeness. Is everything said that needs to be? Are things left out, and covered by generalized statements? If so, are these omissions likely to cause confusion? For instance, in cases of a data conversion, saying “all other values default to null,” is not nearly as informative as listing the fields and explicitly declaring that they default to null. In the first instance, the user must trust that there isn't anything that matters to them. In the latter approach, the user has the information to positively confirm their agreement, with full knowledge (completeness) of the information.
Technology and Tools Impact
We have more “toys” than ever before available to work with. As our project life cycles change, and we move into the eCommerce world, what impact does that have on the users, who they are, how we work with them, and what “toys” we all play with? What can you and your team do to enhance rather than harming your efforts by using “toys”?
Personally, I feel that electronic mail has done more to decrease communications than anything else in the technology revolution. Yes, we get messages—but are they communications? Written word doesn't convey feelings. For example, consider the message:
“I don't know why you said that.”
What did this mean? What was the tone? If the emphasis in on “that,” does it mean something entirely different than if it in on “you”? Was it said sarcastically, or with true concern? Unfortunately, most people tend to jump to the most negative connotation when reviewing written materials. The good news? Technology is starting to catch up. In business, we would be well served to realize what the home user community has been up to with videoconferencing and live cameras.
Dealing with the Problems
Of course, there are always “special cases”—the belligerent, badly behaved user. This section lists some indicators that a problem may exist. If so, take action such as “calling it,” confronting, escalation, and sometimes, just patience while everyone catches up. Back to basics activities—goal and role re-identification, and communications are fundamental. Consider these indicators:
• Schedule slips
• Late or incomplete information
• Too quiet
• Changing targets and needs
• The “I don't remember” syndrome
• User and team avoidance of each other
• Forced humor.
Check in with your team and users. See if they feel there are any issues, suggestions, or concerns they'd like addressed. If so, jointly review the issues, and their suggestions on solutions. Agree on a joint action plan to resolve if appropriate. Focus on project and working issues, not personalities or people. Do not be afraid to use your resources, including an escalation to management, support from external QA and mediators. In unusual cases, personnel action may be warranted. The previous support from management and QA will probably be necessary for this step.
The Perfect User—Fact, not Fiction
Is there a perfect user—sure, I've had a few (two). Are they “yes sirs”—nope. Do they challenge, motivate, frustrate, and generally keep you on your toes—you bet! But, is life fun as a result? Sure is. Do we build better projects when challenged to “stretch”? In my case, yes. If you want one, is there a way to help your current user become the perfect user? I think so, and maybe they'll help you become the perfect project manager! (I'm not, but that doesn't mean I don't have a goal.) I feel the core competencies of a perfect user are:
• Knows their business and needs, and ability to articulate them—whether gathered from others or personal knowledge
• Ability to conceptualize and envision the future, and how the project will impact on it
• Unwillingness to accept you as expert without challenging any area they are uncomfortable with—questions in good faith
• Reads and reviews everything—makes sure it is “right”
• Doesn't accept “good enough”—strives for perfection
• Knows how to compromise and can differentiate and prioritize between critical, important, and nice-to-haves.
So how do you get one of these? Three methods that I know of—they are a “natural,” someone else trained them for you, or you need to educate them in these skills (although, some competencies, such as the ability to conceptualize, are not really “taught”). How? Review the list. Think about your key user. Do they have this skill? Is there anything you can do to help them develop it? For instance, when you give them something to review, do you encourage them to take it seriously and provide adequate time for them to analyze the material, or do you encourage a quick peek and just sign here? Remember, this is a two-way street. The same skills and competencies are important for you as a project manager.
Are all users “manageable”? Probably not. But in most if not all cases, some level of “acceptable” performance and working relationships can be achieved. Think about the points raised in this paper. How do they apply to you, your team, and your users? Take the time to step back periodically for a working relationship health-check, and keep these things in mind. And most of all, value the contribution from all members of the team, and reflect that value in your actions—you'll reap the rewards.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA