-2

I was tasked with a rather open-ended assignment: to document the workflow processes of my organization. I spoke with my coworkers and boss and concluded that this task would not only cover programming-related documentation, but also office workflows of past, present, and future tasks.

As a recent-hire, my ability to modify behavior and habits are limited. However, this does not mean I am unable to influence behavior and habits. I've done some research on the subject on the Workplace:

To name a couple.

My current strategy is to identify tools and software that are currently available to the organization, namely office 365, and start to utilize the tools to my current assigned projects and assignments (Planner, Yammer, Flow) and then invite project teammates to the service. Essentially, hook: invite, line: let's collaborate and keep track of things, sinker: let us start to use the tool for other projects.

The contents of my research have me to conclude that much of the best-practices is to present the needs as a cost-benefit comparison and how it will impact the organization as a whole (increase efficiency, tracking, etc...) I have high confidence that this method would work from a top-down approach. i.e. Management, after reviewing my analysis and proposals, will then make a decision and then implement from the top-down.

What I see as a missed opportunity in their answers is:

  • How do I create buy-in and influence coworkers as an equal, innocuously?

Update as of 2017-09-25

Brief update as it has been a couple months since I've started. Given the advice from this question, I've thought about Thomas' suggestions seriously and I've introduced Microsoft Planner into the task-management side of things for the office.

Results:

  • There is buy-in, but utilization is limited to the data-oriented side of the shop, as most have their personal means of task management.
  • I did not impose the tool on anyone, it was more along the lines of "this is how I track things, feel free to try it out or not, if you have any questions, let me know and I'll help"

Now that I have a means of keeping track of what was done, the next step would be how it is done. My current plan is to use a wiki-based documentation for workflow processes. I've gotten permission to execute, but implementation is currently on the back-burner until current projects complete.

|improve this question

closed as too broad by Jim G., Michael Grubey, Chris E, gnat, mcknz Aug 8 '17 at 16:49

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Thanks to enderland for the edit to emphasize the question. – Frank FYC Aug 7 '17 at 22:17
  • Not a full answer, but a point to consider: Convey that the more thoroughly a workflow is documented, the more aware management will be of the resources required by that workflow, and thus - materials, staff, and budget allocations that would be required. – Wesley Long Aug 7 '17 at 22:27
  • @WesleyLong Thanks, I certainly did not think of that. – Frank FYC Aug 7 '17 at 22:32
  • I saw the task threefold: document the past, present, the future. But to reduce the need for an active documentation task, the goal is to introduce an environment where people have already integrated tools into their day-to-day activities that well... document what they've done to make the documentation task itself self-fulfilling as part of their routine practices. Metaphor, there is a tub full of water (documentation tasks), I am tasked with draining the tub, but the spigot keeps flowing; to both reduce the flow and reduce the need to drain, I need to influence behavior. – Frank FYC Aug 7 '17 at 23:23
  • @JoeStrazzere Understood, ensuring management buy-in would be essential, unfortunately there are many projects running concurrently with many employees wearing multiple hats, so the documentation gets back-logged. My goal was to both reduce the current pile and try to subtly introduce a mechanism to reduce the rate of pile up. – Frank FYC Aug 8 '17 at 3:17
3

From your first paragraph, you say that you were tasked with documenting the workflow and processes in your organization. Somehow, this inflated into documenting past and future states.

I'm not sure how this happened, but as someone who has worked in process improvement: focus on the current state first. In traditional continuous improvement techniques, one of the first things that you want to do is to document the current state. A good tool to do this would be a SIPOC, value stream maps or business process maps and RACI matrices for your key processes from your SIPOC.

That would achieve your objective to document the processes that exist.

Looking at past processes isn't generally that useful, unless you understand a lot more context (such as why you changed) and have good, empirical data about the quality of the processes in the past states.

The next steps in CI really need to be a team process. This is especially true since you are new to the organization. But once you have mapped your processes, you can begin to capture data. Identify areas in the process with long processing times or long lead times that can be reduced. Look at where mistakes are made (find where someone in a down-stream activity has to go back to someone involved in an up-stream activity for help or cases where the work needs to be redone) and attempt to mistake-proof the process. You can identify areas of improvement and use root cause analysis to determine why the problems exist and what solutions would provide the most effective solutions.

I'm concerned that your initial thought is to identify tools and use them. Tools should support the process and not the other way around. Right now, work is being done using some kind of tool, or perhaps a combination of tools. Your documentation of processes used should look at what tools are being used. Depending on what you find, there may be good reasons for how things are done. Or perhaps you'll find that some tools that the organization uses don't meet the needs of the people doing the work.

I think that you need to take a step back. Focus on the first task - document the processes and workflows. Then, once you have everything laid out, look for ways to improve and go after the most meaningful improvements, balancing impact versus the ability (time, cost) to implement those improvements. But involve the entire team when improving processes.

The best way to improve processes is not top-down, but bottom-up. However, some changes may be mandated top-down (for example - identifying and using common tools to save on licensing costs or legal requirements that must be met).

|improve this answer
  • Thanks thomas, I understand the approach that you are advocating. My comment is that this approach would work very well from a consultation-client relationship: Sit, listen, and observe current practices; see what works well and what does not; identify tools that would support the process and make overall improvements. But how would it work for someone in the thick of it? – Frank FYC Aug 7 '17 at 23:35
  • @FrankFYC The same way. I've never been in a consultant-client relation. I've only worked in continuous improvement as an employee, and also while holding a role where I also did the work that was being improved. In fact, the best people to identify problems in a process and work with the other stakeholders are the people who are in the thick of it. – Thomas Owens Aug 7 '17 at 23:39
  • Understood and will do. This would be new territory for me, I will read what you've suggested and incorporate it into my strategy. – Frank FYC Aug 8 '17 at 0:19
6

I have Asperger's syndrome, so every last piece of social interaction I learned, I had to study carefully. This is what works for me:

1) Always set up the win-win. People are very likely to agree with you when you align your interests with theirs

2)Talk in terms the other person understands. People are more likely to reject something they are uncomfortable with or don't understand. Put it in their terms to avoid this roadblock.

3)Think in terms of the other person's needs. How will doing things your way benefit them. Everyone's favorite radio station is WIIFM (What's in it for me) see #1

4)Dramatize your ideas: Present them passionately, others won't get excited unless you do.

5)Present multiple options, with yours as the best. I used to do this as management when there was serious tasks that needed to be addressed. I would present several options, with an undesirable one included.

6)Guided realization. Ask the person leading questions that will guide them to the same conclusions you reached. "Hey, I was comparing these two programs, this one takes 40 seconds to run, this one takes 23 minutes. They both generate the same output, which do you like better". I know that this is an obvious example, but you can apply it with much more subtlety.

7)Ask people for help deciding things. Again, people will be far more invested in something they think is their own idea.

|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.