Category Archives: Customer Success

Project Managers: 3 Tips for Managing Project Schedule When Client Expectations Don’t Match Implementation Timelines

by

There are often misalignments in the available time for a project implementation and the full range of work that needs to occur. As a technical project manager, I have managed this scenario many times as a result of optimistic sales schedules, distorted expectations of the custom software implementation (versus installation of out of the box software) or a variety of other reasons.

Kenneth Darter wrote in a in March 3, 2014 blog post on ProjectManagement.com that there are 3 Methods to Managing Customer Expectations: Optimistic, Realist and Pessimistic. Different organizational groups lean towards different methods. An optimistic approach can result in customer & team frustration when hiccups or schedule slippage occurs, while pessimistic approaches sometimes breed mistrust as the estimates are so padded that nobody believes them. Realism in project estimation requires significant a solid understanding of the team players, the work that needs to happen & client expectations.

PM_constraintshttps://www.projectsmart.co.uk/understanding-the-project-management-triple-constraint.php

As Duncan Haughey pointed out in his December 19, 2011 post on Project Smart, it is often said that there is a 3-way constraint In all projects between cost, time and scope, with quality assumed. This has recently evolved to a 4-way diamond of cost, time, scope, quality, with customer expectations as the foundation. Without understanding the customer expectations, it will be incredibly difficult to you make the right decisions regarding cost, time, scope or quality.

Regardless of your primary method for setting schedules, you will always need to take into consideration cost, time, scope, quality, and most importantly customer expectations.

  1. Communicate the Facts – In reviewing the list of work before a weekend migration project, it became apparent that there were more machine hours of work to migrate some historical data than existed in the weekend of the deployment. Armed with the facts, I was able to talk the client into reducing the scope of the historical data migration for the deployment weekend and plan for remaining work after the fact.
  2. Discover the Business Motivation – During a data integration project with aggressive timelines, a client requested 2 weeks for internal validation. After initial pushback, it became apparent that the issue wasn’t our work, the client had data quality concerns from the source and needed to determine the impact to the business. We were able to tweak our approach to the project to help mitigate some of the concerns.
  3. Be Vigilant – As a project manager it is imperative to keep your pulse on the project. When snags occur (and they will), you need to communicate loudly and often to ensure the project team and the client understand what happened, why it happened and how it’s being resolved.

At the heart of every project are the client expectations. While there is an inherent quality you should push your project team towards, cost, scope & time will all radiant around the expectations and adjust as required.

favoritepicDagny is currently Managing Director at Digital Ambit, a consulting company focused on helping you with your data and software integration needs. Dagny has almost 20 years of experience in project delivery & customer success of software implementation projects.

 

Help me help you!

by

Recently I had a really frustrating experience dealing with one of my daughter’s teachers that reminds me of conversations I have had both with my project teams and with customers. Way too often I think we find ourselves in situations where a little more effort on one person’s side would ultimately result in a better solution or experience. It usually comes down to sharing just a bit more information. I want to be able to leverage all my experiences to give you the best experience, but if the other member of the conversation with-holds information, I am unable to do this. I ask that you simply help me help you.

In the case of this particular trigger event, I received a progress report for my daughter’s english class. Overall, she has been doing really well but there was one assignment where she didn’t perform as well. I immediately emailed the teacher asking for more information. I also talked to my daughter about the assignment. My daughter told she talked to the teacher about it and had done some correction, but the jist of the issue was that she didn’t understand a portion of what was required. About a week after this incident, my daughter came home from school distressed about whether she had english homework. We checked the portal but there wasn’t anything posted. Again, I immediately emailed the teacher to find what about the homework. I did not receive a response to either of those inquiries.

Thinking that there might be something wrong with my emails, I followed up with my daughter’s counselor. She received my emails and agreed to follow up with the teachers. She specifically asked me to follow up confirming I heard from anyone. Another week passes and I still haven’t heard anything, so I informed her counselor. I then received a few emails from other teachers, but still nothing from the english teacher. After about 3 weeks I received this really generic email from the english teacher letting me know that my daughter did not meet the grading criteria on the particular assignment in question. The teacher informed me that there were opportunities to make corrections, but this would not impact my daughter’s grade.

I found this response incredibly frustrating and not at all helpful. I am no closer to understanding whether it was an issue with understanding the assignment, or an issue with not being interested in the assignment. I also don’t have enough information about the assignment to talk to my daughter about how to handle the situation in the future. My daughter told me she talked to her teacher and made corrections, but the english teacher’s feedback made it seem like that wasn’t the case. I’m still stuck in this limbo state of not being able to effectively help my daughter because her teacher has failed to provide me with enough information.

How often have we had a conversation with a customer where they left out a critical piece of background information that would have changed the context of the entire project? Had you had that information, would you have delivered something different? Or in talking to a project team, did they make assumptions about your background therefore with-hold valuable information you could have contributed critical insights to?

My background spans multiple industries and multiple functions, making my experience fairly well rounded. As we become the experts of our field or industry, a common mistake is to assume everyone we are talking to has the same information you do. It might be a simple conversation where you use the acronyms or industry terms, assuming everyone on the call knows what you are talking about. Over the last few years, my roles were more customer facing than backoffice which meant that new technical resources didn’t know I had technical skillsets. This became pretty eye-opening when I started asking technical questions.

I do believe that we were able to deliver better results because of what I brought to the table. But without me challenging common assumptions or being willing to ask for additional information, we would have lost out. We each need to consciously try to prevent ourselves from censuring the information we share.  Let’s work together, helping each other, to develop a better overall experience and meet our collective goals with the best solution.

Prioritizing from the Get-go

by

As you may know, I believe many corporate resourcing & delivery issues stem from not properly prioritizing customers & projects. You can read my recommendations on how to approach those in my prior blog post. Today, I’d like to take a step back and look at prioritization from the onset of customer project introduction. In government contracting, this is called the gate review process.

A business faces immense pressure to succeed these days, facing obstacles from all directions. This might be driven from competition, or budget reductions and uncertainty, investor return or simple from cash flow concerns. Amidst all this chaos, the only real thing the business can control is how they behave. It is up to the business to pursue the business, then accept the business and support the business. Ideally all parts of the business are in sync about the choices being made. Unfortunately, that is not always the case. In my experience, most businesses pursue any prospect of business with a vigor and stubbornness, minimizing any negative feedback or concern. Many times this is done by simply not including other parts of the organization in the sales process.

These challenges can be overcome by simply asking the right questions (and following through with the outcome regardless of the answer) throughout the process. This process does not need to be too tedious. However, it should be thorough enough to have all pre and post involved departments participate in the conversation, being able to have their concerns heard, acknowledged and if possible, mitigated. Three simple questions you can ask during this process are: Can we do it?, Can we win it? and Can we make money?

Can we do it?

Fundamentally this is the first step. This step is really about reviewing your capabilities as and organization and determining whether you can deliver. Some ancillary questions include:

  • Do you have the resources? Can you get them in time?
  • Do you have the applicable skills?
  • Have you done this before?
  • Can you identify and mitigate the risks?

Can we win it?

This step is determining how you stack up to your competitors. It is also about doing an honest assessment of the work involved to ensure you can price within the required range to win it. Questions to consider include:

  • What is your existing relationship with the customer?
  • How do you stack up against the competition?

Can we make money?

While there may be reasons to pursue opportunities with limited margin, the answers to this questions should be most honest. Businesses exist to make money. Continuing to pursue opportunities where the prospect of doing so is limited puts the whole business in jeopardy. This discussion will put some key business assumptions to test about efficiencies, repeatable processes, or the reality of custom work. Questions to consider include:

  • What is the customer’s budget?
  • What is the contract type? Where does the risk lie?
  • Where do your competitors end up with price?
  • Can you mitigate the financial risk?
  • Are their efficiencies you can gain?

It is at the intersection of “yes” to all three of these questions where the optimal place exists for your business to pursue new customers or projects.  It becomes a slippery slope when only two questions result in “yes.” You may strategically choose to pursue business when you have two out of three, but these come with very severe risks. Wasted resources and degradation in customer success are two potential outcomes.

Prioritization is critical to business success. Having checkpoints at multiple stages throughout the sales & pipeline, customer success and PMO processes significantly improve your ability to work on the right projects for your customers. It also helps your ability to delivery and make money from your initiatives.

I want to thank David Stearman for his presentation on Gate Review Decision Making at the Association of Proposal Management Professionals-National Capital Area (APMP-NCA) Mid-Atlantic Conference last week. This blog post is a compilation of my notes and thoughts regarding project discovery & decision to move forward.

Be a resource, not a commodity!

by

I had the chance to see David Belden (founder of ExecuVision International) deliver his keynote at yesterday’s Association of Proposal Management Professionals-National Capital Area (APMP-NCA) Mid-Atlantic Conference. The topic of the keynote was “Relieving Anxiety in the Procurement Landscape.” At face value this didn’t sound particularly interesting, but just a few short minutes into the presentation I found myself taking my notebook out to starting taking notes. The key take away for me had less to do with anxiety and more about positioning ourselves to be resources, or risk being reduced to commodity status.

We all know that selling on price is not the ideal position. We also know that the pace of business has significantly increased. Unfortunately, only these two things matter when you are a commodity. I think we also know, at least conceptually, that adding value to your customers is how you differentiate yourself. Often we attempt to add value by sharing our methods and solutions for free. While these points are not new concepts, Mr. Belden really drove home the idea that every product or service is on the path to commoditization. He further concluded that our inherent reaction to differentiate ourselves results in becoming the commodity we feared we would become. Customers begin to know, or think they know, enough to comparison shop your solution. These are sobering thoughts as we work to grow our consulting company.

As for the preventative strategy, Mr. Belden challenged us to listen closely to our clients and prospects, with special attention paid towards their anxiety. Embracing your client’s anxiety allows you to become a valuable resource to them and can open up other areas of opportunity for you.

The Importance of Understanding Why

by

Last week my 16 year old daughter took her PSATs. While we were talking to her about how she thought she did, it became very evident that she had no idea why the PSAT was important. She claimed that nobody had told her. We discussed a couple of questions she didn’t know and whether she guessed or skipped them. We asked if she knew which option was the best choice for the PSAT. She didn’t know.

This entire conversation frustrated me quite a bit, as I attended a session with her in the Spring about planning for college and some of the major milestones, including the PSATs. Additionally, for most of the summer I was reminding her that she had access to SAT practice tests and she should make the time to take them as her time becomes limited once school starts. At one point in the conversation, I realized she was right. Nobody had explicitly sat down and said the PSAT was important for x, y and z reasons. The importance was implied within broader conversations, but never explicitly stated.

It was easy for me to extrapolate this problem to project management as there have definitely been in situations where you were challenged with a request for less than solid reasoning, mostly because the other person didn’t understand why you were asking. We see this all the time in features and functionality delivered to spec, but that never at all meet the needs of the requestor. To the person doing the explaining, their why is fully ingrained in their own experiences. Each time he/she does this specific process, they have to execute these workarounds because the business need has outpaced the software development. The software developer sees the requirement for the new feature, and implements his interpretation of it. Unfortunately, the lack of understanding of the business needs and processes often result in a working feature that doesn’t fully resolve the business need (although it might replace the workaround).

Flexible development methodologies that allow for knowledge sharing, iterative review and feedback loops are helpful in minimizing this type of issue. As project managers and analysts, we need to hone our ability to ask “why?” not just “what?” Our documents and artifacts need to be flexible enough to articulate both, otherwise there’s a lot to be lost in translation.

Building Trust

by

Trust is a big component of successful project management. Team resources need to trust that each will will do what he/she has agreed to do, and will do it proficiently. The project owners trust the project manager to effectively manage all the resources, and ensure the project stays on schedule and on budget. The project manager needs to manage trust both up and down the project org structure. Without trust of the project owner, there is uncertainty about the goals, resources and schedule. And without some level of trust of the team resources, the project manager won’t be able to effectively communicate status or have any confidence that the work will get done. Unfortunately, trust is also an area that can be severely lacking in project dynamics.

Let’s first address the trust dynamic between the project manager and the project owner and stakeholders. The stakeholders are those people impacted by the project being delivered. The project owner should be the project’s advocate and supporter within the organization. Lack of trust can manifest itself in several different ways including:

  • stakeholders not trusting the project team to deliver the “right” business solution
  • stakeholders don’t trust that the project team will deliver on time
  • project owner is skeptical of the project success

As project manager, your ultimate success (of the project and within the organization) is dependent on how you manage these concerns. Trust is not something given lightly, it must be earned. If you are working with this project owner and stakeholders for the first time, or had the unfortunate situation of a prior project not going well, you will need to assume there are gaps in trust. Once you recognize this as a challenge, you can take the necessary steps to move forward. These should include:

  • understanding the business objectives and challenges the project is supposed to resolve.
    • ask to sit with the business users and share their problem. This deep understanding will help the team deliver the right solution.
  • as much communication as required by the project owner and stakeholders to make them feel included (and informed).
    • Ex: weekly email statuses or twice weekly status calls; or a couple of in depth show and tell sessions. It will really depend on the organization and the specific stakeholders.
    • communicating setbacks or challenges.  Do not shy away from sharing, or feel you need to hide the negative. Doing so will negatively impact project perception, and is counter to the trust you are trying to build.
  • using agile methodologies to deliver functionally ready project components iteratively through the project timeline that you can show the stakeholders.

Next up is the trust dynamic between the project team members (resources and project manager). Again, there can be many reasons why trust is non-existent within the team. Some include:

  • New project manager or team members that have never worked together before.
  • One or more team members have previously demonstrated some undesirable traits (ie. not delivering, not communicating delays, etc).

The team members do not have to like each other, although that can help. The project manager’s goal is to foster enough mutual respect to trust that the work will get done, and  the right project solution gets delivered to the stakeholders. A few methods for doing this include:

  • holding regular project touchbase calls.
    • these can be daily standups, or twice a week status calls. Figure out what works for you and your team.
  • having team members share information about external activities and families.
    • This helps team members see how similar they are, and lets them see the passion and interests that drives each of them.
  • providing time for peer programming or “cardboard batman” sessions.
    • By allowing the team members to help each other, they build deeper connections and foster trust. It makes the project a team effort, not just isolated, individual work.
  • Setting clear expectations, then verifying them.
    • It’s important to provide as much information as you have at the time you have it. Requirements are more fluid than we all care to admit, but making sure you pass new information on quickly will help with trust.
    • As project manager, do your best to verify the work delivered. This may be internal qa or show and tell with the stakeholders.
  • Acknowledging mistakes and promoting successes.
    • People want to do a good job. They also enjoy when those details gets shared within the organization. The project manager needs to take time to promote the team members.
    • Mistakes happen. They can significantly impact the project so they can’t be ignored. More important than the actual mistake is figuring out how to fix it. Acknowledge it, and then find a solution to get it remedied.

There are many different skills that make you an effective project manager. All of them are for not, if you can’t build the trust you need among the team. I challenge you to take a hard look at your projects and make sure you are taking the necessary steps to build the trust you need to make the project, and your team successful.

3 steps to take when your project isn’t going well

by

In an ideal world, all our projects are on-time and under budget. The reality is that is rarely the case. More often, a project runs over on budget or timeline. For the nature of this blog, I’m not going to go into all the reasons why there can be budget or timeline overages. I want to focus on techniques for managing the impact. These very much tie into my approach to project management (you can learn more in this post).

  1. Communicate – At the first sign of a problem, starting communicating up and down the project chain. You want to make sure the project team are aware of the additional stress and constraints the stakeholders are feeling. This keeps them moving towards the end, but prepares them for some of the more difficult conversations they may have with stakeholders. Also important is having an honest conversation with your stakeholders and business sponsors. You need to make sure that everyone is on the same page. It is not about point blame, but rather collectively determining the next steps and discussing remediation options. This might include reducing the scope, or increasing resources or budget.
  2. Be positive about your successes – When projects take a turn for the worst, it is easy to dwell on what’s going on, focusing solely on how to fix it. Make sure you are positive about the successes. These may be as simple as just developing the use cases, or maybe the team has started implementation and development. Each moment of time spent on the project increases the project outputs, and creates positive moments. Leverage these to keep morale up and keep stakeholders engaged with what has been accomplished. It helps if you’ve split your project into small, incremental releases. It’s harder, but still possible when your project has more nebulous intermittent releases.
  3. Keep team moving towards some release date – Project crunch mode is a very stressful time for all those involved. When those culminate, you will want the team to regroup to determine what can be delivered in the shortest amount of time. Ideally, this has some, if not all, of the functionality that is most critical to the business users. You are always better off if you get something in the hands of the business users, as quickly as you can.

Murphy’s law definitely exists in project management. If it can happen, it probably will at some point. I find that it’s much easier to manage these rough times if I communicate (almost to the point of over-communication), be positive about the small successes the team has and make sure we have a plan to deliver something. It helps if the things you deliver are aligned to the stakeholder’s critical requirements. Most importantly, do not shy away from talking about your project issues. That just builds resentment and further uncertainty.

My Approach to Project Management

by

A couple of weeks ago, the project sponsor of a project I’m working on sent a really nice note in reference to my work. It said “Dagny knows her stuff and I like her approach.” Since then I’ve been really thinking about my “approach.” I know that I’m good at what I do, and in this case, I’ve been given the flexibility to run these projects my way. But still, I wonder what defines my approach.

In the end, I’ve come up with 3 core principles to my approach.

  1.  Questions, Questions, Questions – It is critical in any project you manage to be willing and able to ask as many questions as you need. This starts before you even take on the project in it’s entirety. Who are my resources? Are they dedicated or part-time to the project? Next is the deep dive into any specifications or other project documentation. What are the goals? What is being requested by the customer? What do the resources think it means? What does the development landscape look at? All of these are just to get you started. Once you manage the projects, it is still your responsibility to ask and push. This is the only way to understand what’s going on. It is also the only way to can effectively keep the stakeholders up to date, as well as truly be able to remove roadblocks for the resources.
  2. Communication – Once you dive in and ask all these questions, it’s equally important to document the answers and communicate the impact. This applies as much (if not more) to negative information as positive. Do not shy away from delivering bad news. Knowledge in an of itself is worthless. You need to make sure you are effectively aggregating, documenting and then communicating the information you find. Make it available. Your forthrightness will be appreciated.
  3. Oversight – I believe you need to check in with your resources and your stakeholders on a regular basis. A regular cadence of status meetings is recommended, but I would strongly consider subsequent email statuses delivered between meetings, especially for time sensitive/critical projects.

I think these 3 principles are at the heart of my project management methodology. They result in not just effective management of a project, but also help to build the trust you need with resources and stakeholders.

Just take a stand!

by

For as long as I can remember, I’ve been willing to make a decision. The decisions I make are not life or death decisions. I guess this probably makes it easier for me. However, I would say that few people are truly in a position where there decision is going to make a difference between life or death. Yet, I continue to be surprised by people drag out decisions, even the ones that are seemingly insignificant.

Last week I was talking to an independent sales rep for a personal and professional retainer-based service. This service is applicable to many people and is very reasonably priced for individuals, families or small businesses. It also requires no contract, believing that the value of the service will become evident and you will continue on a month to month basis. The sales rep commented about how difficult a decision this was for people.

In another conversation yesterday, I was talking to someone who oversees a team of consultants and project managers. This team is managing a very large number of customers and projects, but often the senior manager has to step in to an escalation situation. For the many of these, he’s is simply reiterating the delivery message around when the work will be started and completed. It became evident in the conversation that the project managers were very hesitant to communicate bad news, or make decisions on prioritizations.

In my customer facing roles, this was never an issue. I understood enough about the business to make a decision, and communicate that decision to both customers and management. I often presented the decision I was going to make, with all the applicable ramifications to management and confirmed their support. I could then effectively manage the communication to the customer. If a customer pushed back on the message, I was able to re-evaluate and re-engage the internal resources to see if any adjustments could be made. At this point, it was helpful to have a senior manager along to show support for the decisions.

The inability to make a decision and move forward is something I see in my teenage daughters as well. For them I suspect it has more to do with confidence than anything else. It is definitely something we are working to take steps to overcome. We talk about decisions (good and bad) and propose other solutions that would have been better. We encourage them to write stories and make little decisions that impact their lives.

When you get presented with that next decision, take a stand. If you can articulate your reasoning when you need to, chances are it will turn out fine. If it turns out that your decision was the best one, then use that knowledge the next time you make a decision. You will only be able to make better decisions by making them. In the broader scheme of things, that one decision will not be significant.

6 Considerations for Making System Migrations Successful

by

Every business makes a system migration decision. The frequency of these decisions has increased significantly, as the improvements to technology are delivered more quickly. Unfortunately, migrations tend to take much longer than everyone wants or thinks. My experience has shown that the following considerations need to be understood and carefully managed to have a successful migration.

  • Why are you migrating?
  • Are there hard dates that apply to the project?
  • How broad is the data or processes you are migrating?
  • How are you controlling the transformation (of data or processes)?
  • How and when are you validating?
  • What are the plans for cutover, training and UAT?

Why are you migrating?

There are always multiple reasons for making a migration decision. Some may be technical like obsolete hardware or degrading software. Other times it may come as result of cost. Regardless of the reason, it is imperative that you also provide business users a reason for the move. This migration will be an inconvenience and they will need to adapt to a new system. You should not do anything that impedes their ability to advocate for the new system. It helps if you can showcase some quick wins by delivering some new business value.

Are there any hard dates that apply to the project?

While this might seem like an obvious question to be asking, it makes a huge difference in project planning. With legacy applications, it is very difficult to plan for every unknown. There tend to be layers of configurations, application upgrades, and varying techniques for implementation and execution (read “spaghetti code”). While all projects should have timelines and deadlines, many times you can build a buffer window in to account for the uncertainty. Ideally, you are planning for future use not just blindly implementing a new system the way it was before. Now is the time to proceed with a fresh set of eyes while still maintaining the insights garnered previously.

How broad is the data or processes you are migrating?

This question tends to raise interesting responses. For all practical purposes, most business users use a finite set of data (year-to-day, 1, 2, 5 years). However, if you pointedly ask a business user what the minimum amount of data they could live with, inevitably the answer will be all of it.  This generally conflicts with how much IT really wants to store or with practical wisdom of data management. Over time, the system has changed, therefore the underlying data has changed.There is a real possibility that early data is of questionable quality and will add no real value for ongoing business use. It may also add some complexities to the implementation process as well. This is also wisdom for most process migrations. Unless you can demonstrate business value of leveraging less data or fewer processes, business users may be wary of the new system.

How are you controlling the transformation?

As mentioned previously, it is recommended to look at a migration from a fresh perspective. Often, this will introduce some requirements to transform the data or process. The application of business rules or assumptions must be fully documented. Additionally, any resultant changes in data or processes identified during the validation stage should be related to those business rules. Make sure the business users embrace the these decisions. If they do not, it will be challenging to get them to engage later in the implementation, or post implementation where critical eyes are determining whether this project is a success.

How and when are you validating?

There are quite a few different steps in the validation process that must occur in a migration. First, there are the basics of making sure your system is implemented and configured to your requirements. More critical is validating that the business use cases return the expected results. Your implementation team should be validating at each step of the way to ensure that issues are quickly identified and resolved.

Validation must occur using methods or interfaces the business users will use. There are general concerns and uncertainty about new systems and being able to provide validated results using agreed upon business processes can go a long way to appease them. Some anomalies are legitimate and they must be fully explained and documented. All sets of tests need to be documented, reviewed during training and UAT and made available to stakeholders in formal documentation or on an internal intranet.

What are the plans for cutover, training and UAT?

Business users need to feel comfortable fulfilling their most basic business needs. If there are nuances or differences on how to accomplish these or in basic assumptions around them, these should be highlighted accordingly. Next, it is helpful for the business users to learn skills that can deliver new business value fairly quickly post-implementation. The goals are to reassure business users that they can still deliver the value they did with the old system, but also that they have new functionality that allows them to deliver new value quickly. This may be as simple as making old value propositions better, faster or more robust.

During this time, the implementation team must quickly respond to questions, issues or concerns. These are the most basic interactions the business users are going to have and will start laying the groundwork for the trust that is required for an implementation to be considered successful. The ultimate goal is for the initial users to fully engage and become advocates across the organization. If these users fulfilled that role with the old system, it will be detrimental to success if that is lost. If these users were not advocates before, it is imperative to win them over.