Category Archives: Customer Success

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.

 

 

Wisdom learned from the NOVA Ice Dogs Tier 2 U-16 Girls Team

by

My 17 year old daughter competed at USA Hockey Tier 2 Nationals last weekend. This was the culmination of many years of hard work for the girls and the coaches. This was the third year that her team declared “national bound”, meaning they would compete for for the right to represent the Southeast division at the National competition. Going into this tournament, our team was ranked 31st in the country, and were scheduled to play the 1st and 2nd ranked teams. Needless to say there was quite a bit of excitement and nerves surrounding the competition. I think we all have a lot to learn about handling ourselves based on this experience.

Rank doesn’t mean much

As I mentioned, the Northern VA (NOVA) Ice Dogs were ranked 31st in the country going into the tournament. Throughout the entire season, the team has been playing teams up and down the east coast. These girls definitely played up, or down, to the level of their competition. We saw them be extremely competitive to teams in Pennsylvania, Rhode Island and New Jersey but then lose to teams they should have beaten locally. This tournament was no different. The girls lost their first game to the 2nd ranked team 0-6, won their second game  and then lost to the 1st ranked team by only 2 points (0-2). Going into this last game, the girls were nervous. It was an evening game so they had all day to dwell on it, but played their hearts out. They had several scoring chances and played solid defense. The girls left that game knowing they deserved to be at Nationals.

I think we’ve all had experiences where we weren’t the first choice. We may know this to be true, or worse, just be worrying that it’s the truth. But the truth is, it doesn’t matter where you ranked in the process, you got it. You earned it. Stop dwelling and move on to get the job done.

Keep your head held high

The team worked very hard to get to Nationals, playing more than 60 games in regular season. This is highly unusual for National bound teams, as they tend to be more select tournament-only players, playing on other teams during regular season. Our girls did it. They made it to Nationals, but lost. The girls walked out of the locker room after their last game with their heads held high. As they should!

We all have had experiences where we’ve done everything we can but it doesn’t work out. That’s really ok. Walk away from that experience with your head held high, knowing there was nothing more for you to do.

Tenacity & Determination

During the regular season playoffs, and then again during the Southeast division playoffs, the NOVA Ice Dogs had multiple games where the opposing team took the lead about half way through. In each of these games the NOVA Ice Dogs came back to win. They could have walked away, demoralized and out of the game. They didn’t. They fought back and succeeded.

The obvious moral to the story is to regroup and refocus when things aren’t going your way.

 

 

How do you Brand your Project?

by

While I was looking for something to write about this week, I came across this blog on Branding your Project by Method123 Project Management Methodology. It got me wondering about my own projects and how actively, or subconsciously I do project branding.

At first I was hesitant to acknowledge that I actively branded my projects. However, as I thought about it more, I realized that everything I do to manage a project is done to effectively get the project to its finish line, and make it successful in the eyes of the project stakeholders. If the point, as the blog says, is “to associate an emotion or a feeling with your project”, then every deliberate action I take contributes to the positive project brand. This includes:

  • conscious communication, almost to the point of over-communication– There is a balance between airing dirty laundry and being honest about issues as they arise.
  • consistent and thorough documentation– the more you can document the project process and make available to stakeholders, users and those expected to support it builds credibility and goodwill.
  • building the bridge between business and technology-Removing perceived obstacles and making sure technical solutions meet the business needs results in better solutions, and happier stakeholders.
  • actively acknowledging hard work– project members, both from the implementation teams and the business teams, need to be recognized for a job well done. This could be as simple as thanking them for their flexibility as you manage meeting times across global resources. Or it could be for figuring out a really complicated problem.

I think establishing your project brand is a lot like the things you do to establish your personal brand. It reminds me of the phrase “do your job, do it well and you’ll be asked to do it again.” By doing the things you need to do as a project manager to effectively manage your project, you lay the groundwork for the project brand. Each artifact, milestone and decision point are opportunities to present the project in the best possible light. If you can’t, or choose not to, capitalize on those opportunities, you leave project perception up to fate. I would rather be deliberate in my message and my management, controlling the project image. You can do this successfully even when you need to deliver bad news.

So, what do you think? Do you actively or passively manage your project brand?

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.

 

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.

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.

Professional Services Leadership – 3 Reasons to Engage your Project Team with your Clients

by

There has been a long running discussion in professional service organizations about whether the technical project team members should be engaged with clients, or whether they should be sheltered from clients often under the guise of allowing them to focus on their task list. In my experience as a Project Manager and Customer Success Manager, I’ve found that allowing them to engage with clients directly streamlined project communication, and expedited the “right” development.

An April 2012 Inc article “The New Rules of Customer Engagement” by Wendy Lea outlines the new customer engagement paradigm. The focus has shifted away from single, often isolated touch-points to a much more integrated, customer-focused, results-driven experience. This particular article is geared towards engagement in social media, it drives home the point that customer service is no longer seen as just part of the sales process. Every conversation that happens, in any venue must be driven toward customer resolution.

https://s3.amazonaws.com/webmobi/Development/websitepics/customer.jpg

Web Mobi Customer picture

A October 2014 Survey Monkey blog post discusses 5 crucial reasons to engage your customer service and product teams as a means to deliver consistently great customer service. It argues that product project teams don’t spend enough time with marketing or customer service to fully understand customer issues and sentiments.

Overall, I think we can agree that being fully engaged with our customers, including fully understanding customer issues and sentiments, is imperative to our business success.  Even further, it is a given that our organization needs to be fully engaged across internal teams. I argue that the technical project teams also need to engage with customers directly. Three critical reasons include:

  1. It streamlines customer communication – When a technical resource needs to make decisions based on business requirements, it can be significantly easier to communicate a question directly to the customer. Critical details often get lost in translation when the technical resource communicates to a project manager, who then translates it to the business user.
  2. It simplifies the project management role – By allowing the direct communication, the requirement for the project manager to be technical becomes minimized. The PM should still understand the technology, but their focus becomes more of a facilitator and a remover of obstacles.
  3. It more closely aligns the customer to the technical team – When the technical project team engages with the customer, and visa versa, each begins to see behind the curtain. This allows each side to more fully appreciate the challenges and opportunities that exist. If the customer never experiences the technical process, or the technical team never experiences the business requirements, you lose the epiphany moments that come from truly solving the customer’s problem rather than more superficial symptoms.

I have seen great success with having my technical teams engage with customers directly. It becomes my role to manage the scope, prioritize the follow ups and generally keep everything on track. I step in to facilitate conversation or remove barriers to success, but don’t get in the way of progress. I challenge each of you to review your engagement model and figure out how to incorporate customer-technical resource communication.

Professional Services Organizations: Do your Project Managers Create Work or Remove Obstacles?

by

I’ve had several conversations lately with software developers or business management regarding project managers, and whether they create work or remove obstacles. As a project manager myself, I’ve felt that removing obstacles and allowing resources to focus on the tasks at hand is one of my top priorities.

In researching this issue, I found a September 2005 article by Scott Berkun “The Art of Project Management: How to Make Things Happen” that highlights that the ability for people to move project forward (AKA remove obstacles) is a skill that some people have, but others do not. Berkun proposes that this skill comes down to knowing how to be a catalyst in many situations, while also having the courage to do it. Additionally, projects move forward more when: prioritization occurs; “no” is accepted and appreciated; open & honest communication occurs; the critical path is known and the PM is relentless & savvy.

PM Technical Skill to Execution Matrix

PM Technical Skill to Execution Matrix

A more recent article published March 16, 2015 in MITSloan Management Review by Alexander Laufer, Edward Hoffman, Jeffrey Russell & W. Scott Cameron “What Successful Project Managers Do” emphasizes the organizational responsibility required to allow project managers to be flexible. This research article states that project managers need to: develop collaboration; integrate planning & review with learning; prevent major disruptions and maintain forward momentum. This ultimately results in a more fluid, adaptive project.

As projects have become significantly more technical in nature, the divide between project managers who create work or remove obstacles has become more pronounced. Technical implementation projects push this even further. As project leaders, we need to recognize the impact of technical skill and the too many active projects on ability to manage a project to its completion. There are 4 combinations on the technical skill to execution matrix:

  • Technical but Overworked – These project managers have the skill, but are not capable of removing obstacles because there are too many other projects on her plate.
  • Technical & Actionable – These are the technical project managers that are able to remove obstacles for their team. Often these resources get overlooked by the project team as they are seen as just doing their job.
  • Non-Technical & Actionable – These resources tend to be PMI certified so know the mechanics of managing a project, are able to remove obstacles without needing to fully understand the technical pieces.
  • Non-Technical & Overworked – These project managers also tend to be PMI certified so know the mechanics, but are overworked so they can’t focus on removing obstacles. Ultimately these pieces get pushed to project resources.

As a technical project manager, I have some bias about which quadrant the rockstars reside. However, there are some strong non-technical project managers who are able to successfully complete projects. This requires management support and a level of organizational prioritization that is really difficult.