What did #givingback teach me about team dynamics?

My younger daughter and I did some volunteer work yesterday at the Capital Area Food Bank warehouse in Washington, DC. We were part of a group of about 12 people, some parents with kids who needed community service hours and other adults. It was fascinating to watch us evolve from individual or small groups to a graceful machine that just did what needed to get done. I left thinking about how a group of strangers working for a good cause can naturally meld, while we have all been in professional situations where people seem to work against the natural evolution.

team-dysfunction

Our job was to unload several pallets of breakfast and lunch foods in the refrigerator, repacking it all into individual banana boxes. Our group of volunteers started working either individually, or with the people that came together. Fairly quickly, people started stepping into roles that just needed to get done. Instead of fighting for floor or pallet space to load boxes, started opening all the boxes and handing them off to packers. Stronger individuals started collecting the boxes as finished, and others stepped into to funnel empty boxes to those that were packing. As pallets were packaged and left empty, others stepped into to breakdown boxes. And we did all of this, with politeness and instinct. I’m not sure anyone even asked any other person their names. It was awesome to have a bunch of strangers work together so seamlessly, all pursuing the same goals (either the short term one of getting out of the fridge or the more altruistic one of helping a worthy cause.)

Why is it then that I have been in more than one professional situation where the team  doesn’t meld in any capacity, let alone as smoothly as yesterday? I’m not talking about the individual who marches to the beat of their own drum, as I’m pretty sure I fall into that position quite a bit. I’m talking about the person or team that seems to fight against almost every request or initiative to solve our customers problems. Maybe it’s because I’ve grown up around small businesses as a child and for most of my professional career. Small businesses need be customer focused to survive in a way that larger companies some times forget. My professional roles have always been in bridging the gaps between customers and technology, so for me, every decision I make is with the customer in mind. It’s unfortunate then when I’ve been in situations where process or team goals have been misaligned. If I’m working to deliver customer value but all efforts are stymied, does it mean the unhelpful person or team isn’t aligned to delivering value to the customer?

I know that this is a harsh criticism. I also recognize that different people have different motivations, and are provided different team goals within organizations. While I don’t truly believe that these teams intentionally set out to hinder what I’m trying to accomplish, I do think it’s unfortunate that there’s that much misalignment across organizations. Too often, customers see the results of this disfunction and ultimately are the ones that get hurt.

 

What are processes without people to follow them?

The … process is only as great as the people who participate in it. – Jeff Miller

Congressman Jeff Miller is attributed to saying this quote in reference to the democratic process, but I think it applies to most process. A process without people following doesn’t go very far.

If you know me, or have navigated my site at all, you know I love to read. Fiction, non-fiction..books, articles, blogs, pretty much anything I can get my hands on. This also means I look for and want documentation and process. I want to see my starting point, and then figure out where I need to go. This also means that I strive to leave the same for others. I am not afraid to leave behind my knowledge or information for others to benefit.

Too often though it is becoming more common to want to be fed information, rather than seek it. When did we lose our natural curiosity? And further, why are we so quick to stop after the first roadblock? Even more frustrating to me are those that should know where to find the information they are looking for, but still don’t follow through.

Don’t get me wrong, this inclination has yielded plenty of new opportunities for me. Because I know these resources exist, I can leverage them and very quickly expand my knowledge, making me more effective. I guess I will keep doing what I do, and try to leave my knowledge on for the next person. I can hope that someone will take advantage of it.

 

 

 

Losing ourselves in the moment….

or maybe it’s just on conference calls. I believe strongly in remote work, and by extension I believe in asynchronous communication like email and chat apps, but also believe we need real-time communication like phone calls, conference calls or web sharing sessions. However, I am still amazed by how people behave on conference calls. It seems as if people just lose a little bit of themselves, and forget common courtesies. Today I’m going to use my soapbox to discuss some of my bigger pet peaves.conference-call-meme

  1. Remember everyone on the conference call, not just those in the room. As a project manager, I try to be conscious of everyone on the call. This includes multiple people that might be in the same room or that person sitting alone. There have been times where I’ve been the only decision maker participating by conference call. During these times, I feIt I had to time my opportunity to speak up just right. I had to do this by jumping in on any pause, regardless of where the discussion was at the time.  Alternatively, I will often have side conversations via text to facilitate progress. For people in the same room, or for the conference call organizer, it is important to remember to intentionally include all participates. You invited them for a reason.
  2. Someone needs to lead the call. The belief that conference calls aren’t effective speaks more to the organization of the call, than anything else. There is always a reason a conference call gets scheduled. Someone needs to facilitate the call. What are you trying to accomplish? What is the take away? And most helpful, if something needs to be prepared or investigated beforehand, make sure that expectation was set when the call was scheduled. Otherwise you are wasting everyone’s time.
  3. Don’t forget your manners. I guess all my frustration really boils down to this. I want to believe that we are all passionate human beings and sometimes tempers flair. I know that’s happened to me. We can only control our own behavior so let’s try to reign in our tempers and remember we are all there, in that moment, for a common good.

 

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.

bespoke-suit-pattern

http://www.giandecaro.com/img/background-bespoke.jpg

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.

 

Whose job is QA?

not-my-problem-meme

Tribute to Gene Wilder as Willy Wonka – it’s not my problem meme

developer.com defines the QA (quality assurance) role as “the role responsible for guaranteeing a level of quality for the end client. It’s about contributing to the quality of the final product.” I really like this definition as it does 3 critical things. First, it highlights the importance of the client. A product that works as designs, but doesn’t solve the customer problem fails to address the crux of software development, giving people an application they need or want. Second, it directly states that the QA role contributes to the quality of the final product. Just as developers contribute to the building of the product, and project managers contribute to getting the project done. Last, this definition removes the perception that QA is the responsibility of a single person. And this, my friends, is the topic of today’s post.

Our job as the project team is to build a solution that solves a customer problem or need. I agree that sometimes you are building a solution that customers don’t know they need yet, but unless that need or problem exists, there’s no point in building it. From the very beginning of development, we should all be working with this goal in mind. And if everyone is focused on the same goal, are we then inherently focused on QA? I think so.

My role as project manager puts me directly in front of the customer. This means that I need to be familiar with the solution, in order to speak intelligibly to customers. I tend to do the “final test” of replicating the steps provided by the customer and using the output as proof that the issue is resolved. Unfortunately, there have been too many times where I’m delivered a solution that doesn’t solve the problem or clearly doesn’t yield the “correct” results. Or, if I report a more general issue about performance, I get very tactical response, rather than considering the customer experience.

So what happens? Why does the solution I’m provided not solve the customer problem? Is it because the developer didn’t understand? didn’t care? More likely, it is the developer did some initial investigation and solved what they thought was the problem but didn’t walk through the steps to see it from the customer perspective and therefore missed a critical step.

I’m not advocating for or implying that I wouldn’t or shouldn’t still have the final sign off not the solution, before delivering it to the customer. I’m suggesting that each person who has touched the solution before getting to me should understand the problem we are trying to solve, and be focused on delivering a quality solution. Each developer should be incorporating regular quality checks into their own development. I never want to hear that “my team doesn’t have a QA person” or “it passed my acceptance test.” If the team members understand the goal, and view QA as a part of their job, the customer solution is bound to be better.

 

All hope is not lost..3 reminders regarding the human side of project management

folly-beach-shoreline

Folly Beach SC shoreline

I just returned from a friendcation in Charleston, SC. This was a much needed vacation after a few really stressful weeks. This vacation was filled with good food, good friends and perfect weather. More than the relaxation and rejuvenation, this vacation reminded me of some key pieces to the human side of project management. Yes, fundamentally, all project management is human, but many times we forget the basic courtesies as projects get challenging.

These three reminders have been playing through my head today as I have returned to my project work.

Don’t forget the generosity of strangers

On the first day of our travels, we were taken under Mary’s wing. Mary was a new acquaintance of one of the group members, who happened to be from the Charleston area. Mary went above and beyond, picking us up, showing us around her town, chauffeuring us to the drugstore, grocery store, and finally depositing us several hours later at our beach house. She provided us with a list of places to go and things to do. We were four friends with a lot of luggage, and a lot of “asks” but Mary extended her southern hospitality and made our lives a whole lot easier. We hadn’t realized how much until about a day or so later when we realized that there were no available Ubers in the area we stayed during the off-season.

In project management, you are usually so focused on your immediate team members and milestones that you can lose sight of the periphery. You might be missing out on just the thing you need to deliver more effectively.

If you’re all aligned to the same goals, you can make anything work

This particular vacation had 4 friends, traveling from 4 different areas, with 4 different budgets. There wasn’t a single spat or disagreement of any kind. Nobody complained about people’s choices to sleep, or golf, or not drink, or even to work a little. We each respected the boundaries the others set and made arrangements for food or checks or whatever we needed.

During challenging projects, it can sometimes get contentious. It’s important to realize that everyone should be aligned to the same goals, and therefore should be able to work together to make it happen. If you truly start to see and feel stakeholders pulling away from the central goal, you need to explore that. Sometimes goals have changed, or other times it’s the pressure they are feeling approaching a looming deadline, or something else entirely. It’s your job to figure out what it is, and how to work through it.

Beware of the driftwood in the corner

Driftwood & Sea Glass

Driftwood & Sea Glass

The beach house we stayed in was very cute. As we were lounging in the front room chatting on the first day, I noticed this driftwood and sea glass art piece in the corner. As I looked more closely at it, it manifested itself as a dead, jumping rabbit carcass. It was all a bit morbid and creepy, but this became the consensus of the group.

Unfortunately, projects often end up with a similar situation. Something seemingly “artistic” morphs into its not so pretty reality. As the project manager, it’s your job to identify these instances before they escalate. Just like the driftwood rabbit, once all the stakeholders start to “see” these in the project, it’s very hard to un-see them.

I’m really glad I took this time away. Yes, I did a bit of work. But mostly, I didn’t. We relaxed in the sun under an umbrella on Folly Beach. We laughed. We explored. I’m back at work, taking my projects to the finish line and reminding myself of all that I learned.

Thanks friends.

Whose side am I on?

http://www.kappit.com/img/122260/whooo-what-a-week-im-so-glad-its-tgif/

http://www.kappit.com/img/122260/whooo-what-a-week-im-so-glad-its-tgif/

This has been a tough week. Not only was it busy, it felt like I was spending a lot of time chasing my tail. Unfortunately, it wasn’t isolated to a single client or project. It seemed across the board, I struggled to keep a handle on what was going on. The one consistent point is that neither the client nor the internal project team felt “I was on there side.”

A project manager or customer success manager for technical products are usually smack in the middle between the demanding customer and the product or project team. So, why then did this week bother me so much? I think it was because I am seemingly able to do a better job balancing everyone’s interests. I’m using today’s post to try and figure out what happened and what I can do better next time.

  • Don’t take it personal – First, I really do need to remind myself not to take it personal. As I tell my kids, “I am only responsible for my own behavior.” On the side of the customer, I am the representative of the company. It is my job to hear their issues and feel their pain. Sometimes that escalates if resolutions aren’t found quickly enough for their liking. On the side of the company, it’s my job to be the advocate for the customer. As a company, we need to realize that it’s not personal. We are each doing our job.
  • It’s all about the communication – This leads me to the second critical point. Everybody needs to communicate. The adage “no news is good news” doesn’t apply in project management. No news usually means that nothing has been done. As the advocate for the customer, it’s my job to follow up and get resolutions. At a minimum, at least tell when I can expect a response. This gives me something to tell the customer.
  • We are all on the same team – Lastly, we all need to realize we are on the same team. No matter how well a company “eats their own dog food”, the customers will always be the experts of the products. Just because they are using the system in a way that we didn’t anticipate doesn’t make what they are doing wrong. They are giving us feedback and making it better. Every time they uncover an issue or ask for something, they are driving us forward. Let’s embrace that. Let’s not assume that the customer is doing something wrong. The onus is on us to understand the use case and solve the customer problem.

I think this week’s lesson is pretty clear. I’m glad it’s friday as I need to regroup this weekend to tackle the open issues head on next week. Hopefully I will be able align everyone towards solving the problems. But as for the question I posed, we are all on the same team: product, services, and customers. 

How do you Counter the “Hurry Up and Wait” Game?

You can get so confused

that you start in to race

down long wiggled roads at a break-necking pace

and grind on for miles across weirdish wild space,

headed, I fear toward a most useless place.

The Waiting Place…

-Dr. Seuss “Oh, the Places You’ll Go

As a project manager who works on complex implementation projects, I find that I spend a lot of time waiting…

  • waiting for developers to finish their work
  • waiting for approval or feedback
  • waiting for resource availability
  • etc

It isn’t the inherent waiting associated with regular project management that’s frustrating, it’s the “hurry up and wait” syndrome that bogs me down.  These are scenarios where you have completed some component of work, are have been waiting for some time for feedback. When the feedback is finally provided, the expectation is that you will turn around a response or resolution immediately. If not managed correctly, this becomes an ugly cycle.

I have to remind myself that this isn’t happening to make my life difficult. There are underlying motivations that I don’t necessarily understand. Ron Ashkenas’s 2014 article in the Harvard Business Review “Two Ways to Reduce “Hurry Up and Wait” Syndrome” suggests that this is a byproduct of the “dramatic acceleration of today’s business culture.” Mr. Ashkenas provides two suggestions for how to minimize the impact by 1) putting a premium on removing low value work so there is more bandwidth for handling urgent issues and 2) do a better job prioritizing new requests as they come in, specifically making decisions on urgency.

I’m a huge supporter of both of these suggestions, but I think the minimize the partnership aspect of working with clients. As a value added partner you should remember these 3 things when faced with the “hurry up and wait” syndrome:

  1. You don’t know what the other person is going through – Yes, you are feeling the stress of the other person’s action, but who knows what they are going through. Maybe this is worse for them.
  2. It is critical you communicate – You need to be able to have a conversation. Tell your customer when you are going to deliver (within reason of course) and deliver. This may not be the requested tomorrow or noon today deadline, but people will generally be reasonable if you set and meet expectations.
  3. Don’t let yourself fall into the “hurry up and wait” syndrome – If you aren’t careful you can find yourself in a situation where you are constantly fighting fires and always reacting to situations. You need to be able to look at all you have to do, across all clients and make legitimate decisions about priority and urgency. By introducing process, you can bring peace to the chaos. It’s this step of building system and process that will allow you to grow and develop smarter as an organization.

 

 

 

 

 

 

 

 

Do your project managers focus on process or delivery?

I’ve struggled in the past with using the term “project manager” to describe what I do. It almost immediately triggers the question of whether I am PMP certified, and focuses less on my experience delivering projects. Additionally, I think there are quite a few employment roles today that include some project management responsibility. Doing basic project management tasks like scheduling meetings, doing status reports and checking the schedule does not automatically mean that you are able to deliver a project to its completion.

images

Rudy Gottschalk wrote a two-part series on shifting from “project management” to “delivery management.” He challenged all of us to look for a different approach, shifting the focus from project artifacts to project delivery.

“Too often project managers follow the rigors of a project management structure, but seem to have no sense of urgency in delivery or at times feel helpless to take control of the project delivery schedule.  They dutifully note progress, document issues and risks, and send minutes with the next meeting invitation. Since these activities fulfill the checklist of project management deliverables required by the organization, they usually give the illusion of progress, although little progress is actually occurring.”

I see this all too often in organizations. One manifestation is very large organizations, where a Project Manager from the PMO (project management office) AND a IT PM (AKA business analyst or delivery manager) get assigned to a project. In this scenario, both resources are expected to coordinate meetings, document decisions and communicate to stakeholders. The real distinction comes in their focus. The project manager tends to focus on following best practices and making sure every box is checked. Often, they are super cautious and tend to be more worried about creating the timelines, rather than the fluidity of project delivery. The delivery manager is primarily responsible for moving the project forward – removing obstacles, managing work assignments and facilitating ownership, driving towards a finish line. By not looking towards the endpoint, you sometimes end up in situations where there are incomplete lists of activities identified for project completion, incorrect timelines or lack of ownership and accountability.

Another manifestation of this problem can be seen in those roles with project management responsibilities. Often times, the immediacy of support tickets, status calls, status reports and the mechanics of the project “workflow” take precedence over delivering towards the end goal. Unfortunately, this can result in delays in getting to the value proposition. Ultimately, it also minimizes the importance of the critical analysis and seeing the overall picture.

If it is not obvious, I strong believe that project managers or those with any project management responsibilities need to be focused on delivery. This means focus on whatever the end result is, be it business value or a specific ROI. Without that target, it is easy to get lost in the logistics and workflow of managing a project, while not actually driving it towards a completion.

A Framework & Critical Decisions for Implementing a Data Integration Project

I have managed quite a few data integration projects. These are projects defined by the development of software and business projects that help organizations move data between systems and better understand the data they have. While each one is different in data sources, and project owners, overall my approach remains the same. I adapt the tools, timelines, and specific tasks depending on the organization and systems involved. Today, I’m reviewing the framework and critical decisions I rely on.

At it’s most basic level, data implementation projects have 4 core phases: Discovery & Requirements, Consensus/Sign Off, Development & Handoff.

  1. Discovery & Requirements – This first phase is most critical. It is at this point that you truly determine all that you need to know to design a solution.
    1. What business problem are you trying to solve? This lays the groundwork for everything else. Without knowing this information, it would be difficult to solve the right problem, or determine the right metrics by which to measure your success.
    2. Where is the data to solve the business problem? Now that you know what problem you are trying to solve, you need to understand where the data resides. This might be 1 source system or integrating 5 source systems. Are the systems internal or external to the organization? Does it only reside in someone’s head? Make sure to document the owners, stakeholders & gatekeepers. Your design could vary significantly based on what you find.
    3. What is the data format? This information and subsequent conversation should drive additional requirements around software, security, encryption and data transformations (AKA business rules).
    4. How is the data accessed? This should actually help you answer how should the data be accessed. Choose the best tool for the job based on the requirements documented in the prior conversations.
    5. What needs to happen to the data? Sometimes a project is as simple as making data sourced from one system available in part, or in entirety to another system. Often times, it doesn’t align exactly and business rules must be applied before it can be leveraged by other systems.
    6. How often is the data needed? And what triggers the transfer? Does one system push the data? Does the other system pull it? Is this an infrequent process? Or something needed real-time? or is there a triggering event?
    7. Which software is best? It’s finally time to start thinking about the tools, languages, & frameworks, etc. Also, make sure to include where the code resides & how security policies impact integration.
    8. How does feedback work? At a minimum, you need to consider how errors & exceptions are handled. In more complex implementations, data will flow both ways.
  2. Consensus/Sign Off – Document everything you learned and decided in the Discovery & Requirements phase. Everything from the high level problem to the detailed technical decisions that were made. Please, please get sign off from all the relevant stakeholders.
  3. Development – Development & validation go hand in hand.
    1. How will your results be measured? Write your test plans before you begin development. These are based on all the decisions & requirements documented in phase 1. You also want to do periodic data quality checks with the business stakeholders throughout the development process. There are ALWAYS things you find while engaging the business stakeholders, using real data, that you would not find on your own.
  4. Handoff – This is not simply a matter of flipping a switch and transferring ownership. This phase includes documentation, knowledge transfer during transition of ownership, and end-user training (if applicable). If not already, make sure the project artifacts are complete, compiled and made available to the organization. Often times, data integration projects require a period of hypercare where developers work closely with support people, and both the project implementation team and the support team work closely with the end-users, to make sure there are no gaps in knowledge.

Ultimately, the goal of data integration projects is information. There is some set of data in one system that could be made more useful or help derive better insights if connected with data from other systems.

Let me know if you think I’m missing any critical decisions in the process.

A infographic of this methodology is available in the case studies section of the Digital Ambit site.