3 reasons to embrace your most vocal customers

So, you’re in the middle of a project and your customer spent the last 15 minutes telling you all the ways the are frustrated with how the project is going, and what you need to do to fix it. As a project manager, this can be quite disheartening. Often we put so much of our selves into our work and it’s hard to hear that your falling short. That said, I think we need to view this scenario from another perspective. Here are 3 reasons to embrace this vocal customer:

improvement_construction

  1. Engagement – If your customer is taking the time to vent their frustrations with you they are still engaged. At this point they still want the project to be successful and haven’t given up on you as a vendor. You still have work to do to resolve issues and mend the trust issues, but they are enabling you to do this.
  2. Improvement – Your most vocal customers are the ones that are pushing you to be better. These customers are sharing their intimate business challenges and opportunities and asking for your help in solving them. While it can be frustrating and  the relevancy to the organization may be foggy, this customer has chosen you to help them. Working closely on defining solutions together allows you to do a better job servicing other customers in the same industry.
  3. The alternative is futile – Doing nothing to respond to your customer’s concerns sets you on a very difficult path. This will ultimately drive your customers away. They underlying business requirement doesn’t go away in this situation so if you aren’t helping to solve it, so other vendor will. Additionally, if you aren’t constantly listening to the changing landscape of your customers’ industries, you aren’t able to iterate to solve those challenges.

Next time you are feeling a bit attacked by your customer, take a step back to breath and recover. Once you relax and realize this isn’t a bad thing, then you can identify your plan for exceeding expectations and delivering to the customer.

Do Project Managers still deliver value in 2017?

“Between agile and automation, project management is going away. There may be jobs with that title but the work will be very different.” — Kevin Brennan

I saw the above quote today on Twitter. Just like a couple of weeks ago, I was totally taken aback. Agile and automation doesn’t take away what a really good project manager can do. These are methodologies and tools that a project manager can use to deliver projects better. When I asked my husband, a software engineer, what he thought of the quote, he suggested that maybe these would drive the non-technical project managers into extinction.

I guess it all really begs the question of what does or what should a good project manager do? I’ve been asked to help train someone on how I run implementation projects, so I guess I should start putting to paper the criteria around what I do and why it allows me to deliver on implementation projects. I will start by saying that all project managers are not equal. This is a big part of the reason that many technical resources are so critical of the PMO and project managers. They don’t see the value and often feel that the project manager just adds work to the technical resources.

Above anything else, a good project manager should remove obstacles from the team and the project. This might be resource alignment, or a dependency from another department, or almost anything. Status meetings, project documentation and stakeholder management are merely manifestations of this work. The catch here is that the project manager needs to be technical enough to fully understand the nature of technical issues, and work with resources on getting them what they need to resolve them.

Second, a good project manager has the analytics wherewithal to assist business and technical resources. On the business side, the project manager can help bridge that gap between that user story or business requirement to the details of how functionality works, to ultimately helping coordinate the validation efforts further offloading work from the technical project team. On the technical side, the project manager with strong analytic foundations can step in at any point from requirement interpretation to design to validation/QA.

natural curiosity can also differentiate a good project manager. The ability to ask questions and drill into the details yields a great project management dividends. It shows your stakeholders and project team that your interested in what they have to say, and is instrumental in the trust building required to successfully deliver. Very few projects run without hitches. The desire to ask why can broaden the range of solutions, ultimately resulting in a successful implementation despite the twists and turns.

A good project manager will balance tenacity with adaptation. Too much happens too quickly these days for project managers to stagnate within in a set methodology, toolset or process. We too often see project managers so set in their ways, unfortunately often following the PMI rulebook to its smallest minutia. The moment the project offsets the delicate balance (of the PM), the delivery becomes jeopardized. Come to the table with your preferred methodology and toolkit, but be willing to be flexible during the project implementation. Ultimately, the project manager will be more successful.

At the end of the day, I don’t think being a good project manager is really difficult. I think a shift in mindset and the ability to constantly learn can make you successful. I’ll continue to do what I do and deliver projects. In the meantime, I’ll leave you with this description of a project manager, sent to me by a former coworker. He hadn’t been a fan of project managers until he had the opportunity to work with me on a project. In addition to the several job referrals, he sends me funny project management memes.

pm-meme

 

Project Managers need agility regardless of methodology

My Sunday morning peruse of Twitter led me to a blog post ‘Agile Project Manager’, It’s a Contradiction. Despite being a little taken aback, I did click through and read it. And I whole-heartedly disagree!

I’m going to start my response by first looking at some definitions.

Methodology – Merriam-Webster defined it as “a particular procedure or set of procedures.”

Waterfall – Wikipedia defined it as “a sequential (non-iterative) design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases.”

Agile – Wikipedia defined it as “a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.”

Process – Merriam-Webster defined it as “a series of actions or operations conducing to an end.”

Principles – Merriam-Webster defined it as “a rule or code of conduct.”

In project management, both Agile and Waterfall are considered project management “methodologies” used to deliver projects. They provide a set of guiding principles for getting results, and delivering business value. They both have pros and cons, and each is not right in every situation. Many times, a hybrid approach is needed.

Regardless of approach, a good project manager needs to be incredibly flexible. They need to understand the dynamics of all stakeholders, grasp the complexities of the value proposition and manage the situation throughout the process, adapting to the changing landscape. I would argue that even when using a waterfall methodology, a good project manager must be nimble.

It saddens me that the author of the aforementioned blog post feels that project managers “belong purely to highly planned deliveries where any change is a hinderance and fluidity is frowned upon.” Have they not ever worked with a good project manager that adapted to the movement of the project? Or have I just been incredibly lucky to work in organizations that allowed me to adapt and morph the project, and my role within in it as I see fit? It didn’t matter whether I was using a waterfall approach or were working towards agile.

The author further states that an agile project manager is a hybrid role, comprised of multiple responsibilities on projects not large enough to all the prescribed roles. I prefer to work within small to mid-size organizations, however usually work on projects for very large organizations. I’ve not had the luxury on any project to have a person to fill every role. Additionally, I think there is some level of getting your hands dirty in analysis, value recognition and other aspects of the project that enable me to delivery the projects I work on.

the-best-laid-plans...

http://www.azquotes.com/quote/608738

The one area where we did agree is “The ability to adapt, morph and practically deliver is…the true spirit of agile delivery.” I would also argue that it is the true spirit of a good project manager. If we are not constantly assessing where we are against our goals, and making decisions about how we manage the project (across stakeholders), and making adjustments to our plans, we can’t be successful.

Project Manage with Intention

Some-people-want-it-to-happen-some-wish-it-would-happen-others-make-it-happen

Sue Sotter – https://www.pinterest.com/susoutter/inspiration-to-be-intentional/

In doing my research for today’s blog, I read two separate articles that referenced “accidental project managers” as anyone who leads projects that hasn’t undergone formal project management certification. I’m a bit taken aback by this. While I don’t hold any project management certifications, I have done extensive studying of project management methodologies and am quite successful as a project manager. This isn’t by accident, but rather by intention.

I’m not going to argue the validity or value of having project management certifications, but I will argue that someone taking on the role of project manager isn’t accidental. “Accidental” means that it’s unintentional, unexpected and happens by chance. Is that really the case? Does our corporate leadership randomly pick an employee to lead a project?  Or rather, does the employee demonstrate some set of qualities or interest that results in project leadership? While the timing and recognition may happen at unexpected times; or the size or scope of the project may be larger or smaller than intended (by the management, or the person who solicited the additional responsibility), deliberate steps were taken to initiate this shift.

And my story? I transitioned from an operations role to a technical role when I became pregnant with my first daughter. At the time, it was thought that I would have more flexibility in a technology than in business operations. After a year or two as a database administrator reporting to misogynous boss, I handed in my resignation. I was asked to reconsider with the offer of a project management role. I understood both the business and technology; and had been at the organization long enough to understand how to get stuff done. I developed subsequent leadership (project & team) skills while getting my MBA and managing teams of technical and analytic resources (software developers, project managers, billing specialists, etc.) Every decision made along the way in my career, and when I manage projects are done with thought and intention.

While I don’t think the two articles were using the term “accidental project manager” as an insult, they were definitely on the side of promoting their products. They were trying to target the people who fill project management roles without having received any project management certifications. Maybe it would be better marketing to focus on being “new to project management” or “running your first projects.”

I on the other hand will continue to manage projects, building on my experience and constant reading, researching & self-learning. Practical application and incorporating lessons learned from post mortems supplement my experience and allow me to improve for each project.

 

 

Whose job is QA?

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.

 

Whose side am I on?

http://www.kappit.com/img/122260/whooo-what-a-week-im-so-glad-its-tgif/

http://www.kappit.com/img/122260/whooo-what-a-week-im-so-glad-its-tgif/

This has been a tough week. Not only was it busy, it felt like I was spending a lot of time chasing my tail. Unfortunately, it wasn’t isolated to a single client or project. It seemed across the board, I struggled to keep a handle on what was going on. The one consistent point is that neither the client nor the internal project team felt “I was on there side.”

A project manager or customer success manager for technical products are usually smack in the middle between the demanding customer and the product or project team. So, why then did this week bother me so much? I think it was because I am seemingly able to do a better job balancing everyone’s interests. I’m using today’s post to try and figure out what happened and what I can do better next time.

  • Don’t take it personal – First, I really do need to remind myself not to take it personal. As I tell my kids, “I am only responsible for my own behavior.” On the side of the customer, I am the representative of the company. It is my job to hear their issues and feel their pain. Sometimes that escalates if resolutions aren’t found quickly enough for their liking. On the side of the company, it’s my job to be the advocate for the customer. As a company, we need to realize that it’s not personal. We are each doing our job.
  • It’s all about the communication – This leads me to the second critical point. Everybody needs to communicate. The adage “no news is good news” doesn’t apply in project management. No news usually means that nothing has been done. As the advocate for the customer, it’s my job to follow up and get resolutions. At a minimum, at least tell when I can expect a response. This gives me something to tell the customer.
  • We are all on the same team – Lastly, we all need to realize we are on the same team. No matter how well a company “eats their own dog food”, the customers will always be the experts of the products. Just because they are using the system in a way that we didn’t anticipate doesn’t make what they are doing wrong. They are giving us feedback and making it better. Every time they uncover an issue or ask for something, they are driving us forward. Let’s embrace that. Let’s not assume that the customer is doing something wrong. The onus is on us to understand the use case and solve the customer problem.

I think this week’s lesson is pretty clear. I’m glad it’s friday as I need to regroup this weekend to tackle the open issues head on next week. Hopefully I will be able align everyone towards solving the problems. But as for the question I posed, we are all on the same team: product, services, and customers. 

Do your project managers focus on process or delivery?

I’ve struggled in the past with using the term “project manager” to describe what I do. It almost immediately triggers the question of whether I am PMP certified, and focuses less on my experience delivering projects. Additionally, I think there are quite a few employment roles today that include some project management responsibility. Doing basic project management tasks like scheduling meetings, doing status reports and checking the schedule does not automatically mean that you are able to deliver a project to its completion.

images

Rudy Gottschalk wrote a two-part series on shifting from “project management” to “delivery management.” He challenged all of us to look for a different approach, shifting the focus from project artifacts to project delivery.

“Too often project managers follow the rigors of a project management structure, but seem to have no sense of urgency in delivery or at times feel helpless to take control of the project delivery schedule.  They dutifully note progress, document issues and risks, and send minutes with the next meeting invitation. Since these activities fulfill the checklist of project management deliverables required by the organization, they usually give the illusion of progress, although little progress is actually occurring.”

I see this all too often in organizations. One manifestation is very large organizations, where a Project Manager from the PMO (project management office) AND a IT PM (AKA business analyst or delivery manager) get assigned to a project. In this scenario, both resources are expected to coordinate meetings, document decisions and communicate to stakeholders. The real distinction comes in their focus. The project manager tends to focus on following best practices and making sure every box is checked. Often, they are super cautious and tend to be more worried about creating the timelines, rather than the fluidity of project delivery. The delivery manager is primarily responsible for moving the project forward – removing obstacles, managing work assignments and facilitating ownership, driving towards a finish line. By not looking towards the endpoint, you sometimes end up in situations where there are incomplete lists of activities identified for project completion, incorrect timelines or lack of ownership and accountability.

Another manifestation of this problem can be seen in those roles with project management responsibilities. Often times, the immediacy of support tickets, status calls, status reports and the mechanics of the project “workflow” take precedence over delivering towards the end goal. Unfortunately, this can result in delays in getting to the value proposition. Ultimately, it also minimizes the importance of the critical analysis and seeing the overall picture.

If it is not obvious, I strong believe that project managers or those with any project management responsibilities need to be focused on delivery. This means focus on whatever the end result is, be it business value or a specific ROI. Without that target, it is easy to get lost in the logistics and workflow of managing a project, while not actually driving it towards a completion.

A Framework & Critical Decisions for Implementing a Data Integration Project

I have managed quite a few data integration projects. These are projects defined by the development of software and business projects that help organizations move data between systems and better understand the data they have. While each one is different in data sources, and project owners, overall my approach remains the same. I adapt the tools, timelines, and specific tasks depending on the organization and systems involved. Today, I’m reviewing the framework and critical decisions I rely on.

At it’s most basic level, data implementation projects have 4 core phases: Discovery & Requirements, Consensus/Sign Off, Development & Handoff.

  1. Discovery & Requirements – This first phase is most critical. It is at this point that you truly determine all that you need to know to design a solution.
    1. What business problem are you trying to solve? This lays the groundwork for everything else. Without knowing this information, it would be difficult to solve the right problem, or determine the right metrics by which to measure your success.
    2. Where is the data to solve the business problem? Now that you know what problem you are trying to solve, you need to understand where the data resides. This might be 1 source system or integrating 5 source systems. Are the systems internal or external to the organization? Does it only reside in someone’s head? Make sure to document the owners, stakeholders & gatekeepers. Your design could vary significantly based on what you find.
    3. What is the data format? This information and subsequent conversation should drive additional requirements around software, security, encryption and data transformations (AKA business rules).
    4. How is the data accessed? This should actually help you answer how should the data be accessed. Choose the best tool for the job based on the requirements documented in the prior conversations.
    5. What needs to happen to the data? Sometimes a project is as simple as making data sourced from one system available in part, or in entirety to another system. Often times, it doesn’t align exactly and business rules must be applied before it can be leveraged by other systems.
    6. How often is the data needed? And what triggers the transfer? Does one system push the data? Does the other system pull it? Is this an infrequent process? Or something needed real-time? or is there a triggering event?
    7. Which software is best? It’s finally time to start thinking about the tools, languages, & frameworks, etc. Also, make sure to include where the code resides & how security policies impact integration.
    8. How does feedback work? At a minimum, you need to consider how errors & exceptions are handled. In more complex implementations, data will flow both ways.
  2. Consensus/Sign Off – Document everything you learned and decided in the Discovery & Requirements phase. Everything from the high level problem to the detailed technical decisions that were made. Please, please get sign off from all the relevant stakeholders.
  3. Development – Development & validation go hand in hand.
    1. How will your results be measured? Write your test plans before you begin development. These are based on all the decisions & requirements documented in phase 1. You also want to do periodic data quality checks with the business stakeholders throughout the development process. There are ALWAYS things you find while engaging the business stakeholders, using real data, that you would not find on your own.
  4. Handoff – This is not simply a matter of flipping a switch and transferring ownership. This phase includes documentation, knowledge transfer during transition of ownership, and end-user training (if applicable). If not already, make sure the project artifacts are complete, compiled and made available to the organization. Often times, data integration projects require a period of hypercare where developers work closely with support people, and both the project implementation team and the support team work closely with the end-users, to make sure there are no gaps in knowledge.

Ultimately, the goal of data integration projects is information. There is some set of data in one system that could be made more useful or help derive better insights if connected with data from other systems.

Let me know if you think I’m missing any critical decisions in the process.

A infographic of this methodology is available in the case studies section of the Digital Ambit site.

5 Ways Managing Projects is like Creating the Family Meal Plan

I am a very food focused individual. I am a pretty good cook and I love to eat. In order to facilitate our weekly family meals, I do a large grocery shopping trip to stock the freezer and pantry with staples. I also visit the grocery store several times a week, if not every day, to pick up any additional items I need once I have been inspired to cook specific things. While I was dwelling on what we had already eaten this week, and what we had already in the fridge, freezer and pantry, I had the thought that this planning was really no different than the project management I do on a daily basis.

http://worldartsme.com/images/balanced-plate-clipart-1.jpg

I’m blending interests to and telling you about the five characteristics I look to create in both.

  1. Inventory – Before you go grocery shopping, you need to determine what ingredients you need. When you first get involved with a project, you need to do an inventory as well. In this case, the inventory allows you to assess what you have and what you need in order to make the project successful. At a minimum, your project inventory should include answering the following questions:
    1. What is the business goal?
    2. What product or solution was sold to the customer?
    3. Does an existing solution meet the need?
    4. What was the committed timeframe?
    5. Who is on the project team?
    6. What tools do you have? need?
    7. What is the budget?
    8. What are the risks?
    9. What are the success criteria?
  2. Variety – I believe in variety in food. This week alone we’ve eaten meals inspired by Italy, Latin America and the United States. In the project context, variety comes most often in the form of the project team. Ideally, my project team is very well rounded. It should include customer stakeholders who understand the business, as well as customer stakeholders than have the technical expertise to help validate and work through technical issues. Additionally, my project implementation team has a variety of skills, whether it be backend and fronted developers, or a data integration/developer and analytics resource. It also helps to have someone to bridge the gap between the technical solutions we are implementing and the customer’s business. Hopefully this me, but sometimes I have to leverage the subject matter experts.
  3. Balance – I’m a bit of stickler for offering a balance dinner plate. I try to always have at least one protein, starch and vegetable option at dinner. Sometimes, I succeed in getting more, and others it doesn’t happen at all. It’s important to create balance in your projects. Most often this refers to the balance established between the budget, scope and schedule. It’s the job of the project manager to set expectations and deliver a solution that meets the business goals.
  4. Budget – This one is probably the most obvious. It is a really good idea both in meal planning and in project management to know your budget. Sometimes, it’s small so you have take shortcuts and make different choices than you would if your budget was large. In the end, it really doesn’t matter what the number is. You need to make sure you know what it is, and drive the conversation around making the choices needed to stay within it (or increase it if you are so lucky.)
  5. Value – It makes me happy when my family and friends enjoy the meals I cook. Every new recipe gets evaluated based on a simple scale of 1) do again, 2) never do again or 3) make some changes and we’ll try it again, but reserve the right to scratch it off the list. A project must have a mechanism for determining completion and value. If there is no defined finish, you risk the never-ending project. And if the project never ends, how do you know if it has created value for the customer. Make sure you have established the success criteria you need to delivery the value you promised.

I hope you enjoyed my blending of my interests. It’s time now to go manage some client projects before heading into the kitchen to cook dinner.

Walking a fine a line

ayn-rand-quoteI write a fair amount about communication being critical in effective project management, but it is equally (if not more) important to be credible and confident. Being credible and confident allows you to more easily deliver hard news while still retaining the trust from the project stakeholders.

Given my track record of execution, I will often be brought into projects to implement a software solution but then hand off to a long-term customer relationship manager (or whatever you choose to call that role). Often times these long-term customer managers are not as technical as I am. As a result, it is much more difficult to be credible and confident in communication. I’ve been in numerous conversations where the less technical customer manager delivers information to the customer and it is not received well. Some of this occurs because the customer starts asking questions and the customer manager doesn’t have the knowledge, skill or confidence to answer. When I step in and deliver the same message or information, the customer reaction is much more amenable. This occurs because the customer trusts what I say (credibility) and believes that I have the knowledge and expertise to know what I’m talking about (confidence).

Credibility and confidence become even more important if you are pushing back on the customer. Without the effective delivery that credibility and confidence allows you, push back or hard news can be very difficult for a customer to absorb. The end result tends to be a battle of wills that takes you further from a resolution.

An example of this might be when the customer is reporting a series of issues, and voices concern about the overall adoption and effectiveness of the implementation. In reviewing the issues, you find that several of them are training issues that had been covered during the formal training sessions, but seemed to have been forgotten now.

  • One method of communication might be to address each issue separately, answering the symptoms but not the broader issues.
  • Another method is to clearly state that the issue is a training issue and users need to be reminded of x, y and z.

I do lean towards a very direct form of communication, that isn’t everyone’s preference, but it does lead to customers who truly trust me and believe that I’m working on their behalf. In the scenario above, I am more likely to tell the client that we need some refresher trainings since some of the critical basics seem to have been forgotten. Ultimately though I have built the relationship so that this is taken for what it is…a direct approach to delivering based on all my experience. If I fail to establish this relationship and still choose the very direct communication method, I risk alienating the customer.

Communication and relationships are complicated in managing projects. I find that project managers need to walk fine line between being direct and navigating the personalities, needs, and desired outcomes of the project. Establishing the credibility and confidence for whatever system or software your delivering will make your customer interactions easier and will smooth away some of the inherent caution associated with new projects, vendors, systems, etc.