If you find project management boring, you might be doing something wrong!

 I saw a recent survey that concluded that project managers are the most bored at work second only to legal employees. I had a similar conversation with my cousin a couple years ago. And similarly, I had another person tell me they found data analysis boring. On one hand, to each their own. Just because I enjoy something doesn’t mean other do as well. However, as I dug into each of these conversations, I realized there was a big difference between the work they were describing and the work that I perform under these same descriptors.

What is it that makes my kind of project management fun?

  • I get to solve real business problems – As an implementation project manager, I get to make sure that the solution implemented meets the business goal, and delivers customer value. I am the facilitator of change in the organization. Yes, there are some tedious tasks that may come with this, like daily status calls, project status documents, task management. But these are small components, compared to the larger component of bridging the gap between the stakeholders, and ensuring the business users get their needs met.
  • Big picture, small details – I get to do both. On one hand, it is my job to understand the big picture of my customer, of my company and then figuring out how to align all the small details to meet everyone’s goals. I am an advocate for the customer, and a feedback collector for my company. To deliver customer value, you really do need to be operating at both levels.
  • I get to be the playmaker – Related to the first bullet, I get to drive us to the end goal. I have to figure out the different puzzle pieces, and figure out how to organize them, in order to create the beautiful picture at the end. Since this is a work in progress from the moment the contract is signed, some times I have draw and cut out the puzzles pieces on my own; other times I’m given a couple of boxes of mismatched pieces and told to sort it all out.

To me, project management is only as boring as you allow it to be. I thrive on figuring out the challenges.

Why is it important to put process first?

…Or if not first, than pretty close to the top. The reality is that the focus is on implementation of the new system, not necessarily on the business process or workflows that make that system successful. It is a known fact among business owners that businesses need defined process to scale, and it is this scalability that allows for long term success. This is true in software implementation projects as well.



Let’s explore why that’s important.

  • Without process there’s no definition and no roles – In lieu of no direction, nobody has responsibilities and nobody knows what to do. This leads to two issues: 1) everyone doing the same as what they did before the implementation and 2) people trying to be helpful by throwing everything over the fence to the next person (i.e. asking every person who has a remote possibility of understanding what to do), and hoping for a handoff. This just results in frustration all the way around.
  • How do you implement the system workflows if you don’t understand the process? Many software systems (CRM, ticketing, ERM, BPM, etc) have workflows that need to get defined. If you don’t understand what the process is, or what you need it to be, how can you implement the workflows? While many of these workflows are changeable, it becomes more difficult to unravel once you starting using them.
  • Reconciling buy-in – How do you reconcile buy-in from all the different stakeholders if you haven’t figured out what the process is, and therefore don’t know all the people it will touch.

I realize every day how hard it is to put process first. I often get caught up in the minutia of implementation, or other tasks at hand, rather than focusing on the big picture. Process needs to be a part of a project implementation as the software integration itself. Consider this from the beginning of the project and you’ll save yourself and your stakeholders a lot of grief.

When change doesn’t go your way

There are always opportunities for improvement…”harder, better, faster, stronger.” That said, everything you try isn’t going to work out. Cliche, I know but still true. I had an experience outside the corporate environment recently that is having me to reflect on what went wrong, what i would change (or not) and how to recover quickly.

change-all-thingsI have been leading an external effort with a big goal. My team is composed of many volunteers all working towards the same goal. As part of this initiative, we just completed a multi-faceted online/offline marketing initiative. There was a solid group of volunteers working on these initiatives and they really did a good job. Logistically, we pulled off a larger initiative that in previous years. Unfortunately, despite the hard work of the volunteers, the outcomes were not what was expected or hoped for. As I was getting real-time updates during the execution phase, I started to realize that we might not see the results we had projected. We reacted quickly and made adjustments to the execution plan. Even so, the results were underwhelming.

What now? While I was saddened by the results, all I can do, and all I can encourage my project team to do is learn from the experience and move on. Here’s how I’ll approach this post mortem:

Remember that people would effort and emotion into executing change. It’s very important to remember not to point blame. This should be treated as a learning opportunity for everyone. 

  • Determination of too much or too little – This is the evaluation of the prep & execution plans to determine whether you did too much or not enough.
  • Support – Did you get the support you needed across the organization? Did everyone buy in? Did everyone do their part? Where did the breakdown occur? How could more support have been provided.
  • Eliminate technical issues as a cause – This involves checking each and every one of technical component (software, hardware, etc) that could have had issues. To the best of our knowledge, are they in working order now? were they in working order at the time of execution? “Working order” encompasses both the physical “did it work” and “did it perform its function?”
  • External factors – Were there external factors that could have impacted your plan? Common ones might be weather, mergers and acquisitions, politics, etc. Some times these do just get in the way. The goal is to identify the ones that impacted you this time, and review those risks the next time
  • Get up again – Ok, so this plan didn’t work out. It has no bearing on the next plan, or even the continuation of the current plan. We take what we’ve learned and apply it to the next round.

The success or failure of a project isn’t solely in the hands of the project team members. The entire project team, including the direct and indirect stakeholders have responsibility to provide the support needed. Further, it is the broader stakeholders that need to help pick the team back up and give them the leeway they need to make improvements the next time around.




Choose your words carefully

be-sure-to-taste-your-wordsWe are often reminded that words should be deliberate, and that sometimes words can hurt. In project management, these are applicable. More importantly, we need to be very conscious of the image that our words present. New projects are often opportunities to deepen the customer relationship. If all project stakeholders aren’t careful about the language they use, the customer or team can get the wrong impression.

Project managers need to have a very clear picture of goals of the project, and the nature of the relationship. It is our job to set the tone of the project. This means if any language is being used that might derail the tone you are trying to set, it is critical for you identify it early, and reframe the conversation.

Many of my projects are data related, which means I spent a lot of time validating data and demonstrating our process to the business users to explain how we got from point A to point B. As we all know, users don’t like change so the introduction of a new system brings distrust until you can prove that you’ve done what was expected (specifically the data gets validated). It is not uncommon for me to hear “it’s wrong.” Probing into that phrase usually results in the business users conveying additional information that would change the methodology. “The data is wrong” in the context of a data project is never where you want to start the implementation. Sometimes I will find that there is an upstream issue that gets uncovered during the implementation. Yes, that is a problem that needs to be fixed. But had we not been in the middle of an implementation, you might not have realized you had the issue.

Another example is configurable software. Again, people are very caution of new software systems, especially ones that proclaim predictive or advanced functionality. The easiest way to convince people is to configure a test. However, too often, the response will be the “algorithm is wrong.” Is the algorithm really wrong? The output is exactly what the software tells it to do. So if a test was configured to “show the art of the possible” with limited information about the specific business or use case, there is a high probability that the outcomes will be unexpected.

“Unexpected” does not mean the same thing as “Wrong”

These words should not be used interchangeable. “Wrong” sets the tone with the business users that the system isn’t doing what it needs to do. This creates very negative emotions towards the project. “Unexpected” can be explained, adjusted and resolved. Working with your project team to resolve unexpected results can foster respect, and positive emotions towards the project and the software.


What is the nature of this relationship?


I had some work travel this week that took me onsite to a customer. My colleague and I were brought there to do some training and have some collaborative business discussions. This trip, and this engagement really highlighted the mutual respect the vendor and the customer have for each other, and how much we are viewed as a team.

This is not always the case. There are definitely times where the vendor-customer relationship is much more doctoral than collaborative. I wonder what is gained by this? It seems to me that either side of the vendor-customer relationship being too rigid isn’t a good thing. From the vendor perspective, if I’m always mandating exactly how something gets done, without having any flexibility to truly understand the customer problem, I get to maintain order and consistently replicate process. However, unless I’m able to truly predict where the customers are going, and can react really quickly to changes in the business process, this is not sustainable. At some point the customers will get frustrated that their needs are being met, and that the vendor isn’ work with them. Alternatively, if the customer is always pushing and dictating how things are done, they lose out on the learnings and growth that happens from supporting multiple customers. It can become increasingly more complicated to manage and maintain solutions that are only designed with one customer in mind. A vendor that kowtows to a customer will ultimately end up with both sides being frustrated.

There is definitely some middle ground in the vendor-customer relationship that will be mutually beneficial. The customer has a right to advocate for their business needs. The vendor has a right to try to standardize and streamline process and systems. It’s the details of the relationship that are going to bridge the gap. On the customer side, bring your concerns, share your business drives and let the vendor do the same. Let the vendor also bring their expertise and insights from multiple customers and have a discussion about the best solution. These are the only way that both organizations can grow and evolve.

Do you understand the nature of your vendor or customer relationships? Have you figured out the the right balance of how to make both organizations successful?

3 factors that contribute to products not delivering business value

A couple of weeks ago I explored the idea of when work is done. This week, I’d like to extend this idea to product management. We have all seen too many products where they promote they do X, but once you start using it you realize that it doesn’t quite do X, or X is so complicated to execute that it defeats the purpose. But how do we really get here? It’s unlikely that a product manager simply decided to push out a bad product. Or that the quality assurance team didn’t actually QA it.


I think there are probably 3 contributing factors:

  1. Lack of customer feedback – Sometimes businesses truly are on the cutting edge in the development of something new and therefore there is no way to get the feedback needed on your new product (think iPod). However, this is usually not the case. We all need to make sure that we are engaging with customers and getting feedback on the products we are developing otherwise we pose serious risk to missing the mark.
  2. Misunderstanding of the business context – A common factor that occurs as a result of the lack of customer feedback is missing out on the customer context. You can think you know what problem you are trying to solve, and develop a product that solves that problem, but you’ll still have adoption issues if the workflow or functional assumptions don’t align to the business context of how the users will engage with it.
  3. Making assumptions about whether it will work without actually vetting the assumed changes – Too many times we get in trouble for being wrong based on an “I think” rather than an “I think, but I’ll verify and get back to you.” All products are built based on a set of assumptions. It’s usually these assumptions that drive how it gets QA’d. We can’t then assume that because the assumptions change (no matter how small they are), that all will work well. These new assumptions need to be vetted as well.

Product management and project management aren’t exact sciences. They do take a level of art and skill to be able to navigate the chaos and deliver on the business value. However, we can take steps to mitigate these factors, ultimately increasing our probability of success with our customers.

Finding your inspiration

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?

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?

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

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.