A Project Management Article by Michiko Diby, PMP
Here’s something I hear a lot in IT development teams:
- Users don’t know what they want
- Users are always changing the requirements
The other day I sat in a meeting with a development team PM and her client. The system, mind you, is already built, but not yet live. I listened, incredulously, as the users asked for one new requirement after another. It was like watching children go nuts in the grocery store while the slightly clueless parent says “Please Johnny don’t.” I was embarrassed for the PM because, quite frankly, she had done a very poor job of managing her users.
Now don’t get me wrong, this article is not a rant on users. Rather it’s a plea to PMs to recognize, respect and manage the often unspoken, but quite real, basic needs of users. To be fair, you’ve probably never heard of these basic needs; I found out about them during an ‘aha’ moment while watching Supernnanny. My theory is that the user’s behavior is a direct reflection on the PM’s user management skills; well managed users are pleasant, easy to talk to, and respectful. Poorly managed users are unruly and want what they want, when they want it, and don’t give a dang about resources, time or cost. Said another way, a PM skilled in user management will never hear their developers say ‘users are always changing requirements.’
I’ve learned a lot about user management by watching Supernanny. Supernanny’s theory is that children have fear based basic needs, and that poor behavior is sourced from parenting that doesn’t meet those needs. These basic needs are:
- The Need for Safety – or knowing what’s going to happen next
- The Need for Contribution – or being heard and respected for their input
- The Need for Authority – or knowing that life is fair and authority recognizes good and disciplines bad
Usually, parents featured on Supernanny have failed to set up consistent processes, failed to allow children to contribute within these processes, and failed to demonstrate fair authority. So Supernnany winds up training the parents how to meet the children’s needs for Safety, Contribution and Authority. Inevitably, the children become well behaved once the parents have implemented processes and rules to address the needs.
In our working world, our users generally have the same need for Safety, Contribution and Authority.
Put yourself in the user’s shoes. From a user’s perspective, an IT project is a scary thing. It’s all about change; ie new processes and new systems, for which they are on the hook for explaining what they want, all of the sudden. And it’s all about new relationships and hierarchies; ie an unfamiliar new group of people (the project team), and maybe being thrown together with other users from other departments, with whom they’ve never had to work. As a user, you feel that there’s no guarantee that the project team will understand your needs, and there’s no guarantee that the project team will build what you need them to build. On the other hand, there is a guarantee that you will have to spend time with the project team, knowing that in the end, the whole thing could fail. It’s a bad combination of fear of the change, fear of being invisible and fear of failure.
The best thing an IT PM can do, for herself and her team, is to alleviate these fears. If you don’t, you will wind up with unruly users. Unruly users will give you requirements all the time because they don’t know if you’ve heard them, if and when they’ll next get to speak to you and if you will allow them to contribute.
So how do you tame the unruly user? By meeting their Safety, Contribution and Authority needs.
Meeting the Safety Need
The Safety Need is all about understanding what’s going to happen next. This reduces fear of the unknown and of change. Think of it as ‘Always be Reminding’. A lot us hold a project kickoff meeting that explain our process, but we don’t really cover the process again as the project moves forward. We should always be reminding our customers what our process is.
When we give a status, reference the process. And keep it jargon-free. Here’s what OK, Good and Outstanding sounds like in meeting the Safety Need:
OK: Provides information but doesn’t describe the process
‘We are 90% complete with system testing’
Good: Provides information, includes process reminders, but still has jargon
‘We are 90% complete with system testing. As you will recall, system test precedes UAT”
Outstanding: Provides information, includes process reminders, and is de-jargonized
‘We are 90% complete with system testing. As you will recall, this is the part of the process where we make sure the system works like you intend it to. The next step will be when we turn the system over to you for so that you can verify system functionality using real-life situations.’
Meeting the Contribution Need
The Contribution Need is all about being able to have a say and being respected for what you have to say. This reduces the fear of being invisible, and in the IT sphere, it reduces the fear that the end product won’t do what you want it to do.
There’s a lot of this fear going on out there because of lots of project fail. So, understand that the user’s initial reaction to you may be in response to another project. It’s up to you to set the tone early, and to explain to users that all their contributions will be noted, and noted in a way that is consistent, documented and well thought-out.
Here’s what OK, Good and Outstanding looks like in meeting the Contribution Need:
OK: Basic contribution tracking
The user’s contribution is noted in a tracking log.
Good: Contribution tracking with immediate acknowledgement
The user’s contribution is noted in a tracking log, and the tracking information is immediately communicated back to the user, and analyzed by the project team.
Outstanding: Contribution tracking with immediate acknowledgement, analysis and Discussion
The user’s contribution is noted in a tracking log, and the tracking information is immediately communicated back to the user, analyzed by the project team, noted in the next project status meeting and discussed with the customer at the next project status meeting.
|User Need||Addresses||Key Phrase||OK||Good||Outstanding|
|Safety||Fear of the Unknown and Change||Always Be Reminding||Provides information but doesn’t describe the process||Provides information, includes process reminders, but still has jargon||Provides information, includes process reminders, and is de-jargonized|
|Contribution||Fear of being Invisible and not respected||Respect Contributions||Basic contribution tracking||Contribution tracking with immediate acknowledgement||Contribution tracking with immediate acknowledgement, analysis and Discussion|
|Authority||Others may have an unfair advantage||Enforce Safety and Contribution needs||Users sometimes trust the project team but will ignore rules due to lack of trust||Users understand the process and trust the project team most of the time.||Users understand and support the process, and fully trust and support the project team|
Meeting the Authority Need
The Authority Need is about knowing that the process is fair and that authority recognizes good and disciplines bad. In other words, there are rules and the rules are enforced. Enforcing the rules reduces the fear that others may have an unfair advantage. Because if, as a user, I’m thinking that I’m following process, but another user is not, and said other user is getting more stuff than me, I’m going to stop following the process too. On a practical level, it is extremely important that everyone knows the rules and that you, as the PM, enforce them.
As an anecdote, I once was privy to an enterprise service level agreement between network engineering and their user base, that specified response times to problems by the severity of the issue and the importance of the person making the call. Incredibly, a VIPs email issue could trump a developer’s data issue. That is just wrong. And, it created an environment of great distrust and animosity.
This is to be avoided. Here’s the key: you’ve met the Authority Need to the degree that you’ve enforced rules that meet the Safety and Contribution Needs. There’s a positive dependency among these three needs; the better you’ve meet the needs for Safety and Contribution, the better you’ve met the Authority need.
To illustrate, let’s take a common scenario. In the project status meeting, Bob says “I would like the system to do a, b, and c – this is a hot issue for us, congress is breathing down our necks and we need that functionality like tomorrow”. As a PM your response will probably be, “Well, Bob, did you create an ticket for that?”
Here’s what OK, good and outstanding user response looks like based on your success in meeting safety and contribution needs:
OK: PM has done an OK job of meeting safety and contribution needs
“Yeah, but last time you all didn’t do anything with that for days. I never got an issue number or anything. I need this done now!!! (waaahhhhhnnnnnnn)
Good: PM has done a good job of meeting safety and contribution needs
“Yeah, I got a ticket number that’s it. But you didn’t tell me it would be a problem!? And now you’re telling me it’s going to take two days?”
Outstanding: PM has done an outstanding job of meeting safety and contribution needs
“Yeah, and I told my boss that we have a change management process that protects us from crazy code. So I understand it can’t be immediate response. But I do need this to be one of your high priorities. Thanks for your email on the level of effort. Let’s talk about that.”
Don’t look at me like that! It is possible to have users who speak like this. You just have to meet their needs.
Meet the user’s Safety Needs by being consistent with process, meet their Contribution Needs by having a repeatable process for input and feedback and meet their Authority Needs by being enforcing the rules, farily. You will reap the results and never be embarrassed by your unruly users again.
Note: this article reflects the viewpoint of the author, Michiko Diby, PMP, and does not necessarily represent the views of PMIWDC. If you disagree with or object to the views expressed here, please let us know