Monthly Archives: July 2017

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.