Friday, November 7, 2014

Don't become this organization...

I was chatting with a colleague in change management a few years ago and she started telling me an interesting story.

She was working with a financial services company and discussing a specific process where the "end result" was a financial report that was run and then added to a folder on a shared drive. The reason I say "end result" is because no one knew what occurred with the report or how it was used after it was posted on the drive. Ultimately, after additional research my colleague realized no one used the report, at least not in the present day. So basically someone made an effort to run this report on a weekly basis and uploaded to a folder on a shared drive which was never used. This may seem like a simple example but imagine how many other instances similar efforts are made to continue a practice without questioning the purpose. Not only is it a waste of time and resources (employees, memory space) but leaving a report in a shared drive could potentially be a security risk from a data and access perspective.

It's important to:


  • Challenge Processes - even if the process is currently optimal at least you've gained an understanding of the steps and in the future may be able to improve upon it
  • Think & Improve - if there's a manual process and it can be automated, automate it
  • Be Change Management - evangelize improvements, people will get on board faster and/or come up with a better route


This changed my perspective of how I viewed things. Earlier in my career I always assumed if something was done a certain way there must be a good reason for it. Now I realize most times current employees do not think it through and generally think that since it's already being done it must be correct. Act like a stakeholder because ultimately all employees are.

Thursday, November 6, 2014

Methodology

As I moved from project to project I noticed, without fail, one process was always used. It didn't matter who the client was, how long the timeline was or how small/large the team was. Methodology was expected and followed. There was never a point in time where we just went ahead and dived in because, what I realized ultimately was, without planning how would the team even have a good grasp of what the tasks were? Even if the team did - who did what,when, and how? I've used many different methodologies across numerous projects and have streamlined it to these essential steps:




This diagram shows the essential steps (depending on project steps can be added, e.g. Deploy)

Plan/Analyze: Develop a timeline, determine key stakeholders, analyze requirements, determine scope and plan key activities

Design: Consists heavily of documenting, prototyping based on requirements, current needs, and future needs. This is where business requirements documents, functional requirements documents, technical requirements documents, product requirements documents are built.

Build: Development based on documentation and discussions, a lot of configuration, a lot of programming and a ton of back and forth between groups.

Test: Critical to test to make sure the product aligns to the design and needs.

One thing I noticed is these steps are generally iterative, it's never step A to step B. Sometimes you will be building -> testing -> building -> testing -> designing -> building -> testing, until everything comes together as expected. Every step is critical to ensure that the end product aligns to the end goal.



Why is the process not optimal?

From my experience as a consultant I saw many different reasons that contributed to inefficient processes:

  • Fast growth company, no time to optimize processes during high growth
  • System changes but process remains the same (which could lead to a very customized system)
  • Process changes due to a system change without consideration for the best way to update the process
  • The right stakeholders are not making the decisions (more than anything there generally isn't a stakeholder that is responsible for this, everyone is always looking externally towards the products/services)
All of these reasons seem relatively simple but this is an issue all companies face big or small. Some of the most forward thinking companies still have an antiquated operations process. Google just recently switched over to Workday from using their homegrown systems and I believe Apple is still on SAP.

Wednesday, August 27, 2014

Introduction

I created this blog as a way to keep track of the key concepts I have learnt across my career as a consultant. This blog will mainly focus on optimizing processes but may delve into other areas that are just as beneficial. I started my consulting career at Accenture and was fortunate enough to be on projects where I was designing the future state versus working on trying to fit in something new into something old. I believe changing processes/the way things are done at companies can be a huge game changer and hopefully this blog will give you the insight to change something for the better.