It has been an eternity since I last posted anything here. And that is because things changed and I lost my focus. My role changed at the company, twice in fact, and it is now that of a manager in a highly visible area where there is a criss-cross of management needs and customer needs, which don’t always jive.
My customers have changed, because they include the people I manage, who manage me, and the companies who buy our products.
When these changes in circumstances happen under a spotlight, the natural reaction is to react first and fix later, whether it be a product plan, a strategy or even hiring. And when you firefight and react to everything immediately, you lose focus. I know I do. So I have to fall back on my best practices and strategies for dealing with it, and these apply whether it’s software development, client meetings or hiring talent.
- Don’t just react, instead acknowledge. So often people react without thinking — look at how we behave in traffic — because they feel threatened or they think their job is in danger. Usually it isn’t and stopping and acknowledging that there is a problem, and what exactly what has gone wrong or right is the only way you’ll ever learn. And it allows you and your team to stop, discuss and focus on the problem so you can focus on your customer.
- Make a mind map and then make a list. If you’re not sure what a mind map is, check it out on Wikipedia. The short version is an connected yet not definitely structured (in terms of priorities) graphic depiction of your ideas. It’s a great starting place letting you figure out where you are running into problems, what kinds and how you can resolve them so you can go back to focusing on the tasks at hand. Once you do the mind map, make a prioritized list, with a backlog of items you want to check off. It’s a slow distillation process but worth the effort. Budget half a day for the whole exercise.
- Put your foot down. You may not have the ultimate power to decide anything, but make sure you have certain hard points or priorities that you are willing to fight for. They become your focus points of action. You may need to convince your team or your boss or your customer that these issues are important to resolving the issues your customer perceives. There may be disagreement, but be prepared to make your case why you don’t want to budge on these things.
I held a kickoff meeting last week for the customer feedback project I am leading and like all kickoffs, I found you need to define goals and deliverables in simple clear terms, and very crucially, define those terms and ensure there is agreement on them. And that requires a lot of forethought especially when you are dealing with people on other continents as I am.
Since I had done some background research on who would be participating in the project, I knew what their expertise was and what role they would play as well as what strength they could play on to help the project move forward. But to portray that in a way that made sense, I established 5 things that applied to all participants:
The project – What’s it all about and why are we doing this. If the direction isn’t clear (to you and the team), the participants will lose faith immediately. This is where you start to establish the terms you’ll be using, such as “feedback loop” or “target group.” The wording can’t be too vague and it has to be relevant to all people in the team. And probably most importantly, they have be motivated by the project lead and they have to know they will learn something new too!
The team – Who is who and what expertise do they bring to the table. That lets every one know who they can turn to for specific questions. Try to also see where gaps are when you assemble your team. These could be gaps in knowledge, in coverage, resources, or any other number of things. Anticipating gaps is hard but very useful.
The goals/deliverables – This seems obvious, but goals and deliverables are often confused. What do you want to achieve and in what format will you present the results that are genuinely implementable (if at all). Make sure the deliverables are acceptable to the person sponsoring the project and that they can be acted on. As for the goals, make sure these are attainable chunks comprised of clear tasks. Use a work breakdown structure to figure out what you want to do. This can and will be modified in the course of the project.
The timelines – Know the duration of your project and what are realistic blocks of time to accomplish your goals. And always plan in buffer for people quitting, changing roles, getting sick or the scope changing because the senior manager wants it that way. Above all be flexible.
The resources – What are the repositories, sharepoints, meeting minutiae, agendas and other tools you will be using to run the project. Do you have a proper project charter? Is there a place to store all your info that everyone can access? Did you set up regular meetings? Does the agenda make sense and cover all aspects? I am not counting the team members as resources here, just the tools you need to get the work organized and done.
So, that is what I used and the meeting went off perfectly. I even got praise from the sponsor and from her boss as well. Feels good when you have a plan and everyone understands it too.
Recently I was given the task of running a project that will create what is known around here as a Customer Interaction Framework. In short, it’s meant to determine what our internal customers need when they do their job with our product, and then find a way to get useful and meaningful feedback from them. And once we figure that out, create the framework so it can be applied to all the global teams so they can generate a feedback loop to build in improvements.
Man, that is a lot of work.
The project scope is meant to span the globe yet only comprises 5 team members. We decided that keeping the team small and staffed with people who not only have experience in this area, but who are also passionate about having a dialogue with their customers and encouraging feedback. It will focus on deliverables we know we can get good feedback on, and the people in the project all have their area of expertise.
But one of the aims of this project is to set up a framework where we can get pretty specific feedback on certain deliverables and then act on it at a global level. If we don’t, we run the definite risk of alienating our customers. The tricky part is that some people are nervous about getting feedback as they think it will reflect poorly on them personally. But we have to avoid that.
However, the prerequisite for success in this project, in my opinion, isn’t the team itself being competent or motivated. That was a given. It’s actually doing our homework at the start of the project to make sure we know who we are speaking to — so we can speak their language. This will entail mapping our deliverables to the project phases and the roles that come into play at specific points, and what those people in those roles need to get their jobs done. Not an easy task. But with a name like this, I never thought it would be easy.
I hope to post more updates on this topic as the year goes by.