Monthly Archives: June 2016

Striving for perfection in project implementations

by

One of Merriam-Webster definitions for perfection is “something that cannot be improved.” For me, project management, software development and data analytics are always evolving. Every new project I take on is balanced on the learnings of all the prior projects I managed. This is true for software projects, and is true in data analytics. For every  question I answer, I can think of several more that I’d like to tackle.

the Idea of perfection is so imperfect.

Source: http://www.thefeelgoodlifestyle.com/wp-content/uploads/2013/04/Perfection-is-imperfect.jpg

Nevertheless, it is not uncommon for project stakeholders to say that you can’t roll something out, or even go into a pilot phase until everything is perfect. It is at these times, that project managers need to take a step back and analyze the project from the people and motivations perspective. The project stakeholders are saying that they are uncomfortable with where the project is and are not willing to put themselves on the line just yet.

How did you get here? 

This problem generally arises when expectations are not aligned. If each side hasn’t clearly documented and shared what they were working towards, there is no guarantee of all sides working towards the same end goal. It is not enough to have documented requirements, or use cases. You also need to agree on the measurement or evaluation criteria.

How then do you move forward? 

  • First, both sides need to communicate.
  • Second, both sides need to jointly agree on a core set of success criteria for each milestone and phase.
  • Third, both sides need to remind themselves that everyone is working towards the same goal.

There will always be requirements that continue to evolve for every software or data integration project. It is making sure the project implementation team is working towards the same success criteria at the same time as the project stakeholders.

 

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

by

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?

by

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

by

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.