Category Archives: Operations

Recap & Top Lessons Learned from DrupalCon New Orleans

by

DrupalCon New Orleans was the epitome of “work hard, play hard.” The days were spent in intensive, thought provoking sessions, the nights were spent at the multitude of social events.

Business Summit

Monday was spent as expected, at the Business Summit. Susan Rust coordinated this year’s event and focused on 3 key areas: recurring & repeat revenue, killer marketing & new clients and leading with ease. The day was planned with presentations by corporate industry leaders followed by small group discussions and subsequent presentation of the key take-aways.

While the information was interesting and valuable, the business summit tended to raise more questions than provided answers for us as a micro-business. For example,

  • How do you ensure that you don’t exert too much emotional (or other) investment on too few customers?
    • How do you do this when the same resources are working in and on the business?
  • Do you find or grow your talent? And how do you do this without distracting from the revenue that keeps your business afloat?

Two critical sentiments resonated with me for most of the conference:

  1. Scaling your business is about process, tools & business infrastructure.
  2. Spending too much time working in the business will prevent you from long-term health & success.

We closed out the day by attending the Opening Reception and started collecting our DrupalCon swag (for me it was t-shirts and some awesome drupal socks).

Conference Session

Tuesday was the official opening of the conference. It started with some early morning global entertainment with costumes, Drupal parodies & skits followed by the official kick-off keynote by Dries Buytaert.

My first session was all about data structures in Drupal. This is a pretty fundamental component, and plays to my internal data geek, so I thought it would be a good place to start my technical Drupal education. Ron Northcutt did a good job of describing the structures and providing guidelines for making better decisions. If you ever get tripped up on the terminology or want a starting point in your Drupal education, this presentation would be good for you to watch.

For the remainder of the day, I stuck mostly to the business track. I attended the critical metrics for your drupal business session, hosted by Michael Silverman (DUO) and Dave Terry (Media Current). These guys dove into resources, tips and metrics we should all understand and track for our businesses. Some key points and resources include:

  • Know your goal or exit plan from the beginning
  • “Master the Rockefeller Habits: What You Must Do to Increase the Value of Your Growing Firm” by Verne Harnish
  • “Drive: The Surprising Truth About What Motivates Us” by Daniel Pink
  • “Traction: Get a Grip on Your Business” by Gino Wickman
  • Don’t forget to measure your culture (presentation highlights ways to do this)
  • To scale your business, you need to be accounting on an accrual basis
  • Sales Tools: Geckoboard, CRMs, templates
  • “A Win Without Pitching Manifesto” by Blair Enns
  • Recruting Tools: JAZZ, DISC, Perform Yard
  • “TopGrading” by Brandford D. Smart
  • “Bo’s Lasting Lessons” by Bo Schembechler
  • “How to Win Friends and Influence People” by Dale Carnegie

I also attended Jeff Walpole’s session on why and how enterprises get involved in the open source community and the drupal showcase GE and FFW case study. I briefly attended the birds of a feather “BOF” (adhoc session) for small drupal shops before I had to head over to the Women in Drupal event. Approximately 200 people showed up before heading off to the other parties.

On Wednesday, I played hooky in the morning before attending Jeffrey “Jam” McGuire’s session on the value of Drupal 8 technical features. This was incredibly valuable to me and I would recommend taking the time to watch this presentation if you aren’t already immersed in Drupal 8. I also attended the diversity in tech session by Nikki Stevens and Karyn Cassio. They shared valuable stats and practical actions we can control in our own behavior, before opening the floor for an honest discussion.

Thursday is the official last day of the conference so is a bit shorter, leaving room for the closing ceremonies and time for contribution sprints. I attended Aimee Degnan’s session on prioritizing your scrum product backlog for Drupal work. The focus was balancing “keeping the lights on” with new product features for a site or group of sites over time. The biggest insight for me had more to do with how to apply a similar model to working on the business and working in the business.

  • Your business (like a single site) is comprised of: primary value creation; supporting systems with direct impact to value creation and supporting systems with indirect impact to primary value creation.
  • Like a project, there is some overhead associated with running your business as well as the application and review of reporting.

We often apply agile methodologies to our projects, but we haven’t been as effective on applying them to our business.

The next session was Jody Hamilton’s talk on growing your own talent. Jody shared her experiences build Zivtech’s talent. She provided tactical tools & tips on on-ramping, quality, recruitment methodologies and evaluations. The key to doing this successfully is process. The biggest argument small shops have for not pursuing this is struggling to balance workload capacity with training resources. Jody challenged this assumption, pointing out that focusing on the work at hand is a short-term initiative. For long-term viability of your business, it’s imperative to think long-term.

  • Developing the talent to keep your culture, philosophy and work are a requirement to scale your business.

My final session selection was easy. I attended Susan Rust’s margins & maseratis talk. There were so many key points in this talk that I think you’ll need to watch it. Susan started with these 3 directives for successfully scaling your business:

  • Be data driven
  • Measure over time
  • Develop processes

From a practical perspective, I learned we have a lot to do including:

  • Documenting everything we do to deliver value to clients
  • Document the tools we use to do them, measure them, report on them (yes, document ALL the tools..)
  • Measure everything..per project, per person, per organization
  • Make sure to focus (aka specialize). Don’t be everything to everyone.
  • It’s all about the margins! Businesses that want to grow focus on revenue where businesses that want to scale focus on margin. It’s not that revenue isn’t important, but it’s more about changes in revenue that are most critical.

And lastly, we attended the closing ceremonies and the Drupal 6 funeral procession, with brass band and police escorts as we shut down New Orleans streets.

I hope you’ve enjoyed my adventure at DrupalCon New Orleans. I know from others that there are quite a few sessions I missed. I’m planning on watching the recordings of those over the next couple of weeks. I’d also love to hear about your experience and take aways.

Balancing Agility with Process is Really Hard!

by

Most of my professional experience has been in small, fast-paced organizations. I had one fairly short stint in a larger public company. During all these experiences, I’ve seen the constant struggle between agility and process. There are numerous studies that prove that companies need to react very quickly in today’s market in order to be competitive. Unfortunately, growth companies tend to pursue agility with pure disregard for process. McKinsey has done a few studies on this, here and here, that speak to the importance of agility but argue that the only way to achieve true agility is to have a strong backbone of structure and governance.

In my experience, the balance between agility and process (AKA structure) is very difficult to attain. When you are a company of 1 or 2, you do what works best for you. Hopefully there is some basic process around prioritization and execution, otherwise there might be a real struggle for viability. As you add additional resources it becomes more important to add some process. Resources need to understand the organization purpose (mission, vision, key performance indicators, etc) or everyone will be doing something different, making the whole very unstable.

Strong sales & organization leaders can overcome this, but they often do it at the expense of their own sanity. If a core group of people exert all their energy in developing sales and onboarding customers, they can compensate for the resources that are adding limited value. It’s at this point in the growth model where organizations struggle. It becomes apparent that some resources are severely underutilized while others are severely over-utilized. The focus of the conversation swings between the expense of training the under utilized resources or releasing the under utilized resources from the organization. In both these cases, the root cause has more to do with the process of onboarding resources. Does the organization invest the time to train the resources they have already or spend the time to find & train new resources? That depends on the resources and how they align to the organization. Some resources will be redeemable, while others are not.

Alternatively, there are many organizations that are so process oriented that they lose sight of agility. The focus becomes on making sure the process is followed, and the appropriate approvals are obtained. This is done at the expense of moving quickly.

Scale comes with being able to consistently deliver your product offering to your customers and add value in your area of expertise. If you have not designed a process around delivery or fully understand your product offering from your customer’s perspective (specifically how they derive value from your offering), you are likely to spend a significant portion of your time in fire fighting mode. Consequently, spending all your time fire fighting results in less time spent helping customers with the value initiatives.

I believe that there should be a balance between agility and process. Define a core set of processes that are critical to your product offering, set the groundwork for resources about why the organization exists (back to mission, vision & goals), but give them the space to make decisions and pivot as required.

 

 

The Curse of Your Procrastination

by

There are an abundance of articles on procrastination – ways to avoid it, reasons why it exists, etc. I wasn’t able to find many resources on how procrastination negatively impacts other people. When it comes to procrastination, It’s really not all about you! Your procrastination is impacting everyone you work and/or interact with.Procrastination Chart

As a project manager, this comes up quite a bit. The project manager diligently breaks down the work, assigns the baseline schedule and owns overall responsibility of making sure the work gets done. We rely on the project team to fulfill their responsibilities and ensure the work gets completed. If a single project team member procrastinates on any single task, it will have a trickle down effect on all other tasks that need to be completed. Procrastination by definition is the avoidance of doing tasks that need to be done. This does not include the scenarios where work goes more slowly as a result of a problem or new information. This is truly the work that a resource puts off because he/she just doesn’t want to do it.

While project managers know that this is a common enough occurrence, I think it’s human nature to assume your procrastination isn’t hurting anyone other than yourself. But in reality, it will impact anyone directly linked to you. A couple of days ago I got into an argument with my daughter for this exact topic. Her high school requires that each student fulfill 15 hours of community service during the course of the school year. While 15 hours over 10 months doesn’t seem that cumbersome, my daughter plays ice hockey September-March. She is on the ice 6 days a week and has to fit homework and other responsibilities on top of that.

Now that we are winding down hockey season, I asked her to conduct some research and  identify opportunities she could do over spring break. She promptly told me she “had it covered’ and would fulfill the hours, but when I pushed her for more details, she had nothing to offer. She assumed that I was pushing her because I didn’t trust her. That really had nothing to do with it. In prior years, we had to scramble to get everything done in time, rushing around in the last minute. Given my other projects and responsibilities, I need her to plan more effectively. I got quite frustrated with her as there is no real effort to do the research (the school provides a list of pre-approved organizations and activities). In this case, her procrastination doesn’t just have the potential for disrupting her grade, it will most likely disrupt my schedule as we have to cram 15 hours over the next month (and she doesn’t drive yet).

As you push off until later the thing you need to do today, please consider the impact you will have on those around to you.

3 Tips to Make Your Project Transitions Occur Smoothly

by

At some point during the course of a project, a transition must occur. Ideally this doesn’t occur until the end of the project when you are transitioning from the implementation phase to the support phase. Unfortunately there are times when transitions need to occur during the implementation phase. Regardless of the scenario, I have found that there are a few things the Project Manager/Organization can do to make this transition go more smoothly.

  1. Establish a process for project artifacts (specific documents and central storage) – While each project may have slight variances to a set process, the more aligned the project documentation is, the easier it will be for a new team member to come up to speed. At a minimum I think this should include standard templates for project status including decisions, action items, upcoming goals and most immediately resolved items; project plans; statement of work & change orders; and support documentation that provides the technical details as well as business rules that impact the implementation (what will the support team need to know to manage the day to day operations of the implementation?).  The central repository for project documentation makes it easy for anyone to step in. They know exactly what has been transmitted and can see the progression of the project over time. Without these, time is wasted on finding the components rather than really digging in figuring out the state.
  2. Establish a process for team hand off – Once the new team has had a chance to review the project artifacts, it is important to bring all technical resources together. When you work on a long term project and try to document all the nuts and bolts of what you did to implement, sometimes there are intuitive pieces you fail to document. These are components that are so obvious to you that they have become insignificant. However, new resources won’t know and won’t necessarily know to ask, unless they have faced that situation before. In the process of talking through the implementation to educate the new team, these details surface and can be captured.
  3. Communicate! – The need to communicate only becomes larger during times of transition. The project manager needs to be fully engaged with all team members and stakeholders. Being open and honest about the transition state yields a bit of flexibility among the project team and stakeholders. Make sure to leverage this time to ask the basic questions you don’t know the answer to you and level set expectations.

Project transitions are inevitable, but don’t have to be a horrible experience. Having the proper project documentation, a central project document repository, team hand-offs and very open communication will significantly reduce the risk and improve the success.

 

4 Considerations When Choosing Project Management Tools

by

Project Managers tend to be very opinionated on the “right” PM tools to use. This discussion, and interview question has always frustrated me. I strongly believe that it doesn’t matter what tool you as the Project Manager prefers, you should be able to adapt to whatever tools work best for the organization and your customer. If you Google “recommended project management tools” or “the best project management tools” you can between 34 million and 125 million results. In my experience, there are four key considerations I use for the basis of deciding which tools will work best.

Which-direction-Fotolia_50558549_XS-300x221KISS

Keep it Simple! The least common denominator is usually the best option. Tons of fancy features aren’t generally very helpful. Often times you pay for the luxury of having those available. Apply the 80/20 rule to your evaluation process – 80% of of your needs will be fulfilled by 20% of the features & functionality in most project management tools.

Audience

Who is your audience? The tools you leverage with your project team or for your own planning will probably be different than those you use with broader stakeholders. I have found that simple tools are often best. While I can develop a complex gantt chart, and will sometimes do so for my own planning, I find basic word-processing & spreadsheet applications are easier for less technical (or PM focused) audiences.

Proximity

Is your audience within or external to your organization or team? Often times you need to deliver project status and meeting notes to an audience with internal and external participants. These are more static update tools, rather than interactive. These tend to capture status, action items, changes, decisions, etc. This is the right tool for conveying priority or tasks to another team within your organization where you may share resources. Additionally, you will want to figure out how to make project artifacts easily accessible. This may be through an intranet for internal access only, or a collaborative/extranet solution.

If your audience is located in your same office, I would highly recommend using tools like white boarding and sticky notes to brainstorm and organize. Recent studies (here’s Inc’s write-up) have shown that leveraging less technical tools improves creativity and brain power.

Feasibility

This consideration encompasses cost and availability. Sometimes your decision is just made for you. If you are running your project budget or organization very lean, you’ll want to leverage open source or free software. Alternatively, if your organization has negotiated a software licensing deal that gives you access to specific tools, it may make the most sense just to use what’s available.

At the end of the day, don’t overthink your tool selection. Decide what your critical goals are, and find the tools that meet them. There are significant advances in project management tools that provide plenty of options. Not all of them are right for all projects, teams or organizations. Sometimes it best to get everyone in the room, using the most basic tools of all.

The Myth of the Project Plan

by

 

The Project Management Institute Project Management Book of Knowledge defines a “project plan as a formal, approved document used to guide project execution and project control.” It further specifies that “it should be used to document approved scope, cost, and schedule baselines.” In my experience, a project plan is treated heavy on the “formal” and “approved” and light on the “baseline.” I think the process of approval gives the perception of longevity on the life of the plan. This minimizes the impact of the project plan as a baseline. Unfortunately this misunderstanding causes many complaints about project delays and delivery.

I was struck by this Computer Weekly quote when I conducted a google search for “project plan”: “[It] is one of the most misunderstood terms in project management. It is a set of living documents that can be expected to change over the life of the project.” This is polar opposite to how I have seen the project plan treated. The project plan is usually created at the beginning of the project, based on a statement of work, with fairly limited information. Even in cases where all stakeholders understand that the project scope is fluid, the project plan is expected at the beginning of the project and is used for making time-specific business decisions (training, user acceptance testing, etc).

Historically this has resulted in project managers padding their project plans with additional time so that the project is guaranteed to come in on time. Alternatively, the project plan isn’t padded, but issues of either scope creep, or scope reduction occur. In all cases, decisions are being made to meet a deadline, often selected artificially, which only aligns to the information available at the beginning of the project. There is no consideration to the fluidity of project implementation and information availability.

It would alleviate quite a few problems in project delivery & success if we chose to leverage the project plan as a living, breathing document. As time progresses, and additional details are obtained, the project plan should be updated. As a project team, we would be in a much better position to make decisions, and set more realistic deadlines as we get into the details and work through the development. Furthermore, sharing regular status and having constructive conversations about the state of a project and the next steps result in a more successful deployment. 

 

 

3 Pitfalls with Allowing Technical Teams to Engage Directly with Clients

by

We all inherently know that our best options are to always to go directly to a source, whatever or whomever that is. In a recent post, I advocated for allowing your project team to engage directly with customers. While I strongly believe this allows you to deliver a better experience, I do think there are a few pitfalls to avoid.

bomb_clip_art_10552 1) Be careful about the “shoot from the hip” responses – Often times in design or business discussions an inquiry will ask “how long?”, “how much?” and it is common for people to “shoot from the hip” and give an answer. There must be a structured way to balance these casual conversations, with the reality of the project status, plan, resources, investment. Otherwise, you will get stuck in the never-ending project and perpetual scope creep.

2) Balance gut estimates with discovery – Everyone is in a rush to understand how long it will take to build this product, feature or system. You need to be able to leverage your knowledge of having done similar applications, with the project discovery you need to do to understand this particular project. Too often I’ve been caught in situations where I had to explain that while a team member said they had done something similar in 10 hours, this particular implementation was going to 40. At initial thought, this seems excessive, as compared to the similar project. However, once you start talking about all the additional project management, testing and discovery required for this one versus that other one, it becomes more palatable. Make sure you vet gut estimates with actual requirements and customer needs.

3) Avoid detours – A huge risk to allowing project teams to engage with customers directly is subtle permission this introduces to go directly to the project team. I’ve seen customers who will stop engaging with ticketing systems in lieu of going directly to project teams. This introduces quite a few disruptions to the process. First it makes tracking and accountability difficult as inquiries aren’t going into a central system. Second, it can overwhelm project team members as they try to balance assigned work with the customer engagement. The project team will sometimes feel that they “have to respond.” The project manager or customer success manager needs to step in and manage the process. The team needs to make sure that they are being responsive, but doing it in a way that addresses the customer priorities, and keeps the customer involved in making those decisions.

As I’ve mentioned before, I’m a huge advocate for engaging project teams with customers. This is not a free for all. There should be a structure and methodology, with appropriate accountability and check points to adjust for the changing environments.

4 Ways Project Managers Deliver Quantifiable Value

by

It is sometimes hard to understand the quantifiable value that strong, technical project managers bring to organizations. I would go one step further and say that some people question the value (of any kind) that project managers bring to the table. Like many in operational roles, project managers are blamed for project challenges, but are often overlooked after project successes.

I searched Google for articles on how project managers deliver quantifiable value. Mostly I found articles that were more conceptual in nature about why you need a project manager or project management office (PMO) or how to get the most value out of your PMs. I didn’t find tangible ways project managers actually improve the bottom line of the organization. In an age where every function needs to be delivering quantifiable value, I was a bit surprised. I know that strong, technical project managers are invaluable to organizations, and worth every penny of their cost.

Project managers deliver Quantifiable Business Value by:

  • Reducing busy work & obstacles for the project team – It has been proven that focused, dedicated time improves the quality and reduces delivery time of technical solutions. A strong PM will handle the busy work, allowing the team to do just that. Cost savings:  Reduced hours worked for project delivery & reduced hours of non-billable rework.
  • Managing the analysis & artifacts – This is an often overlooked function of a PM. A good PM will understand the business requirements and can help facilitate troubleshooting & testing. Additionally, the PM will also be able to write & manage the artifacts (project plans, requirements, implementation documentation), which become most critical during testing & supporting the development post-implementation. Cost savings: Reduced costs for testing, support & maintenance and facilitation of support functions away from high cost developers to less expensive support resources.
  • Reducing risk – A project manager will feel comfortable managing the scope, and making decisions. The PM is willing to have those tough conversations for prioritization. Cost savings: Reduction or elimination of unanticipated costs associated with scope creep. Additional cost savings come from keeping project on schedule.
  • Improving project delivery &  allows for new work – Lastly, and arguably most important, a good PM will deliver! Often organizations get bogged down by lack of prioritization resulting in all resources making their own decisions. This chaos slows the progress of project delivery. For all the reasons outlined above, a PM will delivery projects, which will open the window for new work from customers. Incremental revenue: When PMs deliver, customers deliver too! In this case, it’s in the form of new work.

Don’t under estimate the power of a strong, technical project manager for the success of your business. While you may wonder if you can afford the cost, I would argue that a PM can pay for themselves in what he/she delivers in return.

 

Use Cases & Technological Investment: The Technology Chicken & Egg?

by

In traditional manufacturing, it’s unheard of to purchase production grade equipment without knowing exactly what it will be used for, and more importantly how the significant cost will be recuperated. However, I have seen it first hand that this isn’t always the case with technological investments. It is not uncommon to make a significant investment in a software or hardware solution without fully understanding the business use case.

Courtesy of iterated-reality.com

Courtesy of iterated-reality.com

A September 2015 blog post by Jarvis on Technological Trends that Impress VCs emphasizes leveraging your business use case to make purchasing decisions. Similar themes include not going extravagant until necessary, improvising as you scale, and ultimately not making a purchasing decision merely because the technology is the best, but rather choose the best solution for your business.

A Workspace blog post “Investing in new technology – right for my business“, written by Mark Sharman, discusses some of these same points. Mark raises the concern of being carried away by all the technology bells and whistles, so strongly recommends having a business use case or cost/benefit analysis to fall back on. Additionally, the “real cost of the investment” needs to be fully recognized, inclusive of delays and opportunity costs of not doing something else. That said, Mark reminded us that surviving in business requires keeping pace with change, but thriving in business requires leading the change.

This effectively highlights the conundrum of use cases versus technology investment. If you make the investment to stay on top of changes in technology, will the use cases come? Or if you define the use cases, will you be leading the pack but putting yourself at risk?

Example 1

In one example I’ve seen, the CTO had implemented a massive initiative to move everything to the cloud. At the time, I oversaw highly critical, back office processes. While we had been in the process of reinventing our systems, it didn’t make a lot of sense for us to move into the cloud. It would have added extra layers and complexity, and moved us away from our data sources. However, the implication of not complying to the blanket initiative were large enough that I chose to define a solution where we would be able to move components to the cloud. After I left my position, a former employee of mine, who was still involved, asked why I had designed the system for the cloud. To him, it didn’t make any sense. I agreed, but explained the nature of the political decision I reacted too.

Moral of the story: Just because we can, doesn’t mean we should.

Example 2

In another example, I was working with a company to implement a very complex software solution. They made significant investment in this solution, and worked closely with us during the development and validation phases of the project. There were two project phases that each took 5-6 months to complete. After the implementation was complete, we didn’t hear anything else about it for another ~6 months. At this time, the company asked for a in-depth, technical and business training working through the business requirements through to the technical implementation. During that training, I was told that the team was still working on the use cases for how they wanted to leverage the solution.

It seemed to me that the significant investment in capital and time would have encouraged the need for a business use case before implementation, but that wasn’t the case. Should the company have made this investment without the use case? They were at the cutting edge of this solution, and were able to influence the process by taking a very hands-on approach.

Moral of the story: Sometimes it’s better to be first and influence the solution, than worry about exactly how you are going to use it.

I was talking to my mentor and friend, Dave Shuman, yesterday about this. He challenged that some of the newer, trending technologies lend themselves to investment first, then defining the use cases. The low barriers to entry from a cost and implementation perspective allows for that buy first, define later approach. Lean Startup development methodologies also lend themselves to building in incremental blocks, then iterating until you find the “right” product fit for your customer.

Final Thoughts

So whether you define your use case first, or whether you invest in technology first, you do need to figure out that sweet spot to getting to your return on investment. We all know how well it turns out if you spend all your money and have nothing to show for it.

3 Considerations When Managing Globally Diverse Project Teams

by

Global project teams happen more often than not these days making it no longer feasible to get everyone in a room to facilitate a project. As a Project Manager & leader for both global team members and global customer teams, I’ve experienced the added complexity of this on my projects.

A LiquidPlanner blog post by Tim Clark from October 2013 “7 Tips for Managing a Global Project Teams” highlights time zones, cultural, religious, and sociological differences. Mr. Clark also recommends staying on top of advances in software solutions to simplify the process.

Global Teams

My Experience with Global Teams

Inc. published “5 Tips to Manage a Team Across Multiple Time Zones” by Will Yakowicz in July 2014, which also had very applicable information. Mr. Yakowicz reminded us that we can’t work 24 hours/7 days a week, emphasizing a consistent schedule. He also encouraged us to leverage the latest technology, invest in airfare to facilitate team cohesion while also recognizing that we must be extra aware of those people who aren’t sitting in the same room as us.

In my experience, there are a few additional key considerations for successfully managing global teams.

  • Be Flexible – As the project manager, it was my responsible to facilitate the project. Some things do just get lost in translation over email, and it’s necessary to have a phone or video session. Unfortunately, it’s not all about me, therefore it can’t be all about my time zone. I often had calls in the early morning or late night to coordinate with Europe (EMEA) or Asia (APAC) as required.
  • Be Available – When you have remote teams, it is imperative for each team member to be more communicative than would be required if everyone was in the same place. I can’t hover at someone’s cubicle when they are based in Ireland, but I can make myself as available as possible, as well as encourage each of my team members to do the same, on any mediums used by the respective regions.
  •  Diligently Break Down Barriers – Communication is hard. It’s even harder when you’ve never met a person, other than via email or phone. More often than not, when you are driven to a phone call it’s to resolve an issue. I encourage you to take the time to introduce yourself and chat. By learning the personality traits, and what drives your team, you will be better able to motivate them.

Managing global teams is difficult. The pace of project delivery, technological advances and life adds to the complexity. However, it is the new normal. We’ll need to step up our game to learn to do it well.