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.

What’s the virtual candy jar?

Years ago my friend, mentor and boss introduced me to the simple wonders of the candy jar effect. If you have a jar, basket, drawer, etc always supplied with candy, people across the organization will come to you. This is a great and super easy way to find out what’s going on in other parts of the organization, and with people in general. It also helps you develop an idea of what they like, so you can come bearing gifts when you need some assistance.

That said, I haven’t worked in an office full-time since 2008. With that in mind, I try to make sure i’m extra communicative. But, what about everyone else? Flexible work schedules are becoming more and more the norm, so how do you keep pulse on the organization and obtain all that knowledge you would have gained had you been in the office with a candy jar?

I have two separate thoughts on this spanning both sides of the spectrum. On one hand, I would argue that the people who are most effective in working remotely are often times their own “candy jar.” In my case, I find that people come to me with questions because they believe I have something to contribute. This allows me to get some of that additional information and continue to foster those connections outside of the immediate people I work with day in and day out.

But not everyone does a great job working remotely. I have had team members who were extremely difficult to figure out. Even the basics of determining exactly what they were working on, or how a project was progressing was difficult to ascertain. In this situation, I tried the daily stand up call. That helped a bit, but that was all the communication I got in the 24 hour period, unless I initiated it. An additional problem with the daily stand up call is that it gives you insights into the very specific yesterday’s work, today’s work and any roadblocks but doesn’t necessarily allow you to get a pulse on how the person is feeling.

As a manager, I think it’s my job to know what’s going on with my team. As a project manager, you may not be responsible for the team members but it’s still important for you to know the general pulse of the team. But in lieu of a better option, I think I’m stuck with doing my part to check in and ask. I’d love to hear if you have better suggestions.

What’s your virtual candy jar?

Semi-homemade is better than bespoke for data analytics

I read a product review this week where the company referred to themselves as a provider of “bespoke” data analytics. I had never heard that term used in the context of data analytics, or software specifically. However, when I googled the term, I found many companies using it in their marketing language, but no reference to it by the people who write about data analytics or software. This led me to start thinking about my experiences managing data integration software projects and how my customers view the solutions.

The projects that I’ve worked on in the last couple of years have primarily been data integration projects where we are combining multiple datasources into a single data warehouse and then leveraging that data to deliver data insights. The platform has some standard integration components that you can leverage, but there is also room for quite a bit of custom development. In every implementation, I have had conversations about what “standard” tools are available and what capabilities can be developed custom. On one hand, once these customers start reviewing the available tools, the first questions asked are usually about how we can customize those tools to their business. Each customer self-identifies as a unique even though most are within the same overall industry. There are always unique scenarios for each customer that needs to be accounted for.



On the other hand, customization takes time and effort, regardless of whether the work is done in house or by external consultants. Where does that leave us if our customers want/need something specific to their business but don’t want or can’t invest the time and money to do so?

I think as integration partners, we are probably looking at the entire product management and implementation process incorrectly. Our customers need a balance of standard tools that they can quickly customize to their specific needs along with partners who will work with them to develop custom solutions for new or innovative work. This is similar to the idea of leveraging a template to develop your website, but then be able to customize your experience by changing colors or adding widgets that extend the template capabilities. We can think of these types of products as “semi-homemade.”

Semi-homemade is a term used heavily by Sandra Lee regarding her cooking style. She leverages pantry staples and other ingredients and creates amazing dishes. By not having everything made from scratch, Sandra Lee reduces the cooking & prep time but is still able to deliver tasty dishes people want to eat. If we apply the same principles to data analytics, I think we can definitely leverage some basic tools that we allow people to extend or meld, which result in delivering data insights without the pain of everything being a custom solution.

It’s time to shift our mindset away from solely developing out of the box solutions, or solely developing custom solutions. Product and services should be working together to build base tools that are easily extended to meet the changing needs of our customers. We won’t totally eliminate the need for custom solutions, or new products for that matter. But we will more quickly be able to meet the changing needs of our customers.


No one way…balancing “being different” with best practices

At some point while managing every project, I end up having a conversation with the customer about how different they are from their competitors. Each organization can list a dozen reasons about why and how they are different. This is often used as an excuse for why something can’t or shouldn’t be done a certain way. The reality of it is that organizations within the same industry are more alike than they are different. Yes, there are nuances and competitive advantages that allows them all to exist in the industry, but core business challenges and opportunities are similiar.

I recently had a couple of conversations that were the epitome of this situation. On one hand, we were talking about extensive, semi-permanent changes that were required in order for the system to be “fully accepted and utilized by the stakeholders.” I approached these conversations from the standpoint of acknowledging we would probably move ahead with doing the changes but wanted to ensure that those making the decision understood what purposes those elements served and what potential opportunities were being lost by moving forward. Inevitably, we got to the end of the conversations and I was asked how other organizations had handled this same problem. In all cases, I had to explain that the majority of our customers took the exact opposite approach.

The large-scale data integration projects I manage come with a significant amount of organizational change required to make them truly successful. As a result, the project manager sits at the heart of the internal conflict of the organization between “the way it has always been done” and “industry best practices and opportunity for the future.” The role of the project manager is to educate and recommend, but ultimately, execute. Sometimes that means implementing in the best way for the organization with the understanding that as the system becomes embedded in organizational culture, some of the initial implementation will need to be unraveled.


Are you paid to think?

For most of my career, I’ve been in positions where I got paid to think. It was my job to solve really interesting, and often, really hard problems. If things ever got to a point of monotony, I knew it was time to move on. I have applied this same philosophy to those that work for me. If you worked for me, I wanted to pay you to think. I wanted you to observe and learn and challenge and grow. If there was ever a point where you outgrew the role, I wanted to send you off knowing you had a great experience and learned a lot.

I was recently in contact with a guy, Andy, who worked for me about 7 years ago. At the time, he was just out of college and I was hiring him for a billing analyst role. The responsibilities included: engaging with customers to solve their billing problems; invoice generation & delivery; generation of monthly reporting and data entry for new or updated customer information. We leveraged a combination of web applications, a home-grown visual basic application and Access, along with standard email queue software. After teaching Andy the basics of how the system worked and the overall processes required to do the job, he had full oversight of the process. I was their for escalation and final review/quality assurance.

I remember that Andy asked questions constantly. As I recall, most of the questions were basic questions or ones that he could have figured out if he had spent 5 minutes doing a bit a digging. Apparently, out of frustration one day, I told him “I’m paying you think.” I hadn’t remembered this conversation specifically, but I’m sure I said it. Andy on the other hand, remembers this conversation vividly. As he tells it “That one sentence changed my everything.” Nobody had ever challenged him. When things got hard, he would ask someone instead of thinking about it himself.

Unfortunately, I hear this same story from my friends and see it in my kids. If you want to know something today, you google it. But what happens if the exact results aren’t on the first page? Most people don’t go to the next one. They probably change their search criteria. Often what you are really looking for is the thing that is a couple of layers in, that you only got to by following the breadcrumbs from one result to a reference in another.

I’d like to challenge each of us to make sure we are challenging those around us to think, and are being challenged to think. It is only when we are all paid to think will we solve the really hard problems. We have to stop allowing those around us to use us as a crutch.

Rewarding Ingenuity Part 2

Back in March 2014, I wrote this post raising the question of whether we should reward ingenuity or punish bad behavior. We recently had another incident with the same daughter that had us thinking about this question again. This time, our daughter had her electronics taken away for bad behavior, specifically being rude and disrespectful. We had given her a specific timeframe for which she would have to suffer these indignities. After the first day or two, we found her watching Netflix on the family television in the basement. When we questioned her about it, she quickly pointed out that we had “taken her electronics”, but made no mention of her interaction with other electronics.

In a broader context, we often look at these types of situations and argue the gray line. We say that the offender “should have known better” or “should have known what I meant.” I think we walk a very difficult line with this argument, especially given the diversity of our workforces. Every day we interact with people who have had very different personal, work, education, etc. experiences from ourselves. There is a real possibility that they understand something differently (not necessarily better or worse).

Software projects are infamous for being over budget and delayed with the resulting solution not ever meeting the business objectives. In the traditional waterfall approach to software development, requirements are gathered upfront, and then interpreted by developers during implementation with a final delivery of a solution that hopefully meets the  customer goals. Agile methodologies address this by taking a very iterative approach to development, where constant feedback is given. This allows all stakeholders to see the execution (AKA interpretation) of the requirement and determine whether it meets the business objective.

As a project manager, I have to balance between breaking everything down to the simplest form as a means to eliminate misinterpretation and being vague enough to solicit questions, ideas and foster serendipitous moments. A team member that does only what is asked of them is good, but the team member that analyzes and challenges for the greater good of the project can be a rockstar.

In the end, is this really any different than my daughter interpreting her punishment differently?  On one hand, you want them to do their chores and listen to their parents, but on the other you want them to grow up to be critical thinkers and challenge the status quo to make the world better. This is a very hard lesson when you are 13. I’m not sure whether it gets easier to understand as we get older.

P.S. Just to close out the story, we allowed our daughter to use the family TV to watch Netflix because she very delivered her very logical explanation in a calm and peaceful manner.

Balancing Agility with Process is Really Hard!

Most of my professional experience has been in small, fast-paced organizations. I had one fairly short stint in a larger public company. During all these experiences, I’ve seen the constant struggle between agility and process. There are numerous studies that prove that companies need to react very quickly in today’s market in order to be competitive. Unfortunately, growth companies tend to pursue agility with pure disregard for process. McKinsey has done a few studies on this, here and here, that speak to the importance of agility but argue that the only way to achieve true agility is to have a strong backbone of structure and governance.

In my experience, the balance between agility and process (AKA structure) is very difficult to attain. When you are a company of 1 or 2, you do what works best for you. Hopefully there is some basic process around prioritization and execution, otherwise there might be a real struggle for viability. As you add additional resources it becomes more important to add some process. Resources need to understand the organization purpose (mission, vision, key performance indicators, etc) or everyone will be doing something different, making the whole very unstable.

Strong sales & organization leaders can overcome this, but they often do it at the expense of their own sanity. If a core group of people exert all their energy in developing sales and onboarding customers, they can compensate for the resources that are adding limited value. It’s at this point in the growth model where organizations struggle. It becomes apparent that some resources are severely underutilized while others are severely over-utilized. The focus of the conversation swings between the expense of training the under utilized resources or releasing the under utilized resources from the organization. In both these cases, the root cause has more to do with the process of onboarding resources. Does the organization invest the time to train the resources they have already or spend the time to find & train new resources? That depends on the resources and how they align to the organization. Some resources will be redeemable, while others are not.

Alternatively, there are many organizations that are so process oriented that they lose sight of agility. The focus becomes on making sure the process is followed, and the appropriate approvals are obtained. This is done at the expense of moving quickly.

Scale comes with being able to consistently deliver your product offering to your customers and add value in your area of expertise. If you have not designed a process around delivery or fully understand your product offering from your customer’s perspective (specifically how they derive value from your offering), you are likely to spend a significant portion of your time in fire fighting mode. Consequently, spending all your time fire fighting results in less time spent helping customers with the value initiatives.

I believe that there should be a balance between agility and process. Define a core set of processes that are critical to your product offering, set the groundwork for resources about why the organization exists (back to mission, vision & goals), but give them the space to make decisions and pivot as required.



In Commiseration of the Marissa Mayer WFH Decision

As has everyone else, I’ve been fully inundated with news about Marissa Mayer’s decision to cancel all work from home options at Yahoo.  Part of me really wants to be (and to some extent is) annoyed with the decision.  However the other part of me says that work from home introduces some real challenges, and there is a time and place to require people to come into the office.

I have spent the last year working primarily from home in a consulting role for a small data analytics company, that has office in DC and Arkansas and customers across the nation.  This meant that I could work flexibly around my children’s school schedule.  It also meant that I could get online later in the evening to delve further into issues or respond to inquiries.  Prior to this I managed a team across VA, OH, CO and India with customers in Ireland, Singapore, Australia, Hong Kong and Georgia.  I’m comfortable with managing separate time zones, different priorities and cultural differences.  This does not mean it was easy.  The primary business office was located in Georgia and technical operations was based in Colorado.  I had employees in neither of those places.  This made it increasingly difficult to have those casual conversations and accidental run-ins that are necessary when negotiating priorities and solving issues.

I solved this by travel fairly often to both offices. I often required my team participate in calls late in the evening or early in the morning with our Indian programmers, or our Ireland or Asia-Pacific customers.  When I was in town, in either location, I tried to have lunch or dinners with team members, counterparts or customers.  This established those relationships.  However, I still saw challenges without having that presence.  When one of my employees said he was looking to move out of state, I took the opportunity to introduce some new blood onto our team, and into our ops office.  His work from home status was only a minor element in the decision not to keep him on.

A major initiative of mine was to integrate my team better into the organization, and work collaboratively with other teams.  This was hindered by my teams remote status.  They did not have the connections to other employees, had no desire to make those connections and definitely slowed the progress of this goal.  One might argue that this was a result of the specific people not the policy.  However, it did lead me to the decision that new additions to the team needed to be brought into the office, at least in the initial phases to build those relationships with other teams.  It would considerably smooth the progress of our development efforts and increase the serendipity moments.

I appreciate Marissa Mayer’s courage to make unpopular decisions in her quest to turn around Yahoo. I can understand why this would be good for the organization in the foreseeable future.  That said, if all companies took such drastic measures, it would greatly diminish my own personal well-being, as a mother and contributing member of society.