Finding your inspiration

by
WIT Leadership Awards

L to R: Julia Wilton, Dagny Evans, Emily Walter

Last night I had the pleasure of once again attending the Women in Technology (WIT) Leadership Awards celebration. This event “honors professional women who have exemplified leadership while promoting the WIT mission of Advancing Women in Technology from the Classroom to the Boardroom.” Maureen Bunyeen, long-time Washington news anchor, was our emcee. Not only to I get to connect with old friends, I leave inspired from the stories of the women finalists and winners.

This year the event opened with two special recognitions. First, Kathryn Harris recognized Maureen Caulfield with the WIT President’s Award for commitment and leadership as WIT Sponsorship Chair. Next, The Leadership Foundry, WIT’s board training program, recognized First United Corporation for leading the way in diversity of their corporate board with 33% of their board identifying as women. Then, STEM for Her, a local nonprofit focused on empowering young women to pursue STEM careers, recognized their 2017 cash and experience scholarship winners.

This brought us to our main event, honoring women across nine categories: corporate large-market, corporate mid-market, corporate small-market, government, rising star, small business/entrepreneur, technical leadership, unsung hero and women in defense. Each winner was humbled and inspired to be surrounded by amazing women. This year, winners shared their inspiration by reading quotes from people they admire. We heard about the importance of fathers in setting the path towards STEM related careers as well as having role models to emulate and aspire towards including Walt Disney, Ada Lovelace, Katherine Graham, Katherine Johnson, and Grace Hopper to name just a few.

Congratulations to all the winners! And thank you for raising the bar high!

What makes DrupalCon different?

by

DrupalCon BaltimoreOver the course of my career, I’ve been to a few conferences. Most were technical and most were related to the legal industry as that is where I spent the majority of my career so far. The last two years, I attended DrupalCon. Drupal is an open source platform for managing content and delivering websites. My business partner and husband Carson has been involved with Drupal for the last 6 or 7 years. Previously, I would travel to whatever city was hosting DrupalCon and would site-see while Carson participated in the sessions. Usually I would meet up with him at night for some of the social fun.

Last year, we decided there would be value in me attending the conference to participate in the business summit, learn a bit about Drupal and maybe pick up a few project management tips. I did all of that and more. You can read about that experience here. But, what made me go back?

When you run a small business, it’s really hard to take time away at conferences. Often, you still need to facilitate project work since you don’t have the luxury of a bigger team to pick up that work. Additionally, no work, no revenue. With all those considerations, we still both attended DrupalCon North America in Baltimore, MD. Why’d we do it?

  1. Proximity to DC and Opportunity to network with government contacts – While Baltimore isn’t our first choice for where I want to spend a week, it’s close enough that we didn’t really need to work for it. We drove up Sunday night and returned on Thursday evening. We also figured that the location would draw more government attendees. Since we live and work in the DC metropolitan are, we thought it would be a good networking opportunity.
  2. Global community – DrupalCon North America had more than 3,200 attendees from all over the world – Europe, Australia, India, South America.
  3. Willingness to tackle hard subjects – The Drupal community has been undergoing some serious scrutiny and challenging times as it relates to people’s choices and the perception & reality of that as it relates to an open source community. Many volunteers spent numerous hours coordinating community discussions, leading sessions and BOFs (birds of a feather) on diversity & inclusion and how to be an ally. The annual Women in Drupal event was the best one yet. We were glad to be sponsoring it again this year.
  4. The un-conference components – I can think of several parts of the conference that reduce the formality of the conference. Let’s start with the annual pre-note. This is fun, engaging sketch comedy formatted event that precedes the official keynote. It is usually comprised of drupal-themed songs, colorful costumes and a cast of characters. Then there are the BOFs, or birds of a feather sessions, are participate driven areas of interest to gather like (or unlike) minds to discuss. We can also include the unofficial “official” hallway track. I had numerous conversations with people this year about how they come less for the technical training and more about the community. Everywhere you looked you could see hugs, reunions and of course, the making of new friends. This year, one sponsor distributed flowers for the purpose of using it to thank someone who helped you. It was a little reminiscent of 8th grade or high school valentine’s day, but the sentiment was nice.
  5. Openness – Drupalcon always reminds me of the openness of the community. From the most basic example of vendors not being particularly elitist about who attends their large, very expensive parties to the level of details organizations are willing to share about how they run their companies and how they make decisions.

Thanks again to all the Drupalcon Baltimore volunteers and association organizers for putting on an amazing event.

Has discrimination made me a better project manager?

by

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.

 

 

 

 

The alignment of my project methodology to the lean process

by

I’ve written before on the implementation methodology that I tend to follow when managing my integration projects. If you missed it, you can see it here. I’m taking a lean six sigma course from Simplilearn and was pleasantly surprised by how well our methodology aligned to the lean process.

lean-six-sigma-process-flowStep 1: Critical to both processes is identify the value. Why is the customer engaging in
the in this activity? what are they trying to accomplish? how is it measured?

Step 2: In six sigma, the next step is to map the value stream. This step is about getting to the goals & requirements. In our integration methodology, this encompasses steps 2 through 8 and is the core of the nitty gritty details. Since most of my projects relate to data integration, I need to know:

  • where’s the data coming from?
  • what’s the source of record?
  • who owns it?
  • what’s the data format(s)?
  • how is the data accessed?
  • how does the data need to be transformed?
  • what’s the frequency of exchange?
  • what’s the trigger?
  • are there software requirements or limitations?
  • have yo closed the loop? do you need to?

Step 3: The process of defining and discovering the requirements and goals leads naturally into the development of whatever flow(s) you need. This is true from a data, development and dependencies perspective. This process also helps identify gaps, complexities, inefficiencies and bottlenecks.

Step 4: In lean, like in data integration projects, you must discuss and determine push versus pull. Lean is seeking out the most efficient solution, generating the least amount of waste. While that is the ideal in data integration projects as well, you’re often at the whim of the technology, or other decisions.

Step 5: Seek perfection in all things! In lean, this means developing a system without waste. In my data integration projects, this means developing the process that will deliver the cleanest, simplest, consistent, and reliable system. And for that you need to be vigilant in your measurement, and you can’t forget or forgo testing and validation. This is not a one-time endeavor. With data (and more and more processes (if not all) are driven by data these days), things can change. The importance of closed feedback loops, regular use and validation, the process and data become stale.

As the project manager for data integration projects, I believe that that we should all be looking for ways to simplify and streamline what we are doing to reduce errors and ultimately become more efficient. As we all know, there is a lot we can not control in project management (and in life). We need to be constantly re-evaluating our state and making incremental improvements. This is the core to both lean six sigma and my integration methodology.

For more information and case studies on lean six sigma, check out this “Learn Lean Six Sigma Part 1” article by Mohamed Elgendy.

 

 

When are you done?

by

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 differences between Customer Success and Project Managers

by

I had a recent conversation where I was challenged in my use of the term “Project Manager” to describe myself versus “Customer Success Manager”, the prevalent description for people doing similar work in their SAAS organization. This week’s blog post will explore the key differences.

I’ll first begin by providing some basic definitions.

Customer Success Managers (CSM) – According to Teresa Becker, CSMs provide “a proactive, real-time sales approach consisting of building relationships with existing customers, understanding in depth their company and product goals, and helping the customer meet those goals through day to day contact. Each customer has different needs and uses for your product, so it’s up to the Customer Success Manager (CSM) to thoroughly understand each customer and to be their champion throughout their entire customer journey. The role of the CSM is a value-add and is usually not a fee-based service.”

zombie-customer-success

Implementation Project Managers (PM) – Webopedia defines an Implementation Manager as “an IT project manager who focuses on implementing information systems into a business environment. The implementation manager oversees the task, ensuring the project adheres to budget and time frame guidelines.”

From my perspective, there are 3 core differences in the two roles:

  • Longevity  – Implementation PMs are generally involved on a short-term basis for the duration of the project, while CSMs are closely tied to the customer for the length of the customer engagement (or pending other customer alignment decisions).
  • Technical Skills – The technical skills required to do a complex integration or implementation are higher than those required to maintain the customer relationship. CSMs do need to understand the product, the implementation and how to apply the product towards achieving customer goals. However, the depth and breadth of technical skills needed to navigate the implementation process is usually much broader in scope.
  • Project Management Skills – Typically CSMs take on basic project management tasks in the process of deriving & delivering value to the customer. Implementation PMs are often required to dive into the more advanced project management tasks (detailed requirements analysis, project plan definitions, risk assessments, etc).

As companies continue to evolve, we’ll continue to see blurred lines between roles,  responsibilities and titles. Both of the roles will continue to exist, but what you call them really is dependent on the organization, the product and the implementation lifecycle.

Resetting project expectations isn’t a bad thing

by

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.

 

Do you want to be Joan of Arc or Martin Luther?

by

I participated in a panel discussion on Wed. March 8th for International Women’s Day. The panelist were challenged to talk about their bold moments in our careers and life. As I was thinking about this and deciding what I was going to say, I talked to my husband and dad. I’ve had quite a few moments where I made a decision and took action on something others might consider bold, where I saw them as a necessity to stay true to myself. Was I going to talk about leaving St. Croix at 17 to pursue college and my life in Washington, DC away from family and friends? Or the time I quit my “good” job working for a big, public company in 2011 without another job lined up? Or do I talk about the next time I quit my job to run a consulting company with my husband? I determined leaving St. Croix wasn’t bold, it was necessary. While I see the other two events as necessary as well, I also didn’t think it was too appropriate to talk about as the only person on the panel who didn’t work at the company hosting the event.joan-of-arc

In talking to my husband, he reminded me of some advice my father gave me when I was struggling to find my place years earlier. My dad told me “you can be Joan of Arc or you can be Martin Luther. Are you going to very publicly and loudly air your grievances, potentially going down in flames; or are you going to quietly nail your list of grievances to the door and live to see another day.”

martin-luther As we identify challenges in our work places or in society, we need to determine how we pursue “justice.” Each situation is different and you’ll need to make that decision each time. You need to weigh the risks and the rewards. For me, personally and professionally, the risks were always minimized by what I knew about myself. I will land on my two feet.

When I left St. Croix for college to a city relatively unseen with no family, I was encouraged by the fact that I had family in Philly, NJ, NY, all just a few hours away. I opted for a small, Catholic college in a city I loved minimizing the importance of the diversity of island life and the small thing that I wasn’t Catholic. I figured if I didn’t like it, I could transfer somewhere else. And that’s just what I did.

When I was struggling to find my place in that job in 2011, I took a hybrid approach to lay out the list of issues, and bring solutions to the table. Ultimately, I ended up quitting anyway as my sense of urgency didn’t align to the organization. As my husband says, I was the worst quitter ever, delivering volumes of documentation and hiring my replacement. The organization ended up delivering on their word, heavily investing in resolving the issues. I was told at the time that I needed to stay and work it out, learning to navigate corporate america if I was ever going to be successful. They brought me back as a consultant a couple years later.

And that time I quit my job again, to run a business with my husband? Three years later, business is good and no bridges were burnt. We’ve managed to grow and thrive, and still do work for our previous employers.

Life is made up of choices. As we are reminded to #BeBoldforChange, make sure to figure out who you are and what choices you plan to make.

Not at the top of my game this week

by

I was not at the top of my game this week. I don’t really know why. Yes, it was has been a busy week, but that’s usually not an issue. I’m working on a few different projects, all in different phases, and different level of engagement. That made for some comedic moments, but again, I don’t think that was the reason for overwhelming sense of chaos.
chaos And unfortunately, I did demonstrate my sense of chaos very publicly amongst my peers. Thankfully, it wasn’t so much evident to the customer teams I worked with, but it was clear to the internal teams I engage with.

On Wednesday, I expressed an extreme sense of frustration being adamant and forceful about pursuing an open issue that I felt was being brushed under the rug and told “that’s not an issue.” I was sure I was right. I compiled the “facts” and sent an email trying to communicate the necessary details so we could get it resolved. I coordinated a meeting about the issue on Friday, the earliest time I could get the right people on the call.

In the meantime, I did other work. On Friday, i get online and start checking different things. And on 3 different issues, I was told it was resolved but when I checked it I wasn’t seeing the resolution. The call comes around and we get on it and it was clear that I was a bit crazy. One of the attendees was able to explain what I was seeing, and clearly demonstrate that it wasn’t an issue for the customer. Not just on the issue from Wednesday, but also my other issues. At that point, I said was done and clearly needed to take the rest of the day off. I did go ahead and send an email to some of the team members thanking them for their patience and apologizing for wasting their time.

Ultimately, I probably wasn’t wrong for pursuing a customer issue that wasn’t getting the proper attention. But I wasn’t as respectful as I should have been in my behavior towards my fellow team members. I can say tomorrow starts another week, and it will be better. I can’t dwell on the mistake I made yesterday.

3 Signs you over-thought it!

by

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.

over-engineered-system

  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.