Has discrimination made me a better project manager?

hippoMy dad recently sent me this article by David Silverberg on questioning your hippo boss. Once I got over the unfamiliarity with hippo as a business term meaning “highest paid person’s opinion”, I started to ponder the premise of the article. Mr. Silverberg introduced me to a study by the Rotterdam School of Management, which determined that “projects led by junior managers were more likely to be successful than those that had a senior boss in charge, because other employees felt far more able to voice their opinions and give critical feedback.”

Next consider all the studies and social experiments around how differently men are treated than women in professional situations. The most recent one I’ve read is where two colleagues switched signatures for 2 weeks and Martin Schneider learned the hard way about the not so subtle sexism that happens towards women in professional situations.

Let’s also consider the premises by CIO.com and Capterra that women make better project managers. According to the CIO article, “more than 75% of projects $10 million and over fail, overshooting their budgets by 55%, costing the typical Fortune 1000 company an average of $160 million per year.”  Since only 17-30% of large projects are led by women, the majority of those failed projects are led by men. Much of the differences are attributed to the difference in the ways that women assess risk and the confidence trap (the more wrong men are, the more confident their assertions). The Capterra article shares several compelling details about female leaders including “female project managers are almost twice as likely to be on projects costing $1 million or less”, but “women are seen as more  effective (by others) when they held senior-level management positions.”

And finally, let’s consider my my career. I have been the highest paid person on my team and have run several successful technical implementation projects. I often speak up and challenge the status quo to drive others to find better solutions. I have done this with my team (project or direct reports), peers and bosses (direct and several layers up). I have also been challenged many times in my roles as project manager, director or vice president of technical teams and projects.

Should we then conclude that women make better senior executives and project managers as a result of the inherent bias that results in women being treated differently than men?

It’s certainly possible. As a project manager or team lead, I definitely work harder to:

  • foster a collaborative team – I’m very willing to pull additional resources into conversations, as required and force an issue on a call rather than dragging it out over email. If you start building bridges with other groups, departments or resources, you open yourself up to having a wider variety of people to bounce ideas and solicit diverse input.
  • share everything – I’m also a strong believer in documenting everything I can and sharing that with others. I pride myself on doing this, and making it available. It frustrates me that so much of this is not considered important or too proprietary to share even at the team or department level.
  • do my own research – In the same vein, I do a lot of reading and thinking about different topics. Not only does this expand my worldview, it also makes people more willing to engage with me when I need help.

Whether it’s because of or in spite of, I will continue to learn, adapt and delivery on projects.

 

 

 

 

Resetting project expectations isn’t a bad thing

dream-catcherThe project I’m working on is perfect. I have the all the money, resources and time I need to be successful. The stakeholders are really engaged, the success criteria is clear and we are moving along on the project timeline exactly as we originally defined it.

Yes, that was a lovely dream. Unfortunately, we all know that most projects don’t go like this. I was working on a project that should have been a quick implementation, but immediately after the kickoff it became apparent that the scope defined in the sales process didn’t align to the requirements of business stakeholders. This made for some interesting project discussions. A couple of weeks in, just as the project was on the brink of derailing, we were able to have a very honest discussion and reset the project expectations.

This was a necessary step in making this project successful. There was definitely a miss in the early scoping process, but as a result of the communication among the business stakeholders and the project team, these issues were identified early. It also helped that this was a case where we didn’t lose any time working on unnecessary components. All the work that had been done before the project reset was still a valuable contribution to the project. Too often, project teams are hesitant to have these very honest conversations. Instead, time is wasted dancing around the problem, or implementing solutions that don’t meet customer needs.

To enable recovery from a project that is going awry, you need

  • Business stakeholders who are involved and advocate for their needs from the beginning
  • Project manager and leadership that is open & honest about the existing scope
  • An entire project team who (project implementation team, decision makers, business stakeholders) want the project to be successful and are willing to re-evaluate and reset the project scope and timelines accordingly.

 

The impact of sales context on project management

domino-effectData or software projects are usually purchased in one of two ways: as a part of a large, enterprise level deal that impacts multiple teams and has overarching corporate goals or as a stand alone purchase for a specific purpose for a specific team. This sales context can make for very interesting project management moments.

If we take the scenario where an organization makes an enterprise level implementation decision, you could have some additional levels of complexity. For example:

  • The project team may have to “sell” the project to the individual teams of users within the organization. The teams will likely have different levels of familiarity and maturity with the business process or solution.
  • Where there are varying levels of maturity, you have to be careful to effectively set expectations and cater differently to teams based on their desired engagement.

In another scenario, one part of the organization makes a purchasing decision with dependencies on other parts of the organization. This will often result is some interesting yet awkward project conversations. For example:

  • If you need to engage with another part of the organization to make the project be successful, it’s important to lay out all the facts and deciding factors. Too often project conversations must occur to relieve stakeholder concerns without those stakeholders having all the facts. Those seemingly minute details can totally shift the tone of conversations, making or breaking success.

And last, let’s consider the scenario where a specific team is looking at a solution. In this case, there can be additional considerations both in the sales process but in the project management as well. For example:

  • Does the team control the purse strings? Or are there other dependent groups or players? Make sure you fully understand the landscape of stakeholders & stakes.
  • Does the pain points being discussed align to what you do best? Just because you can sell your solution, doesn’t mean you should.
  • How does this sale fit into the overall goal of you both organizations? Is this a one-off purchase by a team without any broader organizational support? or are there opportunities for growth for both parties?

Project management in itself is a fairly straightforward undertaking. Your job as project manager is to deliver on the project goals. As the saying goes, “the devil is in the details.” You need to quickly assess the lay of the project land. Who are the key players involved in the project? Who are the key players not involved directly in the project? What are the potential pitfalls or landmines you need keep on your radar (not necessarily on your horizon as you should be working to mitigate these as much as possible)?

Find your “green flash” in each of your projects

A green flash occurs when the conditions are right as the sun rises or sets. Growing up on St. Croix with many weekends spent at the beach at the west end of the island, I’ve seen a few of them. As I sit down to get some work done on this damp, dark, dreary, rainy day Monday I think about this one to two second flash of brilliance on the horizon. Sometimes it is just what you need to refocus your attention on the task or project at hand.

Green flash – www.sandcastleonthebeach.com

So, what then is the equivalent of a green flash moment on a project. It’s that thought, idea or component that drives you forward. It could be the group of people you are working with; or the ability to use a specific skill; or learn something new. It doesn’t really matter what it is, but rather that it motivates you. And this is a more personal endeavor than just being on time, or on budget, or meeting a specific stakeholder KPI. This can and probably should be different across different projects.

Just like a lighthouse beacon, every decision or action you take should be with this point in mind. This means that you need to consciously think through your actions to make sure they align to this particular project goal. While I don’t necessarily think it’s necessary to share your personal green flash moment, but I do think that you need to visualize yourself succeeding in the way you defined. Your mental conversation should be how you get to the end, not questioning whether you can get there.

 

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.

 

Striving for perfection in project implementations

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.

 

Preparing for my First Drupalcon

I’m heading to my first Drupalcon in New Orleans next week. While I’m a very technical project manager who has worked on website implementation projects with content management systems or other integrations, I’ve never worked in or on a Drupal project. This is really my husband’s area of expertise.  Carson has been to several Drupalcons, but still spent quite a bit of time debating between the business and technical track. You can read his blog post on it if you’re interested in his thoughts. I struggled a bit with my own planning so I am hoping a blog post on it would help organize my own thoughts.

I attended Drupal GovCon last year where I participated in mostly the business sessions. I wrote about that experience too. Going into this Drupalcon, I have many of the same goals that I had last summer: learn more about Drupal and make some good contacts in the Drupal community. As I was looking through the different sessions, I did not want to hyper-focus on any one particular track as I have personal & professional interests in business, project management, women in drupal and the learning more about the technical side of Drupal. I’m not sure this aligns to the typical attendee. This made my initial pass through the different sessions a bit frustrating. I walked away thinking that there wasn’t a lot of sessions that interested me and concerned that I would be wasting my time. I was a bit more successful the second time around, and by that time the Birds of Feather “BOF” (adhoc sessions) were available.

Monday was easy! Carson participated in the business summit at last year’s Drupalcon and got a lot out of it. This year I’m participating in it, while he attends the government summit.  This is a great opportunity to learn from other Drupal agencies. Businesses in the Drupal community tend to really open up their books and processes and experiences in a way that other businesses don’t. I attribute that to the core principles of giving back if you participate in the open source community.

On Tuesday, I’m mixing up technical sessions with business ones. After my first Dries keynote, I start off my day with a session on understanding data structures and am definitely going to the session on how to get more involved in the open source community. Beyond that, I’m still bouncing between critical metrics for your business and teaching drupal to kids; case study on leveraging drupal to deliver business results beyond clicks, conversions & revenue and building a remote drupal shop. I’m also going to the BOF for small business owners to share ideas. Then we’ll head over to the Women in Drupal event we’re sponsoring.

Wednesday is focused on the business side of things. I’m hoping the writing great case studies for drupal.org will allow me to pick up some skills for writing great case studies for anyone. Then I’ll be learning about selling the value of new drupal 8 technical features, and finding my purpose as a drupal agency. There is only one time slot where I have not decided yet. Is it the session on Drupal community as an example of diversity in tech or implementing performance metrics and dashboards for your digital agency or productive collaboration of sales and project management as a means to drive customer satisfaction? Before we head off for more socializing, I’ll participate in the account management to customer success evolution BOF.

Thursday is the last day of sessions. I’m going to learn about successful drupal integrations then focus on growing talent & margins within your organization.

I am excited to participate and think I came up with a good schedule. Lucky for me, I’m not locked into any one of these and can easily bounce between sessions as the floor plan  & timing permits.

 

Do you suffer from “fear of making mistakes”?

We often talk about “fear of missing out”, but I’ve found that “fear of making mistakes” is a much bigger issue in the workplace. I’ve worked with project teams where this fear of making mistakes resulted in in lack of communication and frustration on all sides. If we are not willing to make mistakes, how then do we learn and grow? How will we solve the complex problems?

Fear of making mistakes has significant impact to communication among team members. Those resources that are afraid to make mistakes tend to be less forthcoming with details and information. If only positive or complete information is shared, project management and team dynamics become very strained. As the project manager, I want to hear all of it. Help me understand the true status – what’s working, what isn’t, what the next steps are and how you anticipate the changes to the schedule. I’m not there as a passive participant. I am part of the project team, one that team members can rely on to help minimize issues, remove obstacles and ultimately celebrate success. I can’t do that effectively when members only share limited information.

Unfortunately this problem gets more complicated as time goes on. The resource is afraid of making a mistake, so withholds information. This leads to frustration on behalf of the project manager, who may be required to escalate. This makes the resource more nervous, so even less willing to share the low points. Without the proper communication, timeframes, effort and quality of work all come into play.

The onus of identifying this problem and mitigating the circumstances falls to the project manager. The project manager may need to set of separate touchpoints with the specific resource, and review the individual tasks. Targeted questions on next steps, and precise estimates will need to tracked very regularly. Additionally, feedback, especially on areas that aren’t working or need improvement, will need to be clearly documented. All this needs to be handled delicately as I found the resources who experience fear of making mistakes are usually working really hard. The lack of communication makes it difficult for the project team to see the results.

 

 

4 Lessons on Team Dynamics Learned from My Kids’ Sports

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.