When are you done?

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!

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.


  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.