Separating sales from reality

Have you ever participated in a conversation about a prospective new project to walk away feeling like the sales team has a very different sense of reality than you do? How do you balance that with defining realistic expectations and success criteria? unicorn, sunshine and rainbowsUnderstanding that it is sales’s responsibility to sell the deal and your responsibility to implement it, you also need to be very conscious to set you, your organization and your client up for success.

A couple of tips for doing this effectively include:

  • Speak Up – while this seems pretty obvious, there are a lot of reasons people don’t. Maybe, the person communicating is a boss or more senior coworker. There are numerous studies that show that senior managers aren’t challenged as much because subordinates are intimidated. As a project manager, you need to be one of the first to speak up. It is not about you versus them, but rather it is about you managing a project that’s going to be successful. It is your job to understand the requirements, the success criteria and level set where necessary.
  • Align to your internal team first – While speaking up is critical to project success, I would highly recommend aligning within your organization first. It can be incredibly alarming to your customer if you and other parts of the project or stakeholder team do not share the same goal and outcomes.
  • Do what’s necessary now to meet the requirements – If you are successful now, there are usually opportunities for dazzling (and/or upsell) your customer later. Data and software integration projects are complex enough. Don’t add another level of complexity by adding that one more thing because you think it will impress your customer. Focus on delivering all the requirements within the time and budget allotted. That said, if there are concessions you can make that have no impact to the requirements, it is ok to throw them in (but only after securing the requirements).

If you are a good project manager, you won’t always pick up a project that all “sunshine and rainbows and unicorns.” More often than not, there are challenges and opportunities you need to work through. Figure out where you are, identify the requirements and success criteria and start communication upward and outward often.

Make sure to write the weekly status report!

TPS_Report_MEME It really doesn’t matter how often you communicate with the project team, don’t forgo the weekly status report. I can, and do often think of several reasons why I “can’t” get to it, but having that status report has several key benefits.

 

  1. Aligns everyone to progress and issues – Many times progress and issues can get lost in the smaller, tactical project team. However, a software implementation can be quite a big investment and therefore impacts people outside the immediate project team. The weekly status report provides that source for where we are now, and where we are going.
  2. Ensures broader audience keeps your project in mind – While lots of people may need or want to keep the pulse on your software implementation project, other priorities can get in the way. By distributing your weekly status report you are managing multiple layers of stakeholders, and ensuring that your project isn’t forgotten.
  3. Credibility – building on the theme of the last blog post, status reports build credibility. If done in a way that gives an honest account of where the project is, regardless of whether it is going well or where there are opportunities for improvement, you are building credibility to you as a project manager and your organization (vendor, department, etc) as a partner.

I generally am on the side of streamlining process, and reducing administrative nonsense. In the case of status reports, they really are a critical tool in keeping everyone in the loop about where you are. If the stakeholders are new to you as a project manager, you may need to redirect people to your status reports, but generally, people jump on the bandwagon and like the more formal approach.

 

Building credibility one step at a time

bricklayerIt doesn’t matter if this is the first project with the customer, or the whether you have done tons of projects with them, each new project provides an opportunity to further build credibility (or lose it). From a project management perspective there are several tools that can be used to help facilitate this. The 4 critical ones I’ll dive into today are:

  • Requirements
  • Action Items
  • Issues log
  • Validation Sign Off

Requirements

I talked extensively in the last 3 blog posts about scope, which lays out the tasks that need to get accomplished. Requirements take this a step further, defining the business rules, and needed or wanted criteria. These are the nuances and details upon which the customer is benchmarking your solution. As a project manager, make sure you have these clearly documented, and understood by the entire project team. If there are questions or concerns, raise them early and often. If the requirements change, capture the details of the change and the decision (who & when).

Action items

Action items is a simple list of follow ups for the team. This are usually pre-requisites to accomplishing scope and requirements. This is less about a task list for the project development team, but more of a way to capture dependencies. Sallie can’t start working on X, until Tom provides Y. The resultant action item is Tom to provide Sallie with Y before she can begin working on X. These action items should be reviewed during the regular status call.

Issue log

An issue log captures open issues. Ideally, the development team could act as a perfect proxy for the business users and a project wouldn’t be required to go through user acceptance testing “UAT.” Unfortunately, the reality is that no matter how close a development team is to the business problem, nuances and use cases get missed. The issue log is the means to captures issues identified by project QA or business UAT. It tracks who, what, when, where & how.

  1. who reported the issue?
  2. what is the issue?
  3. when did this issue happen?
  4. where in the system is the issue?
  5. how can the project team replicate it?

Validation Sign Off

It is imperative in a project to receive validation from the business users. It is also important to capture who did the validation and any special circumstances that may have existed. In many projects, anomalies or unexpected results are identified but they don’t change the implementation. They merely need to be acknowledged by all the project development team and the business stakeholders and documented for future reference. These details can be useful in training and rollout as well.

Each of these tools are helping build credibility with the customer. They see that you are hearing them, acknowledging them and documenting the findings each step of the way. At no point should anyone be blindsided by the details of requirements, dependent action items, open issues or signed off results. These are fundamental to project management, and what a project manager needs to do to be successful.

Project plans are your source of truth

It’s been a while since I last wrote about project plans, calling them living, breathing documents. As part of the recent series digging into the critical components of scope and estimates, project plans are the next logical discussion point. Project plans are the manifestation of the scope and estimates. It comes in the form of gantt charts, excel work breakdown structures, calendars, etc.

The project plan, in whatever form, is a combination of tasks (scope), timelines (schedule ), resources and cost (sometimes). They can be high-level or very detailed. They should show dependencies among tasks. However, I would caution you to make them too detailed, as they aren’t set in stone, and making them complicated means it can be painful to update. Give yourself and your project team enough information to see what needs to happen, when it will happen, and discussion points for scope changes, issues, etc.

Most project managers have their preferred tool. My preference is the simplest tool for the project team. In my cases, this is usually a work-breakdown chart in excel. Excel is something that most business professionals know how to use. You also have flexibility in how much detail you provide and it’s fairly easy to update.

Most important is for the project manager to be regularly reviewing and updating the project plan. Always accurately represent where you are in the project. This is something that you should be sending out to key stakeholders on a weekly, or semi-weekly basis. It really does become the point of reference for discussions. Stakeholders may not read it, but you can use it to guide discussions, and point to it as the single source of truth. This is key.

Estimates are just educated guestimates

In my last post, I introduced scope. I defined it, explained how it can go wrong, and discussed the key role of the project manager to manage it. This week, I’m going to dive into some thoughts on scope definition and estimates. With everything I said last week about scope needing constant supervision and management, how is it possible to effectively define project scope?

scope-creep-monsterThere is a reason that we refer to the assignment of hours to tasks in projects as estimates. They are rough calculation, or less eloquently referred to as guesses. There are too many unknowns in software or data integration projects to be 100% correct, 100% of the time. However, there are definitely tips and tricks that we can use to get us a point where we are right more often than wrong (although that is a relative number when you consider that scope creep or changes are to be expected).

So, where do we start? We start with gathering as much information you we can about the work to be done. In the sales process, there are usually some very high level swag timelines thrown out, with caveats (AKA assumptions) that point to the need to fine-tune the timeline as the sales process continues. The next steps is to think about those tasks as they relate to functions and tasks your organization has done before. While it may not be the exact scenario, you can usually assign a relatively good initial estimate.

A common error in estimating is trying to estimate a task that is too broadly defined. Make sure you create tangible component tasks.

If a requirement is totally new, or you are using new resources, or there are quite a bit of unknowns, you need to take that all into consideration. You should look at similar work and then apply some multiple of time to account for your unknowns. This is where documenting your assumptions becomes critical. Like the scope definition, estimates and their corresponding plans (work breakdown structures, project plans, etc) are all living, breathing documents. They need to be reviewed, updated and acknowledged regularly.

A separate issue in all of this is the alignment of scope to project cost/budget. This are two very different things. When you are scoping a project, it is in your best interest to scope it fully. Do not consider the customer or organization budget in that matter. It is a strategic decision by your organization (sales, executive, etc) to decide what is charged to the customer for what scope. Negotiation of fees and scope will happen. Your goal should still be to stay as close to budget and timelines as you can, but understand that there can be other circumstances in play.

The biggest take-away to all of this is, you have to start somewhere! Monitor your estimates, update and communicate regularly and then learn from it. Apply the learnings to the next estimates you need to do.

Trust that your scope will change

The Project Management Book of Knowledge defines scope as the project boundaries. I prefer this definition on TechTarget:

Project scope is the part of project planning that involves determining and documenting a list of specific project goals, deliverables, tasks, costs and deadlines.

From a practical project management perspective, what does this really mean? Who gets to define this? How do you manage? Let’s delve into the details of a scope.

A very simple evolution of a project is sales > implementation > support. Scope is relevant in each of these phases, however it may not mean the same thing to the stakeholders key to each phase. A company agrees to invest money in a project to solve a business problem. A salesperson has convinced the company that they have the solution. Here’s the first step of the process where scope can diverge. Can the corporate decision maker speak for all the business stakeholders? Do they really understand the details of the business problem that needs to be solved for each type of user? And how about the sales person? Do they really understand the software? Do they understand the business problems it can solve? Are more technical sales engineers involved in the sales process?

That simple example involving just the corporate decision maker and the sales person is indicative of how scope can rapidly become a problem in a project.

Scope must be managed throughout the entire project. 

Over the course of my career, I have had different levels of involvement in the sales process. Some I was involved from the first demo/sales call with the customer, others I help with preparing estimates and potential timelines, others I inherit after the contract is signed and others I inherit long after the implementation. It doesn’t matter at what point I become involved in a project, my first action is to receive a copy of all project artifacts. And yes, I do read that contract. I want and need to know what was committed.

Unfortunately, I’m not done there. I take the details I can find in the contract and communicate those out as often as I can. If this is a large project with multiple business teams, I will review the scope with each team. This is the opportunity for your customer, and more specifically the business users, to vocalize their agreement (or not). Either is fine, but it is imperative to align expectations. If there is disagreement, it is the responsibility of the project manager to sound the alarm to the corporate decision makers, and the services and sales organizations. Misaligned scope results in 1) unhappy customers, 2) stalemate of customer and company or 3) mutual agreement to realign scope. Note: The scope doesn’t necessarily have to be immediately changed. It is sufficient for the new work to be phased in after the initial scope implementation.

This is definitely a rinse and repeat process. Business are changing on a daily business, and implementing data and software projects means your environment is constantly changing. Time doesn’t stand still during implementation projects. This means new inquiries and requests come up constantly. Each time, you need to figure out how it fits into the work you are already doing. Some requests can be easily accommodated, but others need a deliberate approach to determine how it impacts existing goals, timelines, budgets, and overall commitments.

Do not fear the scope. The scope is your friend. It provides guiding principles for the work you are doing, and the goals you are accomplishing.


https://www.tamingdata.com/wp-content/uploads/2010/07/tree-swing-project-management-large.png

To POC or not…

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

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?

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

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?