To POC or not…

by

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

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

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

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

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

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

It really isn’t all about the numbers

by

Sitting at the intersection of business and technology means that I can interact with both groups. As a project manager who specializes in data projects, this often means diving into the analysis of the data, for validation, or understanding requirements, or more importantly to help craft a story, preferably around project success. Companies are becoming more data savvy, hiring Chief Data Officers and data scientists, and focusing on numbers to drive business decisions. I am very supportive of this, but we need to be careful to remember that it’s not just about the numbers.

numbers

More important is how we use these numbers to tell our stories. If your customer presents you with a problem, and a set of data that supports their conclusions, you need to look at it end to end to determine how to approach your story. Here’s a few thoughts on how you might approach it.

  • What were the assumptions made? In lieu of other information, we start with a core set of assumptions. It’s good to recognize and document these assumptions. It’s also good to challenge the assumptions if you have information not previously considered.
  • Evaluate your inputs end to end. Start at the beginning of the process and evaluate each step to understand the decisions made, and how those decisions impacted the outcomes.
  • Evaluate the outputs. There are so many opportunities to introduce uncertainty and inaccuracies into human process (data or otherwise). Was the data entry manual? Is there evidence of irregularities? Does the output make sense in relation to the logic of it’s corresponding process? Systematic logic is still at the whims of the people who write it.
  • Challenge the conclusion. While it’s important not to be defensive here, you do need to consider the “foregone conclusion”  and make sure it withstands probing and prodding. This is where perspective and point of view comes in. Make a conscious determination of the story you are telling based not the facts.
  • Communicate the deficiencies. If you go from one extreme to another extreme, swapping the entire frame of reference, it raises questions and credibility issues. As you are diving in and crafting your story, make sure to highlight deficiencies and inefficiencies of all components. Try to be balanced in your analysis, taking into account the work your customer took before it came to you.

There are lots of methodologies being used for diving in to real root causes (i.e. 5 whys, fishbone, etc). In data projects, it’s about being able to understand what the data is telling you and being able to convey that in a coherent and concise manner. Please don’t give me a bunch of facts, without an explanation of how you got there. This is the story. Understanding that data needs explanations, in the form of stories,  is why I do so well in managing my data projects.

How do food adventures relate to project management?

by

For the past two weeks, my family and I have been visiting Amsterdam, Antwerp and Paris. This was the first time my girls had been outside the country. Out of shear necessity, this also meant that we were exposing them to lots of new cuisine. Ultimately, trying all the new foods became a highlight of our trip. My girls learned a lot about themselves along the way. And I learned that managing people’s food preferences is a lot like managing stakeholders (yes, I had to tie it in to project management).

Our trip started a bit on the precarious side on day one in Amsterdam when the younger daughter was tired and hungry and offered up pizza or pasta as the only options for dinner. Since neither of those were of interest to anyone else, I suggested a Spanish tapas place. I figured I would be able to find at least one dish that everyone liked. We had prawns in lemon butter sauce, abondigas (Spanish meatballs), a potato and egg frittata, grilled octopus and several other dishes. I knew it was a winner about half-way through when Ana asked if I could make the potato and egg frittata at home. Cayla decided that grilled octopus was pretty tasty.

 Amsterdam is known for Indonesian food, and since the girls were being adventurous, we tried it. We did the traditional Indonesian rice table, where we were served a variety of dishes of chicken, lamb, beef, fish and shrimp, all covered in a different sauce. The experience was unique and Cayla declared this her favorite new food of the trip.

In Antwerp, we had traditional Belgian food including waffles and fries. Here we learned about the inclination to use mayonnaise and unexpected sauces on everything. Sadly, we ordered mussels before it was explained that you never eat mussels in months that don’t have an “r”.

We spent the last couple of days in Paris. Our first dinner we ordered both frogs legs and escargot to continue the culinary exploration. Frog legs were a favorite to eat, but the experience of eating the escargot was a highlight. We also learned that Parisians use dark chocolate in their ice cream. We ended our trip at our hotel restaurant, a very nice restaurant that showcased a 7 course chef’s tasting menu. The food adventure stopped short for the girls for this one, so we had to order regular menu items. We did make them try the amusebuch. This did not rank high up for the girls, but Carson and I enjoyed it.

Through all that, what did we learn?

  • You don’t have to like it, you just have to try it
  • Often food is about the image of it in your mind, rather than it’s reality
  • You really can find at least 1 thing on any menu you can enjoy for a meal
  • You don’t need to travel hundreds of miles across the ocean to start your food adventure

What does any of this have to do with project management? Actually, a whole lot more than you think.

  • This whole trip was about managing stakeholders; acknowledging preferences and balancing motivation (hunger, tiredness, etc)
  • Trying something new shouldn’t be under-estimated. If it doesn’t work, you can try something else.
  • Timetables and schedules are important even when not. We were on vacation so didn’t have a set schedule. We all had an idea of what we wanted to do and see, but exactly when or how were flexible. Despite all this, we still needed to manage to a schedule for food, relaxation and bed. It was clear when we made the wrong decision, or were pushing each other to our max.

Being more zen in your project management approach

by

For the last year and half, I’ve been doing yoga as my primary form of exercise. Before that, I had been attending a once a week intensive yoga class for about a year. I set a goal for myself to go at least twice during the work week, and then on weekends, I attend my regular Saturday and Sunday classes. Various classes are run throughout the day, with the earliest starting at 6am. I don’t go to those very often. My rule of thumb is that I will go if I am already up (i.e. after early morning airport drop-offs), or if I wake up naturally in time and it is still early enough to go after I try to go back to sleep.

This morning, I woke up, couldn’t go back to sleep so motivated myself to go to morning yoga. Maybe it was the early morning or the post workout coffee, but I started thinking about how yoga principles carryover to project management. And I’m not the only one. If the topic interests you, you can also read posts by Alison Sigmon, Workfront, Julie Miller,  and Katy Martucci.

  • Find your base – During most yoga practices, you spend the first few minutes centering yourself and setting your intention. Additionally, many yoga practices require an engagement of your core and grounding in focusing on your breath. In project management, you base is your foundation/methodology. It is the thing that helps you set the projection of the project, and you revisit as the project progresses.
  • `Everybody can fly – This picture was taken at a 4 hour acro-yoga workshop during the time when I was only attending 1 yoga class a week. Our instructor, Ginny Loving, is holding the base of my super woman, but it is my core strength and balance allowing me to fly. Similar principles apply in project management. With a strong foundation, anyone can manage a project. The more you strengthen the core, the longer you can hold the pose, the easier it will be to get in and out of it. Each project you run provides that experience you need to manage the next one. The more projects you manage, the larger initiatives you can undertake, and the easier it will be to navigate the ebs and flows of the project.
  • The devil is in the details – There are lots of different types of yoga. It’s important to consider the positions, chanting, intensity, heat, etc before you will find the one you enjoy (and this may change day to day). There are many different nuances to managing projects. You need to consider project goals, stakeholders & team management, risks, issues, self-imposed and external timelines, etc (and these too may change day to day).

This is just a fun, little example of how project management is truly related to most things. Where have you made connections between your hobbies and your job?

If you find project management boring, you might be doing something wrong!

by

 I saw a recent survey that concluded that project managers are the most bored at work second only to legal professionals. I had a similar conversation with my cousin a couple years ago. And similarly, I had another person tell me they found data analysis boring. On one hand, to each their own. Just because I enjoy something doesn’t mean others do as well. However, as I dug into each of these conversations, I realized there was a big difference between the work they were describing and the work that I perform under these same descriptors.

What is it that makes my kind of project management fun?

  • I get to solve real business problems – As an implementation project manager, I get to make sure that the solution implemented meets the business goal, and delivers customer value. I am the facilitator of change in the organization. Yes, there are some tedious tasks that may come with this, like daily status calls, project status documents, task management. But these are small components, compared to the larger component of bridging the gap between the stakeholders, and ensuring the business users get their needs met.
  • Big picture, small details – I get to do both. On one hand, it is my job to understand the big picture of my customer, of my company and then figuring out how to align all the small details to meet everyone’s goals. I am an advocate for the customer, and a feedback collector for my company. To deliver customer value, you really do need to be operating at both levels.
  • I get to be the playmaker – Related to the first bullet, I get to drive us to the end goal. I have to figure out the different puzzle pieces, and figure out how to organize them, in order to create the beautiful picture at the end. Since this is a work in progress from the moment the contract is signed, some times I have draw and cut out the puzzles pieces on my own; other times I’m given a couple of boxes of mismatched pieces and told to sort it all out.

To me, project management is only as boring as you allow it to be. I thrive on figuring out the challenges.

Why is it important to put process first?

by

…Or if not first, than pretty close to the top. The reality is that the focus is on implementation of the new system, not necessarily on the business process or workflows that make that system successful. It is a known fact among business owners that businesses need defined process to scale, and it is this scalability that allows for long term success. This is true in software implementation projects as well.

https://strativa.com/new-business-processes-and-new-systems/

https://strativa.com/new-business-processes-and-new-systems/

Let’s explore why that’s important.

  • Without process there’s no definition and no roles – In lieu of no direction, nobody has responsibilities and nobody knows what to do. This leads to two issues: 1) everyone doing the same as what they did before the implementation and 2) people trying to be helpful by throwing everything over the fence to the next person (i.e. asking every person who has a remote possibility of understanding what to do), and hoping for a handoff. This just results in frustration all the way around.
  • How do you implement the system workflows if you don’t understand the process? Many software systems (CRM, ticketing, ERM, BPM, etc) have workflows that need to get defined. If you don’t understand what the process is, or what you need it to be, how can you implement the workflows? While many of these workflows are changeable, it becomes more difficult to unravel once you starting using them.
  • Reconciling buy-in – How do you reconcile buy-in from all the different stakeholders if you haven’t figured out what the process is, and therefore don’t know all the people it will touch.

I realize every day how hard it is to put process first. I often get caught up in the minutia of implementation, or other tasks at hand, rather than focusing on the big picture. Process needs to be a part of a project implementation as the software integration itself. Consider this from the beginning of the project and you’ll save yourself and your stakeholders a lot of grief.

When change doesn’t go your way

by

There are always opportunities for improvement…”harder, better, faster, stronger.” That said, everything you try isn’t going to work out. Cliche, I know but still true. I had an experience outside the corporate environment recently that is having me to reflect on what went wrong, what i would change (or not) and how to recover quickly.

change-all-thingsI have been leading an external effort with a big goal. My team is composed of many volunteers all working towards the same goal. As part of this initiative, we just completed a multi-faceted online/offline marketing initiative. There was a solid group of volunteers working on these initiatives and they really did a good job. Logistically, we pulled off a larger initiative that in previous years. Unfortunately, despite the hard work of the volunteers, the outcomes were not what was expected or hoped for. As I was getting real-time updates during the execution phase, I started to realize that we might not see the results we had projected. We reacted quickly and made adjustments to the execution plan. Even so, the results were underwhelming.

What now? While I was saddened by the results, all I can do, and all I can encourage my project team to do is learn from the experience and move on. Here’s how I’ll approach this post mortem:

Remember that people put effort and emotion into executing change. It’s very important to remember not to point blame. This should be treated as a learning opportunity for everyone. 

  • Determination of too much or too little – This is the evaluation of the prep & execution plans to determine whether you did too much or not enough.
  • Support – Did you get the support you needed across the organization? Did everyone buy in? Did everyone do their part? Where did the breakdown occur? How could more support have been provided.
  • Eliminate technical issues as a cause – This involves checking each and every one of technical component (software, hardware, etc) that could have had issues. To the best of our knowledge, are they in working order now? were they in working order at the time of execution? “Working order” encompasses both the physical “did it work” and “did it perform its function?”
  • External factors – Were there external factors that could have impacted your plan? Common ones might be weather, mergers and acquisitions, politics, etc. Some times these do just get in the way. The goal is to identify the ones that impacted you this time, and review those risks the next time
  • Get up again – Ok, so this plan didn’t work out. It has no bearing on the next plan, or even the continuation of the current plan. We take what we’ve learned and apply it to the next round.

The success or failure of a project isn’t solely in the hands of the project team members. The entire project team, including the direct and indirect stakeholders have responsibility to provide the support needed. Further, it is the broader stakeholders that need to help pick the team back up and give them the leeway they need to make improvements the next time around.

 

 

 

Choose your words carefully

by

be-sure-to-taste-your-wordsWe are often reminded that words should be deliberate, and that sometimes words can hurt. In project management, these are applicable. More importantly, we need to be very conscious of the image that our words present. New projects are often opportunities to deepen the customer relationship. If all project stakeholders aren’t careful about the language they use, the customer or team can get the wrong impression.

Project managers need to have a very clear picture of goals of the project, and the nature of the relationship. It is our job to set the tone of the project. This means if any language is being used that might derail the tone you are trying to set, it is critical for you identify it early, and reframe the conversation.

Many of my projects are data related, which means I spent a lot of time validating data and demonstrating our process to the business users to explain how we got from point A to point B. As we all know, users don’t like change so the introduction of a new system brings distrust until you can prove that you’ve done what was expected (specifically the data gets validated). It is not uncommon for me to hear “it’s wrong.” Probing into that phrase usually results in the business users conveying additional information that would change the methodology. “The data is wrong” in the context of a data project is never where you want to start the implementation. Sometimes I will find that there is an upstream issue that gets uncovered during the implementation. Yes, that is a problem that needs to be fixed. But had we not been in the middle of an implementation, you might not have realized you had the issue.

Another example is configurable software. Again, people are very caution of new software systems, especially ones that proclaim predictive or advanced functionality. The easiest way to convince people is to configure a test. However, too often, the response will be the “algorithm is wrong.” Is the algorithm really wrong? The output is exactly what the software tells it to do. So if a test was configured to “show the art of the possible” with limited information about the specific business or use case, there is a high probability that the outcomes will be unexpected.

“Unexpected” does not mean the same thing as “Wrong”

These words should not be used interchangeable. “Wrong” sets the tone with the business users that the system isn’t doing what it needs to do. This creates very negative emotions towards the project. “Unexpected” can be explained, adjusted and resolved. Working with your project team to resolve unexpected results can foster respect, and positive emotions towards the project and the software.

 

What is the nature of this relationship?

by

dilbert-vendor-relationship

I had some work travel this week that took me onsite to a customer. My colleague and I were brought there to do some training and have some collaborative business discussions. This trip, and this engagement really highlighted the mutual respect the vendor and the customer have for each other, and how much we are viewed as a team.

This is not always the case. There are definitely times where the vendor-customer relationship is much more doctoral than collaborative. I wonder what is gained by this? It seems to me that either side of the vendor-customer relationship being too rigid isn’t a good thing. From the vendor perspective, if I’m always mandating exactly how something gets done, without having any flexibility to truly understand the customer problem, I get to maintain order and consistently replicate process. However, unless I’m able to truly predict where the customers are going, and can react really quickly to changes in the business process, this is not sustainable. At some point the customers will get frustrated that their needs are being met, and that the vendor isn’ work with them. Alternatively, if the customer is always pushing and dictating how things are done, they lose out on the learnings and growth that happens from supporting multiple customers. It can become increasingly more complicated to manage and maintain solutions that are only designed with one customer in mind. A vendor that kowtows to a customer will ultimately end up with both sides being frustrated.

There is definitely some middle ground in the vendor-customer relationship that will be mutually beneficial. The customer has a right to advocate for their business needs. The vendor has a right to try to standardize and streamline process and systems. It’s the details of the relationship that are going to bridge the gap. On the customer side, bring your concerns, share your business drives and let the vendor do the same. Let the vendor also bring their expertise and insights from multiple customers and have a discussion about the best solution. These are the only way that both organizations can grow and evolve.

Do you understand the nature of your vendor or customer relationships? Have you figured out the the right balance of how to make both organizations successful?

3 factors that contribute to products not delivering business value

by

A couple of weeks ago I explored the idea of when work is done. This week, I’d like to extend this idea to product management. We have all seen too many products where they promote they do X, but once you start using it you realize that it doesn’t quite do X, or X is so complicated to execute that it defeats the purpose. But how do we really get here? It’s unlikely that a product manager simply decided to push out a bad product. Or that the quality assurance team didn’t actually QA it.

Adobe-blog-product-meme-tell-me-more-extensive-testing-one-client

I think there are probably 3 contributing factors:

  1. Lack of customer feedback – Sometimes businesses truly are on the cutting edge in the development of something new and therefore there is no way to get the feedback needed on your new product (think iPod). However, this is usually not the case. We all need to make sure that we are engaging with customers and getting feedback on the products we are developing otherwise we pose serious risk to missing the mark.
  2. Misunderstanding of the business context – A common factor that occurs as a result of the lack of customer feedback is missing out on the customer context. You can think you know what problem you are trying to solve, and develop a product that solves that problem, but you’ll still have adoption issues if the workflow or functional assumptions don’t align to the business context of how the users will engage with it.
  3. Making assumptions about whether it will work without actually vetting the assumed changes – Too many times we get in trouble for being wrong based on an “I think” rather than an “I think, but I’ll verify and get back to you.” All products are built based on a set of assumptions. It’s usually these assumptions that drive how it gets QA’d. We can’t then assume that because the assumptions change (no matter how small they are), that all will work well. These new assumptions need to be vetted as well.

Product management and project management aren’t exact sciences. They do take a level of art and skill to be able to navigate the chaos and deliver on the business value. However, we can take steps to mitigate these factors, ultimately increasing our probability of success with our customers.