Why did my successful project launch feel like a let down?

by

I had been working on a very large migration project for about a year when we started preparing for the cutover day (AKA “launch”). As far as projects go, this was fairly typical. We started at an even steady pace, but as time went on we found ourselves putting in more work across the board to mark off all those little things that come up.

We had our punch list of prioritized issues, and work feverishly working through them. We were also aggressively determining/negotiating the true show-stopper nature of each of them. After a couple of close calls where it was unclear whether we would need to push the date, our launch kicked off. Every person involved with the launch had quite a bit of pent of nerves, excitement, energy, etc. Of course Murphy struck and we had to tackle those real-time, last minute issues. After several long days and very specific collaboration across teams, we were able to ultimately deliver.

While I was extremely happy to be live in the new system, this monumental effort (or what had seemed like it a year ago, or even 3 months ago) had no real impact. We did it! But now it was time to move on. The customer had been our customer for many years, and so we were not getting the benefit of working with a new customer. Nor were we getting to do anything new with an existing customer. It was business as usual. It was time to start thinking about all that work we had pushed off, while also helping the customer prep for their next operational weekly cycle.

Once the adrenaline faded, I looked around and thought about how far we had come. But there really wasn’t any fanfare. I’ve come to realize that this is a good thing. The project team had set out to accomplish something and we did. And it worked. And now it’s time to refocus and help the customer realize all those benefits they had hoped to get by the migration.

I was told there would be a break

Realizing I’ve become a consultant

by

A couple of weeks ago, I had an epiphany about the role I was playing with the customers I support. For much of my time, I work on large implementation projects, but I spend a lot of the rest of the time working with customers in the role of Customer Success Manager (CSM). The goal of Customer success is help customers derive the most value out of the product, and ultimately helping them meet their business goals. As a Customer Success Manager, this can mean many things. I engage with both corporate and specific business teams, guiding them on the solution and helping them with their individual goals.

It was while I was having one of these weekly discussions that I realized my role had shifted. I was no longer just a project manager or CSM. I was contributing to their business strategy in a consultant role. A consultant is defined as “a person who provides expert advice professionally.” In this particular case, I was leveraging years of experience working with this particular product, in this particular industry. I wasn’t having a tactical conversation about next steps, or how to use the system. I wasn’t discussing the next corporate initiatives. I was sharing my business expertise to help them to determine how they could improve their overall success over the lifetime of this project, ultimately increasing their sales. I was providing value versus just assisting them in getting value out of our products.

In retrospect it seemed like such a silly moment for me. I came into my role with no prior experience in the industry or even directly the technology. My first 3 projects were highly technical and highly industry specific. I jumped in and asked many questions along the way. Almost seven years later, I’ve completed quite a few implementations and special projects, working with about a dozen large customers in the industry. I’m no longer feeling my way, along with my customer. It’s in under these circumstances, that I stand back and put my consultant hat on.

http://www.memegen.com

Balancing the power between the technical and non-technical

by

Given recent events, the balance of power is definitely on peoples’ minds. As a female technical project manager, I’ve definitely seen my share of bad behavior as a result of an imbalance of power. But today, I’ll be discussing the power differential between a technical PM and a non-technical PM in managing a project.

I fully believe that everyone deserves a shot, and if you work hard and are smart, there’s really not much you can’t do successfully. That said, it’s a lot easier to manage a technical project if you have some exposure to the subject matter or technology. Hopefully you’ll get paired with another project manager who meets this criteria. Each project manager, the technical and the non-technical, have a core set of responsibilities we need to fulfill to our project teams. More importantly, I think we have a set of responsibilities to fulfill between each of us.

Three of the most critical include:

  1. Leverage your resources – Both project managers, the technical and non-technical need to figure out the respective strengths of each other very quickly post kick-off. As Victoria Yashchuk describes in her blog How is it to be non-technical project manager among technical developers?, not every technical term will be understandable. This could refer to both true technical terms but also subject matter terms. Ms Yashchuk reminds us that people are typically passionate about what they do. It’s important to recognize that and ask lots of questions. It works better for both project managers, if they can leverage each other’s strengths, but also work together to minimize their weaknesses. Ultimately, they both should be on the same team, with the same goal of delivering a successful project.
  2. Revert to the basics – At its most core, delivering a successful project comes down to relationships and removing obstacles. Leading People When They Know More than You Do by Wanda Wallace and David Creelman describe these as critical components for managing teams when you end up in unfamiliar territory. Software integration projects rely on both an implementation team with internal or external the service provider, but also guidance and engagement from the customer. If your non-technical, its even more important to appreciate the entire team and recognize that you are dependent on them for successful delivery. Further, each project manager should be constantly surveying the situation to identify obstacles that will derail the project.
  3. Get out of your way – The most important thing to realize as a non-technical project manager, or even as a technical one delving into something new, is when you are in over your head. It’s worth repeating that the success of a project is dependent on everyone involved. It’s important that you do everything you can to follow along (i.e. reading the contract in detail, following up with questions to make sure you understand each component, getting the details on what needs to happen from the team, etc), but not so much that you end up hindering the team.

Each project is different, primarily as a result of different people, context, etc. Embrace it, learn from it and contribute to its success!

Do you need to be a system expert to successfully implement it?

by

mythical_unicornI have often been asked to step into projects where the industry or software are unfamiliar to me. More times than not, the project team has been hesitant at first. A common sentiment towards project managers of many technical resources I’ve encountered is disdain. After a while, the team gets used to working with me and figures out how I can help. In many cases, I’ve changed the opinions of project managers for these technical resources. But why is that? What is it about my approach to managing data and software implementation projects that enables me to step into any project at almost any stage and help deliver results?

  • Willingness to learn – I am willing to learn. I know when to shut up & listen, take notes and ask later. I try to read the materials I’m provided, and if relevant, find external sources. I follow up with questions and try to make connections but acknowledging that I could have missed something.
  • General understanding of technology – I have a fairly good understanding of software development, database, data, workflow, process methodologies that gives me a foundation of understanding.
  • Resources – I’ve been lucky enough to have worked or socialized with a number of very smart people across a broad range of disciplines. I’m able to engage with my network on an as needed basis.
  • Know what you don’t know – It is imperative that I admit when I don’t know something. I need to engage with the right people at the right time, but yet recognize the dynamics of the situation and adapt accordingly.

I don’t think you do need to be a system expert to successfully manage an implementation project. I think you can develop enough of what you need to know to get involved to the extent you can. You’ll obviously need to adjust your level of engagement, and rely on your project team for the software expertise. You also need to know enough about the project and system to call bullshit when you need to.

Separating sales from reality

by

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!

by

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

by

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

by

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

by

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

by

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