Category Archives: Uncategorized

Realizing I’ve become a consultant

by

A couple of weeks ago, I had an epiphany about the role I was playing with the customers I support. For much of my time, I work on large implementation projects, but I spend a lot of the rest of the time working with customers in the role of Customer Success Manager (CSM). The goal of Customer success is help customers derive the most value out of the product, and ultimately helping them meet their business goals. As a Customer Success Manager, this can mean many things. I engage with both corporate and specific business teams, guiding them on the solution and helping them with their individual goals.

It was while I was having one of these weekly discussions that I realized my role had shifted. I was no longer just a project manager or CSM. I was contributing to their business strategy in a consultant role. A consultant is defined as “a person who provides expert advice professionally.” In this particular case, I was leveraging years of experience working with this particular product, in this particular industry. I wasn’t having a tactical conversation about next steps, or how to use the system. I wasn’t discussing the next corporate initiatives. I was sharing my business expertise to help them to determine how they could improve their overall success over the lifetime of this project, ultimately increasing their sales. I was providing value versus just assisting them in getting value out of our products.

In retrospect it seemed like such a silly moment for me. I came into my role with no prior experience in the industry or even directly the technology. My first 3 projects were highly technical and highly industry specific. I jumped in and asked many questions along the way. Almost seven years later, I’ve completed quite a few implementations and special projects, working with about a dozen large customers in the industry. I’m no longer feeling my way, along with my customer. It’s in under these circumstances, that I stand back and put my consultant hat on.

http://www.memegen.com

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.

 

 

 

 

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.

 

The impact of sales context on project management

by

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

by

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

by

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?

by

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

by

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

by

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”?

by

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.