Category Archives: Operations

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.

Don’t take for granted how far you’ve come

by

I’m inspired to write this by my 16 year old daughter, who is also our summer intern. I’ve written about her before so I won’t spend too much time on background info. Cayla will start her junior year of high school in about two weeks, and this is Cayla’s first job. She agreed to do it because she had nothing else to do. My husband and I definitely had high hopes for her. Not only did we want her to start developing skills she would need after high school, we also hoped that she would start developing an interest in technology, aside from just personal use. She’s spent the last two months helping consolidate and organize our marketing list; started on Node School; and started learning R so she could work on her data science project to predict who will win the next Stanley Cup. Cayla also started pulling the data she needs for her project and working through her project plan.

Throughout all this, I’ve been amazed by the basic skills in business (and business applications), data management, and project management that I take for granted. There have been ample opportunities this summer for me to realize how far I’ve come since I started my first professional job.

Basic Skills in Business Applications – My experience is all very business and analytics intensive. As part of that, I’m very familiar with vlookups (using one data element in one spreadsheet to dynamically find the data element in another spreadsheet), pivot tables, advance sorting and grouping. While it made sense to make sure to teach Cayla how to do vlookups and pivot tables (as needed), it never crossed my mind that we would need to show her how to sort by multiple columns. Or, that she could use Excel functions to find duplicates, or convert names to the same format using the split text function plus a formula to reformat them. After the first time Cayla spent 5 hours adding the same value to multiple records by copying the cell and paste over and over again, it was very clear that I needed to be more explicit in the instructions and guidance I gave. These are basic lessons that I didn’t even realize everyone didn’t know.

Data Management – Cayla has been working with downloading, cleansing and analyzing NHL statistics for the last couple of weeks. We have had several discussions around computers being stupid and doing exactly you tell them to do. When the computer displays duplicate records, instead of grouping by a single identifier, I am quick to recognize that something is different about the records. Cayla was always more inclined to say that nothing was different as she was looking at the superficial value of the player name. Once she started diving into the data, she found spaces, tick marks and commas that wreaked havoc on her data analysis.

Project Management – I know that everyone works differently, but I’m a huge believer in documentation. I’m an avid notetaker, in my handy dandy hardcopy, spiral bound notebook. I red ink (and blue and green…) spec documents, log detailed questions and explanations and am quick to make sure everyone involved gets the information. I don’t believe in hoarding information. I assumed this was a way of life. It’s really not. No matter how many times I have coached Cayla about clearly documenting her project work, or outlining her blog post, this is not intuitive or comfortable to her. I’m a firm believer that developing these skills will help her feel more organized, help her remember or reference information better and would make communication in whatever form, easier for her.

Each of these are just a small subset of the examples I encountered this summer mentoring and leading Cayla. As we continue to mentor and sponsor people, we need to remember how far we have come. Let’s take a step back and make sure we convey the information required for people to learn the critical skills we have. They may not retain them all, but the good ones will definitely adapt some of those skills as their own.

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.

Isn’t it just data?

by

There is a prevalence of news on “big data”. Almost every day, there is another story about how you can benefit from it. Despite all this, most people do not understand what “big data” means. This has resulted in my complete dislike for this term. Businesses have business questions and data. As businesses grow, they collect more data and the business questions change. This means that different methods are used for storing and managing the data; extracting and cleansing the data; and then analyzing and delivering the  results. Does it really matter if it’s “big?”

“Big data” is often defined by large volume, high velocity and wide variety. There’s no doubt that the increases in volume, velocity and variety of data has introduced new technologies and methodologies. These are not right for all businesses in all circumstances. In order to make the right choice, It is very important for businesses to understand:

  • how much data they have?
  • how quickly their data grows?
  • how much data variety exists?
  • what business questions are they trying to answer?

Once businesses have an understanding of what they have and what they want to accomplish, they can then start focusing on the tools and methodologies for leveraging what they have to get to what they need. Another consideration at this time is determining whether the tools that fit best for today are short term solutions, or whether they will grow with the business as the business needs change.

While I believe that “big data” is an overused term that many don’t really understand, I am a big supporter of businesses becoming more data driven. In order for this to be a success, businesses will need to know what they have, where they are going and what they are looking for. They will also want to evaluate the abundance of data storage, extraction, cleansing and analysis tools to determine which work best for them.

3 Hallmarks of Customer Service

by

I read a blog recently that discussed exceeding customer expectations in an e-commerce context. This got me thinking about customer expectations in the broader business sense. Customer service has been a huge part of my business education from my own family’s businesses as well as other successful small businesses I’ve been a part of. I do think there are a few variances to how you should exceed customer expectations in a business to business (b2b) environment as compared to business to consumer (b2c).

The most critical components of delivering exceptional customer service in a consulting environment are trust, honesty, and communication. While these all 3 go hand in hand, each should be considered a separate initiative you need to foster as your relationship develops over time.

Trust

Consulting, like many other types of b2b businesses, is built on trust. Your customers are trusting you as experts or supplemental resources. They are often sharing the most basic aspects of their business with you so you can provide a service. The entire sales, implementation and customer success experience is about building that trust. If you do something to cause that trust to be questioned, every decision you make comes into question. This ultimately challenges who the customer buyer is and what they believe.

Lack of honesty or poor communication are two ways that you can quickly and easily deplete that trust.

Honesty

I think we all know how important it is to be honest. Unfortunately, sticky business situations can often challenge our abilities. For example, the situation where you are the “expert” but don’t know the answer to the question; or where you were unable to complete one set of customer work because you were too busy with another. I have found that your best option is still to be as honest as you can. In the first example, you can say “I don’t know, but let me know find out for you.” This is generally an acceptable response. Customers tend to appreciate this more than making something up, then having decisions made based on incorrect information. It takes less effort to wait to make decisions until after you have the information than it does to have to make corrections later on.

In the latter example, it was regrettable for you to have gotten to this question at all. Ideally, you would have clearly articulated what you were going to accomplish and when, setting very clear expectations. This might have involved a discussion around urgent versus minor issues with respective response times. Depending on the customer relationship, this may have also included a more detailed discussion around your prioritization model (don’t have one, see defining your customer prioritization model).

Communication

Almost every misunderstanding comes from poor communication. This might be lack of communication or poorly articulated communication. It doesn’t matter as these are equally bad. Communication is how you are show your honesty to your customers and how you build that trust. It comes in many forms – from quick social media engagements to project engagement emails, to marketing sales contact and training materials. Your honest voice must carry through every piece of communication, in order to build and maintain trust.

Project Coordination vs. Project Management

by

For as long as I can remember, I have described myself as a project manager. I found it was the simplest way to explain what I did. In reality, I have been a Sybase database administrator (DBA), systems analyst, software team lead, business process manager, implementation manager and most recently, a customer success manager. At the end of the day, I get s**t done. I found that the term “project manager” was the simplest way for people to grasp what I do.

I have started to wonder whether I’m using the right term. As I compare my methodology to how others are managing projects, I wonder if “project manager” may not be inclusive enough. Additionally, the response I get from resources involved in my projects often is one of pleasant surprise. Their prior experiences or preconceived notions of what a “project manager” is has left them jaded and unimpressed.

A few years back I was brought into an organization by a mentor and former boss to help alleviate his workload so he could focus on raising money for the organization. Prior to my entrance into the organization, everyone did everything for their customers. There were no project managers. This resulted in project delays and the curse of constantly switching gears to focus on the biggest fire. At first there was subtle push back and doubt as to what value I was bringing to the table. Out of necessity and as a result of the influence of my mentor, the project resources started engaging me on the basics – timelines, status, meetings, etc. As I got more involved and took on more responsibility (i.e. owning the documentation, managing the communication, pursuing the missing information) those same resources started to come around to me as a “project manager.” I believe they view me as the exception rather than the rule.

More recently, I overheard a conversation regarding a project where technical resources were responsible for writing status reports and updating the project team. This very much confused me as I have always felt that this function was a core responsibility of the project manager. After probing a bit, I learned that the project manager did not understand the technical solution and therefore was unable to provide descriptive enough project statuses. I understand that the project manager is in an oversight role and will rarely understand every detail of how a technical resource plans to implement, but I don’t understand how they are going to oversee every piece of the project if they don’t understand individual components.

These are just 2 anecdotes that make me ponder whether I misunderstand what a project manager is or incorrectly associate this term to what I do. A good project manager requires equal parts operational understanding, technical skill and project coordination.

PM

Operational Understanding: To manage a project effectively, it is imperative to understand how that project fits into the big picture.

  • How does it impact the business unit?
  • What motivates the project owner?
  • How will it impact the project stakeholders?

If I don’t understand that the goal of the project is to significantly reduce costs or improve efficiencies in order to prevent layoffs, I may not see or understand the anxiety of the stakeholders or the project owner. I may also not know the right way to motivate the team or get to the root cause of disagreements.

Technical Skill: Furthermore, it is crucial to have an active part in the technical conversation.

  • How do you step in to test or troubleshoot?
  • How do you mitigate disagreements between technical resources?
  • How do you translate between technical resources and the business owners?

Technical skill allows me to get my hands dirty when required. It is the reason that I can play “cardboard batman” to work through complicated project issues. It also allows me to step in and mitigate disagreements between technical resources, and pursuasively communicate decision “whys.”

Project Coordination: Lastly, it is critical to know what goes into running a project.

  • How do you estimate a project task?
  • How do you allocate resources and make sure milestones are met?

This is the nitty gritty of running the project. It’s the logistics – status meetings and reports, milestones and gantt charts, task estimation, etc. These are the basics you need to know. Unfortunately it is not enough to make sure project successful. Only by combining the basics of project coordination with technical skill and operational understanding can you truly get s**t done.

Why do you need a cardboard batman?

by

I am not a software developer.  I do have some training as a database administrator, most of experience is in managing projects and teams for highly technical initiatives.  This ranges from shopping cart and credit card integration for an e-commerce site in the early stages of the Internet; the creation of automated renewal subscription processes; billing systems; customer portals; complex billing processes for publicly traded companies and legacy to SAAS migration of critical business software.  I raise my experience here as I want to talk about the principle used in software development called “rubber duck problem solving”, but which I have been using and calling cardboard batman for my entire career.

“Cardboard Batman” refers to the act of clearly articulating a technical problem and in the process solving it, without any help from the person you talked to (real or fake).  I have to thank my husband, Carson, for introducing me to this concept. I met my husband 20 years ago at a small, e-commerce startup.  He was the programmer and I was the project manager.  At the pinnacle of the dot com bubble, our days, nights and weekends were often filled with work towards an aggressive deadline.  This often meant that Carson would be sustaining himself on mountain dew and pizza and I was constantly asking “are you done yet? is it ready for me to test?”

Inevitably an issue would arise late at night with no seemingly easy solution.  After Carson would spend some period of time trying unsuccessfully to debug his code, he would call me over to explain what he was doing. This usually involved walking me through software code in the language du jour and trying to step me through the problem – both what customer problem he was trying to solve and what issue he was running into.  This is where my lack of programming skills became an asset.  In translating between the customer problem and the software code, more often than not, the issue would become obvious.

Over the years, I have incorporated this methodology into my project and product management.  It forces you to step back and rethink the problem you are trying to solve and the current solution.  In many cases, it has exposed a different, better way of doing something.  It has also allowed me to manage highly technical developers, database and system administrators, without necessarily having that classical training.

So, Do you have a cardboard batman (or rubber duck) readily available?

While we call it something different, the cardboard batman method is real and sound.  You can find more at this blog, youtube, wikipedia and even urban dictionary.

When does “jack of all trades” become “broadly experienced”?

by

I recently transitioned out of my most current job and have had an interesting perception shift since the last time I’ve done this.  Throughout my career, I have had opportunities to do a wide-range of activities and fill very diverse roles.  This has worked well for the small, growing organizations I have been a part of, as well as my own lifestyle and growth.  This did not work as well during times of transition when it was time to pursue other opportunities.

While my resume was full of successes and statistics, it lacked focus and singular, sellable skills. I was not a database administrator or a certified project manager or a business analyst, however I had filled each of those roles for some period of time.  The first time I recognized this, I supplemented my work experience with an MBA.  Re-entering the workplace in a startup as Director of Technology & Billing, as a doer and overseer, allowed me to leverage the skills I had.  This role further broadened my experiences in managing international teams, selling a company and global billing systems.  I would not have had these opportunities without the diverse skill set I brought to the table.  But this was a specific case of a specific company who was looking for my specific skills.

This time around, I feel the conversations are different.  I now have enough experience that my expertise is my diverse background in small and growing companies managing projects, processes and answering business intelligence questions.  I have found that the tone and questions I get from people during this transition are more about figuring out what interests me  and aligns more with my interests, than what specific skill do I have.  I am no longer the “jack of all trades master of nothing”, but rather someone with broad experience.

Do you recognize people for consistent or spontaneous effort?

by

Many years ago I worked a couple of stints for a kitschy fast casual restaurant, once in their merchandise store and then as a restaurant server.  As a server, I very quickly went from “newbie” daytime waitress to competent server who got to work the night and swing shifts with the rockstar group.  It was common practice to drive competition among the employees with hourly, daily and monthly goals and contests.  On the merchandise side of the house, these were pretty objective contests based primarily on how much you sold.  On the restaurant side of the house, there were objective contests based solely on sales and table turnover, but there were also subjective awards granted by management.

I was always amazed by how often employees were rewarded for “moments of brilliance” over those employees who consistently did their job, and did it well.  I have never been able to figure out if this was done with the intent to motivate the award winner to more consistently perform, or if it was just a matter of how the spontaneous effort was perceived through the course of that day.  For those employees, for that short period of time, they went above and beyond what was expected of them.  For that, it was noticed and recognized.  The rewards did not seem to impact their overall performance significantly increase the number of times they produced spontaneous effort.

Unfortunately I think this was actually quite demotivating to the employees who always consistently performed.  It was always assumed that those individuals would just do what they do.  I do not believe that the intent was to not reward those employees.  The impact of their effort was just minimized by the very obvious, very visible spontaneous effort of others.  Inevitably, the employees who consistently exerted effort left and everyone felt the pain of their absence.  However, that was not sufficient enough to break the cycle.

I’d like to challenge you to consider looking at the people you work with and make sure that everyone gets the recognition they deserve and need.  Do not single out people who have “moments of brilliance” without also recognizing those people who you can consistently rely on.