Tag Archives: customer engagement

To POC or not…

by

POCs or proof of concepts are project initiatives to test drive a product to ensure it works for your business needs, and functions in the way it is promoted. From the perspective of the evaluator making the decision on what software application to invest in, they can make a lot of sense. It can also make a fair amount of sense to do a POC if you are the enterprise software service provider. This is a “simple” way to have the customer use the system and gives the software provider opportunities to engage the end users and create stickiness in key business functions.realty-check

There are several considerations that the customer and the provider need to make before deciding whether a proof of concept is the right approach.

  1. What’s the goal? Can a POC be created to cover the key requirements with reasonable effort, cost and time commitments of business users and the software provider? For software providers, on boarding a customer to specific functionality for a POC is no different than on-boarding that customer in a full implementation. There may be an additional level of involvement of both the business users and the software provider to make the business use case successful. Are all sides ready for this level of commitment?
  2. Is the scope small enough that it’s not cost prohibitive, but large enough that the solution covers the critical requirements for you to make a long term decision?
  3. What defines success and/or failure? Are you looking for specific outcomes (i.e. replacement of a specific system, improved performance, reduced costs, etc) for a set of business processes? Are there broader use cases that these component functionalities are only a small part of?
  4. Is everyone on board? Software POCs need customer decision makers, customer business users, and customer IT resources sometimes. They also need some combination of sales, developers, analysts, integrators, dev ops and project managers from the service provider. Does everyone understand the POC? Are they committed to the process? the goals? the fact that this is a POC and not a full implementation?

POCs can be quite successful. They can be a great way to quickly spin up a core set of functionality to enable customers to get in and experience what you have to offer. It works best when the scope is limited, and fully understood.

All that said, I think it’s still important to express what a POC is not. A POC is not a replacement for a full software implementation. The breadth and depth of enterprise software is way too complex to showcase, and hone all the business processes in a “small” POC. It is also not a trick to get development and integration components done before the actual project begins.

To POC or not is up to you, your company culture (and tolerance for these types of projects), and that of the software provider you are working with.

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.

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.