Personal Insights
Deep Thoughts – Does it matter “who” you are working with?
Does the “who” drive how you work? How not what priority. Do you work differently with them according to what you know about them?
Know your business users:
So if you know the person you are working with you can determine how to work with them based upon different things. I tend to in general group them into 4 different groups in my mind.
Group 1: The problem is exactly as they stated almost all of the time.
Group 2: It may or may not be an issue. After around 2 hours they figure it out.
Group 3: Usually they just need training. Of course, you have to prove it by the data.
Group 4: Will never believe you.
I’m sure there other groups. Of course, people change groups depending on what area they are working in. And of course the day might make a difference or the weather or… But in general you know them well enough to know what group they fall into.
The Break/Fix:
Group 1:
Ask them about it. Have them tell you what they think isn’t working and get to work looking at your code or your configuration.
Group 2:
If you have to fix it quickly – then you’ll want to do the same as group 1. If you can wait a bit, then do so, the problem may not be an issue. If it still is, I start by looking at the data. The code/configuration comes next.
Group 3:
Start with the data. Ask them exactly how they did something. Skype is my friend at that point. Dig around, usually you’ll find the issue. If not then back to the code/config. It may be that you would want to put together some training documents.
Group 4:
I have to love this group. Why? Because they are so very cynical. If you can get some examples from them. If not start by calling a co-worker that does the same job from one of the other groups. If you get the examples it’s hard to know if it is data or it is code/config. I try data, but if it doesn’t show up soon enough – right on to the code/config. Once you find the error (training, bad data, or code/config) you’ll try to explain they might surprise you and fall into one of the other groups. If not, you’ll have to phone a friend. Show a co-worker the change, training… Then ask they to show the person in group 4.
New Project – Requirements:
Group 1:
Yes! Fist pump. They usually know what they want. They can explain it well too. i usually still have some questions, but things move rather quickly. I’ll let them lead and then ask the questions I have.
Group 2:
This is still a great group to work with. They know what they want. However, I spend more time on the questions. I try to draw things out so they know exactly what the project will look like. In my own scribbles at this point.
Group 3:
I start with getting a general idea from them. I generally get this before a meeting. Then I draw something up. Next meet with them and ask questions. Refine the drawing and more questions. Remember this is just the beginning.
Group 4:
Phone a friend. Get more than just that group in the meeting with you. Then basically I follow the same route as group 3. I meet with them before the meeting. Next I’ll have a general idea and meet with my friend before the meeting. If at all possible have your friend with you at the meeting.
All of the rest of the requirement steps are the same for all of them. I usually have a straw man drawn out before the requirements are complete, but that depends on the size of the project.
Documentation:
Who loves documentation? Well actually I do. I just don’t love creating it. But if a question is coming up many times, it makes sense to create some training documents. I do that. Then based on questions about the document, I will refine it. For new projects – it depends on how big they are. If it is big enough, their are people dedicated to creating it. Otherwise it becomes very important to have some training documents. You’ll find that there will be questions and perhaps new requirements from them. Depending on the request it may be set up as an enhancement for a later date.
And yes, I try to create functional requirements, technical requirements, test documents AND training documents. There sometimes just isn’t enough time. You might argue I have to have them all before I start. I do have the functional requirements before I start usually written by me.
Does it matter to you?
So for me, sometimes who you are matters to me. Honestly if you are one of the people at the top of the food chain and you say drop everything, I will. If you have a requirement it is met. The first time if at all possible.
It matters who I work with. They change groups depending on what I’m working on. But it is a huge benefit to know how they work.
Now I hope to generate many comments. Does who you work with, matter? Are there more groups you would add?
Side Note:
Yes, I have read – “Who Moved my Cheese“. Well worth the read.
I read this nodding my head - and then I had the thought when I have to pass work on to other SAP Teams which group do they see me in.
Interesting. I wonder where I would fit in different projects. 🙂
Mhh, I like the idea of grouping. I had a group less. Like, don't like and don't care. After the blog, with comments, I also wonder what these are thinking about me?
Oh boy - don't care. I bet you do, you just don't know your doing it. 😉
I've had to deal with many people all over this spectrum and then some but I don't really try to group them or think of them this way. Of course, when you work with someone (be it for years or for a couple of tickets) you immediately form an impression of them, it's a human nature. And, just like parents have a favorite child, IT has favorite customers. That's why in my old job I've always been shamelessly buttering up the Help Desk guys with cookies and flattery.
Have a clear requirements, test quickly and close the ticket with a "thank you"? Rest assured your next request won't be sitting unassigned pretending we're super busy. Complain forever, change the spec 5 times, then have "no time to test" for 3 months - next time no one will want to work on your request. This is pretty much like mafia. Gee, thanks for blowing our cover, Michelle! 🙂
LOL - so very true. All of it. Yes, to some degree we all decide at different points what we will work on. Yes, I don't really write down the name and say "YOU" are in that group. Like you I just in general know. But I was discussing this with a team member. When explain to her why the person she was working with would require much more questions to get a better requirement.
She, as all of us, didn't get the full requirement. I never have. Someday....
Thank you for the comment and the laugh on a Monday Morning!
Michelle
Interesting thoughts, Michelle!
For me, it really helps to "know your audience" and to have at least some idea how much tech-speak they are likely to understand. Among my colleagues in the process teams, who usually tackle customizing tasks and have direct contact with the end-users, are some who have a programming background. With them, it's obviously easier to talk shop and they also don't shy away if you mention activities like "debugging" or "SQL-trace".
I'm in the development team and therefore don't have as much direct contact with the end-users as members of our process teams have. But, we are nonetheless aware of some "special customers" or as we colloquially call them "our Pappenheimer", some of whom are notorious in wanting something done "by yesterday" and who - if you provide it as quickly as was possible - then don't find/make the time to properly test it, having changes linger for quite some time in the test systems. Not necessarily an indication that it actually needed to be addressed urgently and something we tend to bear in mind next time they need/want something done quickly.
On the other hand, I try to avoid pigeonholing people as much as possible and - as it cannot really be avoided completely - to at the very least base it on my own experience instead of relying on other people's accounts.
Cheers
Bärbel
Totally agree with everything you wrote. 😉 What's more interesting is that at times I don't realize what I've done.
Speaking to the audience! Yes, yes, yes... Again sometimes I forget and throw in something like Eclipse. When I get blank looks, that's when I know I have "done it again". It's easier when it's a presentation. It's hard when it's a quick chat in the break room. Or when it's a quick Skype with someone and you are waiting for a response. If it never comes - I have to think about what I just said.
Pigeonholing, I think I've done that before. More than I want to admit. However, I did say they moved from group to group depending on the subject. It really isn't a conscious decision. I don't think to myself you are in this group. But I do notice a difference.
Have a great one!
Michelle
I learned something - hence I can call it a day. Not really but interesting colloquial. I really liked that you nicely set up a link for me.
Ever wonder what I do at work? I will call myself a developer. In fact I think that’s my title. However, I’m working for a small company. So I do just about everything SAPish. I did get to work with BASIS too, but sadly that was outsourced. (Ouch, I said a bad word. Hopefully that never happens to me, or to you reading this. It's happened a couple of times to me. Don't want a number three.)
What does that mean? I know a something about the different processes done where I work. What I don’t know, I ask. I know more about development, but not as deeply as many here. What I don’t know – I have my friend google to help me. I end up here! (or in the archives) OK, so I do that with the different processes too.
I bet you know something about business process too! You aren't just a developer. There isn't such a thing as just a developer.
MMMMmmmm.... I'm wordy today.
Hi Michelle,
well, I only said that I'm in the development team ? and you are of course quite correct that I'm not "just" a developer. Matter of fact, I spend the least amount of my time on coding stuff as I'm looking after our development guidelines, am responsible for our ATC-checks via a central system, do the coordination of incoming development work and "dabble" with Atlassian's Confluence and JIRA to help with all of that. Quite a neat mixture and combination of things! I just have to make sure to not forget how to program! ?
Cheers
Bärbel
This describes many of the business users I deal with in my workplace to a T. While we (or I) haven't explicitly classified folks this way, nevertheless we definitely subconsciously group them something like this, and adjust how we deal with them, too. Wish we had more in Group 1 or even Group 2! Unfortunately, most of our folks are probably in Group 3, and Group 4... well, group 4 includes some directors and executives. That's a bit of a problem, and we have an initiative specifically designed to change some of the thinking for that group.
And, like Florian, Sarah's comment made me introspect a little... how do others group me? Not a bad idea for all of us to step back and reflect on this question once in a while.
Glad I'm not the only one who thinks this way. Group 3 or Group 4 that's bad especially when you are talking at director/executive level. Those are the people that all requests are treated as a high priority. Lucky for me, most of mine fall into 1 or 2. Of course they do move around.
Yes - as I reflect on that... It does make me hyper aware now. It actually made me change the way I work slightly. I'm always working on that thing, you know that thing - Listen first. Don't think of answering anything until the speaker is done.
So yes, I reflect on that based on some excellent comments!