Monthly Archives: September 2015

4 Lessons on Team Dynamics Learned from My Kids’ Sports

by

The start of fall rings in the season of multiple sports for our family. While I was protecting myself from the elements during the rainy, windy soccer game and then again, during the brisk temperature of the ice hockey rink, my mind drifted to the lessons we can learn from kids sports (or any sports for that matter). These lessons are also very applicable to any team endeavors including the team dynamics of managing a project.

You can’t control anyone other than yourselves

Teams, sports or project, are comprised of multiple people with very different and dynamic personalities. Each person is added to the team for their unique perspective and talents. It’s important to remember, both as a project member and team contributor, that you can only control your actions. If someone isn’t pulling their weight, or is doing something to negatively impact the project, you can try to influence them. However, the change in attitude or action can only be driven by the person doing it.

One option you have is to step up and fill a gap or try to positively offset the negative behavior. It won’t always work. In other cases it may be enough for the offending person to change their ways.

Sometimes external elements will adversely impact your performance

Outdoor sports are at the whim of the elements. While sometimes it is extreme enough to cancel or postpone the sporting event, but more often than not, the teams just have to power through it. In a project, there are also external pressures and decisions that will adversely impact your performance.

As a project manager, you need to do the best you can to minimize the impact. This might equate to sheltering your team with an umbrella or blanket. It is important to openly communicate about these challenges. As a team member, you need to trust that your project leaders will do their best to shield you from those external influences. Sometimes these efforts are not enough, and then you need to make do with the information and circumstance you have on hand. Like team players should never stop a play until the whistle is blown, team contributors should not stop working towards the end goal until directive is giving to stop or change direction.

You shouldn’t ignore those players who just show up everyday

My youngest daughter plays hockey primarily to spend time with her dad. She’s been playing for 2-3 years on a club team. Admittedly, soccer is not her favorite sport. She knows that playing a second sport often helps improve the first one. That all said, she goes to most practices, sometimes begrudgingly, and participates in all games where she isn’t already playing soccer. This does not mean that every waking hour is consumed by soccer either. It’s unusual for Ana to do an external practice.

This weekend was the first time this season I saw Ana play in both her soccer game and her hockey game. This year is the first year where Ana is playing on a full soccer field, so I wasn’t sure how she’d do. There’s a lot of running involved AND there’s an awful lot of opportunity to get distracted. She did well. Ana stayed focus, she didn’t get too far ahead of herself, or too far behind. The real drastic improvement was in her ice hockey game. This was the first game where I saw Ana as a real hockey player. She had a few shots on goals, plus a few assists. One was a beautiful play, where Ana actually looked up, acknowledged another player then passed the puck. Ana also had several breakaways to the puck, where she beat out the other players.

Something can definitely be said for showing up every day. You are going to improve a little  each time you get out there. Then one day, you will have actually made such significant improvement that everyone begins to notice.

You have to differentiate to separate yourself from the crowd

This one is somewhat in jest of the numerous Ana-like names on Ana’s soccer team. There’s Annika, Anna, Ana and Christiana, who prefers to go by “Ana.” We can’t use last name initial either as Ana is also, “Ana E” (as is Christiana). As you can imagine, this leads to some confusion about positions and field feedback. It’s easy to assume that it’s another  player receiving the feedback. This is not unlike a project team with multiple software developers, analysts or designers. External stakeholders do not necessarily understand the nuances of what each person is doing.

While most examples will not be as blatant as the 4 similarly named girls in the example above, you should assume that everyone is not educated about what you bring to the table. You will need to educate them. Whatever your primary strength, you should be highlighting this throughout your customer interaction. If your expertise is search engine optimization, demonstrating the techniques you use and their impact to the customer experience would differentiate you among your peers.

I’m sure there are quite a few other lessons we can learn from our extra-curricular activities. These were the ones that came to mind this weekend, with our specific games and circumstances.

 

Building Trust

by

Trust is a big component of successful project management. Team resources need to trust that each will will do what he/she has agreed to do, and will do it proficiently. The project owners trust the project manager to effectively manage all the resources, and ensure the project stays on schedule and on budget. The project manager needs to manage trust both up and down the project org structure. Without trust of the project owner, there is uncertainty about the goals, resources and schedule. And without some level of trust of the team resources, the project manager won’t be able to effectively communicate status or have any confidence that the work will get done. Unfortunately, trust is also an area that can be severely lacking in project dynamics.

Let’s first address the trust dynamic between the project manager and the project owner and stakeholders. The stakeholders are those people impacted by the project being delivered. The project owner should be the project’s advocate and supporter within the organization. Lack of trust can manifest itself in several different ways including:

  • stakeholders not trusting the project team to deliver the “right” business solution
  • stakeholders don’t trust that the project team will deliver on time
  • project owner is skeptical of the project success

As project manager, your ultimate success (of the project and within the organization) is dependent on how you manage these concerns. Trust is not something given lightly, it must be earned. If you are working with this project owner and stakeholders for the first time, or had the unfortunate situation of a prior project not going well, you will need to assume there are gaps in trust. Once you recognize this as a challenge, you can take the necessary steps to move forward. These should include:

  • understanding the business objectives and challenges the project is supposed to resolve.
    • ask to sit with the business users and share their problem. This deep understanding will help the team deliver the right solution.
  • as much communication as required by the project owner and stakeholders to make them feel included (and informed).
    • Ex: weekly email statuses or twice weekly status calls; or a couple of in depth show and tell sessions. It will really depend on the organization and the specific stakeholders.
    • communicating setbacks or challenges.  Do not shy away from sharing, or feel you need to hide the negative. Doing so will negatively impact project perception, and is counter to the trust you are trying to build.
  • using agile methodologies to deliver functionally ready project components iteratively through the project timeline that you can show the stakeholders.

Next up is the trust dynamic between the project team members (resources and project manager). Again, there can be many reasons why trust is non-existent within the team. Some include:

  • New project manager or team members that have never worked together before.
  • One or more team members have previously demonstrated some undesirable traits (ie. not delivering, not communicating delays, etc).

The team members do not have to like each other, although that can help. The project manager’s goal is to foster enough mutual respect to trust that the work will get done, and  the right project solution gets delivered to the stakeholders. A few methods for doing this include:

  • holding regular project touchbase calls.
    • these can be daily standups, or twice a week status calls. Figure out what works for you and your team.
  • having team members share information about external activities and families.
    • This helps team members see how similar they are, and lets them see the passion and interests that drives each of them.
  • providing time for peer programming or “cardboard batman” sessions.
    • By allowing the team members to help each other, they build deeper connections and foster trust. It makes the project a team effort, not just isolated, individual work.
  • Setting clear expectations, then verifying them.
    • It’s important to provide as much information as you have at the time you have it. Requirements are more fluid than we all care to admit, but making sure you pass new information on quickly will help with trust.
    • As project manager, do your best to verify the work delivered. This may be internal qa or show and tell with the stakeholders.
  • Acknowledging mistakes and promoting successes.
    • People want to do a good job. They also enjoy when those details gets shared within the organization. The project manager needs to take time to promote the team members.
    • Mistakes happen. They can significantly impact the project so they can’t be ignored. More important than the actual mistake is figuring out how to fix it. Acknowledge it, and then find a solution to get it remedied.

There are many different skills that make you an effective project manager. All of them are for not, if you can’t build the trust you need among the team. I challenge you to take a hard look at your projects and make sure you are taking the necessary steps to build the trust you need to make the project, and your team successful.

Teaching data science to my teenage daughter

by

Note: This post is a bit long, but it’s the story behind the evolution of our project to teach data analytics and data science to a teenager, leveraging her love of ice hockey.

There are a few times during my career where I have made decisions, that were in retrospect, a lot better for my family than I initially thought. At the time I made the decision, I did weigh the impact of the decision on my family, but there have been 2 that were really the best things that could have happened. The first was back in 2011 when I quit my job. My younger daughter was struggling in school and having the time and flexibility to get her the help she needed would have been extremely difficult if I had been working the schedule I had been. The second happened recently. In March I left another job to join my husband in the full-time running of our business. Since March, I’ve been able to spend one-on-one time with each of my daughters, taking separate spring break trips. And more importantly (at least for this post), I was able to work with Cayla, our 16 year old, during her summer internship project.

This story begins when we decided in the spring that we were going to hire Cayla as an intern in Digital Ambit, our software and data integration consulting business. At the time we knew we wanted to use this time productively, specifically we hoped to teach Cayla some technical skills. The most obvious route would have been to have Carson teach her programming. However, Carson was more than 100% utilized in our consulting business, where I had a bit more available time working on the business. We needed to be able to get Cayla some tech skills, without severely impacting Carson’s ability to deliver on our billable work. This left me to figure something out.

My background is fairly diverse, with time spent in both technical and software skills. I consider myself a technical project manager, truly leveraging my technical skills to manage customers and projects. While I can manage any technical project or implementation, my actual technical experience focuses on databases and data management. I had recently taken some data science Coursera courses and had dipped my toe in the R world. I finally decided Cayla was going to do a data analytics/science project to take hockey statistics and see if she could predict who will win next year’s Stanley Cup.

I bought Cayla a couple of books on data science for business and practical data science with R. I knew Cayla had never studied statistics and had a few concerns about the complexity of resources written about data science and R. I made Cayla write a blog to make sure she could articulate the material she was learning. Once she started picking up some of the basics, we talked through the project at a very high level so Cayla knew what the next steps were. This was very much a hands on project for her. She had to find the data, download the data, cleanse the data, and figure out the R syntax to load and analyze the data. I gave her space to work through issues, especially after the first few times she told me she had an issue with R and after asking if she had confirmed the syntax, pointing out the missing comma or syntax error.

We were about a month into the project before Cayla could bring all the pieces together and really explain what she was trying to do. She could relate the daily work to the project, and had mapped out her next steps to align to her business question (“Who will win the next Stanley Cup?”). At this same time, we learned we had been accepted to present this story to the DC Web Women Code(Her) conference. This intensified the pressure, and added a hard deadline of September 12, 2015.

This is where it got a bit difficult for Cayla. At this point she had gotten all the data she thought she needed, cleansed it (or so she thought), and had found  at least one way to calculate the historical means, and populate the 2015-2016 statistics. The complex nature of the statistical models and the applicable documentation caused this to be a real sticking point for Cayla. Unfortunately, the method she had been using, along with her still dirty data made reproducibility and data modeling extremely difficult.

At this point, I stepped in to help in a more hands on way. I knew that I wanted to create an R script to share during our presentation, so I started walking through Cayla’s syntax. Sometimes things that work in isolation, don’t work the best when combined with the other methods you applied. It took some intense focus to step through the process, cleanse the data to acceptable R processing standards, and leveraging different syntax for historical means and filling gaps. The hardest part was finding clear, concise examples of people who had done this before. Ultimately, I was able to find syntax that worked to run models against the data and analyze the data. We were not successful in getting the model to predict any winners.

I think Cayla and I both learned a lot from this project. Cayla learned that she can do really hard things, she’s never done before. Cayla also learned about planning and organizing data projects, and how truly difficult, but incredibly important, it is to clean your data. I learned that Cayla can learn anything with the right incentive, or within the framework of something that interests her. I also learned that in data analytics and science, more people need to publish their work in simpler forms. Please don’t assume everyone has a PHD.

We presented our story at the Code(Her) conference on Saturday. Cayla reinforced her knowledge of data science during the Intro to Machine Learning session, and seemed to have fun learning agile principles while playing games. The day culminated with us presenting to a room full of women. It was really rewarding to see how well Cayla did, and to see how many wanted to hear us.

IMG_0396

To see our detailed presentation and additional materials, visit my github page.

3 steps to take when your project isn’t going well

by

In an ideal world, all our projects are on-time and under budget. The reality is that is rarely the case. More often, a project runs over on budget or timeline. For the nature of this blog, I’m not going to go into all the reasons why there can be budget or timeline overages. I want to focus on techniques for managing the impact. These very much tie into my approach to project management (you can learn more in this post).

  1. Communicate – At the first sign of a problem, starting communicating up and down the project chain. You want to make sure the project team are aware of the additional stress and constraints the stakeholders are feeling. This keeps them moving towards the end, but prepares them for some of the more difficult conversations they may have with stakeholders. Also important is having an honest conversation with your stakeholders and business sponsors. You need to make sure that everyone is on the same page. It is not about point blame, but rather collectively determining the next steps and discussing remediation options. This might include reducing the scope, or increasing resources or budget.
  2. Be positive about your successes – When projects take a turn for the worst, it is easy to dwell on what’s going on, focusing solely on how to fix it. Make sure you are positive about the successes. These may be as simple as just developing the use cases, or maybe the team has started implementation and development. Each moment of time spent on the project increases the project outputs, and creates positive moments. Leverage these to keep morale up and keep stakeholders engaged with what has been accomplished. It helps if you’ve split your project into small, incremental releases. It’s harder, but still possible when your project has more nebulous intermittent releases.
  3. Keep team moving towards some release date – Project crunch mode is a very stressful time for all those involved. When those culminate, you will want the team to regroup to determine what can be delivered in the shortest amount of time. Ideally, this has some, if not all, of the functionality that is most critical to the business users. You are always better off if you get something in the hands of the business users, as quickly as you can.

Murphy’s law definitely exists in project management. If it can happen, it probably will at some point. I find that it’s much easier to manage these rough times if I communicate (almost to the point of over-communication), be positive about the small successes the team has and make sure we have a plan to deliver something. It helps if the things you deliver are aligned to the stakeholder’s critical requirements. Most importantly, do not shy away from talking about your project issues. That just builds resentment and further uncertainty.