Tag Archives: process improvement

When change doesn’t go your way

by

There are always opportunities for improvement…”harder, better, faster, stronger.” That said, everything you try isn’t going to work out. Cliche, I know but still true. I had an experience outside the corporate environment recently that is having me to reflect on what went wrong, what i would change (or not) and how to recover quickly.

change-all-thingsI have been leading an external effort with a big goal. My team is composed of many volunteers all working towards the same goal. As part of this initiative, we just completed a multi-faceted online/offline marketing initiative. There was a solid group of volunteers working on these initiatives and they really did a good job. Logistically, we pulled off a larger initiative that in previous years. Unfortunately, despite the hard work of the volunteers, the outcomes were not what was expected or hoped for. As I was getting real-time updates during the execution phase, I started to realize that we might not see the results we had projected. We reacted quickly and made adjustments to the execution plan. Even so, the results were underwhelming.

What now? While I was saddened by the results, all I can do, and all I can encourage my project team to do is learn from the experience and move on. Here’s how I’ll approach this post mortem:

Remember that people put effort and emotion into executing change. It’s very important to remember not to point blame. This should be treated as a learning opportunity for everyone. 

  • Determination of too much or too little – This is the evaluation of the prep & execution plans to determine whether you did too much or not enough.
  • Support – Did you get the support you needed across the organization? Did everyone buy in? Did everyone do their part? Where did the breakdown occur? How could more support have been provided.
  • Eliminate technical issues as a cause – This involves checking each and every one of technical component (software, hardware, etc) that could have had issues. To the best of our knowledge, are they in working order now? were they in working order at the time of execution? “Working order” encompasses both the physical “did it work” and “did it perform its function?”
  • External factors – Were there external factors that could have impacted your plan? Common ones might be weather, mergers and acquisitions, politics, etc. Some times these do just get in the way. The goal is to identify the ones that impacted you this time, and review those risks the next time
  • Get up again – Ok, so this plan didn’t work out. It has no bearing on the next plan, or even the continuation of the current plan. We take what we’ve learned and apply it to the next round.

The success or failure of a project isn’t solely in the hands of the project team members. The entire project team, including the direct and indirect stakeholders have responsibility to provide the support needed. Further, it is the broader stakeholders that need to help pick the team back up and give them the leeway they need to make improvements the next time around.

 

 

 

When are you done?

by

it-compiles-ship-itAs a paranoid project manager, I will conduct my own validation before communicating to customers. There have been too many times where I have not done this extra validation and sent it to the customer who immediately identified obvious issues. That doesn’t help anyone during a project implementation. And actually, it can cause serious credibility issues with the stakeholders.

For me, a task is done when I can demonstrate that the requirements are met or the issue is resolved. I’m not talking about the detailed nuances that are found the stakeholder does their deep dive into the solution. I’m also not talking about the scenarios where we have set the foundation early on that the validation would be collaborative in nature. However, I’m finding that the ability to follow through and conduct basic validation before communicating it’s done is a skill. And it’s one definitely not found in my teenage daughters and in many adults. I’ll walk through two quick examples, before I set some guidelines.

My husband pays my teenage daughter, Cayla, to do his laundry. Every week, I over-hear the same conversation. “Is my laundry done?” from Carson to Cayla. Once Cayla confirms, the follow up is either “so why don’t I have any socks (or whatever)?” or “then where is my basket (as it hasn’t been returned to our room)?” For the most part, Cayla has done the majority of the work, she just didn’t fully follow through. This could mean the laundry has been washed, folded and put away but the baskets not returned; or just washed and in a pile downstairs; or some other variation on an incomplete status.

In the workplace, I’ve seen lots of examples of this. A project team member will hand over what is supposed to be a complete deliverable, but I can’t get it to run, or it doesn’t meet the basic requirements. I’ve heard all sorts of excuses as justification throughout the years: “it’s done but not complete”; “it compiled so I thought it would work”, “I installed it but didn’t configure it”, “I finished one piece of it”, “it works if you do x, y and z  (even if that’s not the logical use)”

So, when are you done? I think there a few critical components that project team members should be consider before marking something as complete.

  • Available – The solution must be available in a form to distribute to the business user. Even if it’s something you are developing and installing on their behalf, there should be a tangible output to show for it.
  • Configured – Having a solution installed is often not enough. Is the solution configured as required to meet the customer needs? or in a state where the customer can configure it themselves?
  • Validated – Have you followed the steps the user would use to interact with the solution? Have you ensured the workflow makes sense, the solution does what it needs to and produces output that is as correct as you can determine (sometimes it is just doing a gut check on the output or making sure the user interface works for the inputs).

This is one of the most frustrating components of projects from a customer perspective. We all need to take ownership of the work we do and make sure we are doing some form of validation against the requirements and against basic usability. Does your solution do what the requirements define it should. I understand that not everyone has the business context, but own the functional requirements of whatever you’re developing.

3 Signs you over-thought it!

by

How often are we faced with a system, process or application that leaves you frustrated and confused? Based on my own experiences this week, and that of many of my friends (thanks social media), it occurs pretty frequently. Feeling inspired by all this disfunction leaves me thinking about how we can quickly assess whether we have made it overly complex.

over-engineered-system

  1. It’s difficult to maintain – A well designed process or system is one that is easy to understand it’s purpose, and intuitive enough (or simply documented enough) for someone to maintain it. Our environments are not stagnant so we can expect our processes or systems to be.
  2. Users complain about it (or just don’t use it) – Processes and systems are designed to solve a business problem. If we make them so complicated and cumbersome users won’t use it, and if there is no other choice, will complain relentlessly about doing so. If the system or process requires more people to enforce it, then it’s time to take another look.
  3. It’s not delivering the quantifiable measure of success you thought – Again, you implemented this to solve a business problem. Hopefully, you defined a measure of success. If you are only seeing marginal improvement, or even a decline in performance against the business problem, this is highly indicative of having over-thought your solution. It’s may be time to start over.

I don’t think overly complicated systems or processes come from a malicious place, however they can be detrimental to the overall success. Be conscious of these warning signs and be aggressive if fixing these. It will make for a better overall user experience improving morale and positively impacting the bottom line.

To read more on this topic, see these blog posts by Gregory C. Smith, Code Simplicity, and David Meehan.