Why is it important to put process first?

…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

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

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.

 

When are you done?

it-compiles-ship-itAs a paranoid project manager, I will conduct my own validation before communicating to customers. There have been too many times where I have not done this extra validation and sent it to the customer who immediately identified obvious issues. That doesn’t help anyone during a project implementation. And actually, it can cause serious credibility issues with the stakeholders.

For me, a task is done when I can demonstrate that the requirements are met or the issue is resolved. I’m not talking about the detailed nuances that are found the stakeholder does their deep dive into the solution. I’m also not talking about the scenarios where we have set the foundation early on that the validation would be collaborative in nature. However, I’m finding that the ability to follow through and conduct basic validation before communicating it’s done is a skill. And it’s one definitely not found in my teenage daughters and in many adults. I’ll walk through two quick examples, before I set some guidelines.

My husband pays my teenage daughter, Cayla, to do his laundry. Every week, I over-hear the same conversation. “Is my laundry done?” from Carson to Cayla. Once Cayla confirms, the follow up is either “so why don’t I have any socks (or whatever)?” or “then where is my basket (as it hasn’t been returned to our room)?” For the most part, Cayla has done the majority of the work, she just didn’t fully follow through. This could mean the laundry has been washed, folded and put away but the baskets not returned; or just washed and in a pile downstairs; or some other variation on an incomplete status.

In the workplace, I’ve seen lots of examples of this. A project team member will hand over what is supposed to be a complete deliverable, but I can’t get it to run, or it doesn’t meet the basic requirements. I’ve heard all sorts of excuses as justification throughout the years: “it’s done but not complete”; “it compiled so I thought it would work”, “I installed it but didn’t configure it”, “I finished one piece of it”, “it works if you do x, y and z  (even if that’s not the logical use)”

So, when are you done? I think there a few critical components that project team members should be consider before marking something as complete.

  • Available – The solution must be available in a form to distribute to the business user. Even if it’s something you are developing and installing on their behalf, there should be a tangible output to show for it.
  • Configured – Having a solution installed is often not enough. Is the solution configured as required to meet the customer needs? or in a state where the customer can configure it themselves?
  • Validated – Have you followed the steps the user would use to interact with the solution? Have you ensured the workflow makes sense, the solution does what it needs to and produces output that is as correct as you can determine (sometimes it is just doing a gut check on the output or making sure the user interface works for the inputs).

This is one of the most frustrating components of projects from a customer perspective. We all need to take ownership of the work we do and make sure we are doing some form of validation against the requirements and against basic usability. Does your solution do what the requirements define it should. I understand that not everyone has the business context, but own the functional requirements of whatever you’re developing.

Resetting project expectations isn’t a bad thing

dream-catcherThe project I’m working on is perfect. I have the all the money, resources and time I need to be successful. The stakeholders are really engaged, the success criteria is clear and we are moving along on the project timeline exactly as we originally defined it.

Yes, that was a lovely dream. Unfortunately, we all know that most projects don’t go like this. I was working on a project that should have been a quick implementation, but immediately after the kickoff it became apparent that the scope defined in the sales process didn’t align to the requirements of business stakeholders. This made for some interesting project discussions. A couple of weeks in, just as the project was on the brink of derailing, we were able to have a very honest discussion and reset the project expectations.

This was a necessary step in making this project successful. There was definitely a miss in the early scoping process, but as a result of the communication among the business stakeholders and the project team, these issues were identified early. It also helped that this was a case where we didn’t lose any time working on unnecessary components. All the work that had been done before the project reset was still a valuable contribution to the project. Too often, project teams are hesitant to have these very honest conversations. Instead, time is wasted dancing around the problem, or implementing solutions that don’t meet customer needs.

To enable recovery from a project that is going awry, you need

  • Business stakeholders who are involved and advocate for their needs from the beginning
  • Project manager and leadership that is open & honest about the existing scope
  • An entire project team who (project implementation team, decision makers, business stakeholders) want the project to be successful and are willing to re-evaluate and reset the project scope and timelines accordingly.

 

The impact of sales context on project management

domino-effectData or software projects are usually purchased in one of two ways: as a part of a large, enterprise level deal that impacts multiple teams and has overarching corporate goals or as a stand alone purchase for a specific purpose for a specific team. This sales context can make for very interesting project management moments.

If we take the scenario where an organization makes an enterprise level implementation decision, you could have some additional levels of complexity. For example:

  • The project team may have to “sell” the project to the individual teams of users within the organization. The teams will likely have different levels of familiarity and maturity with the business process or solution.
  • Where there are varying levels of maturity, you have to be careful to effectively set expectations and cater differently to teams based on their desired engagement.

In another scenario, one part of the organization makes a purchasing decision with dependencies on other parts of the organization. This will often result is some interesting yet awkward project conversations. For example:

  • If you need to engage with another part of the organization to make the project be successful, it’s important to lay out all the facts and deciding factors. Too often project conversations must occur to relieve stakeholder concerns without those stakeholders having all the facts. Those seemingly minute details can totally shift the tone of conversations, making or breaking success.

And last, let’s consider the scenario where a specific team is looking at a solution. In this case, there can be additional considerations both in the sales process but in the project management as well. For example:

  • Does the team control the purse strings? Or are there other dependent groups or players? Make sure you fully understand the landscape of stakeholders & stakes.
  • Does the pain points being discussed align to what you do best? Just because you can sell your solution, doesn’t mean you should.
  • How does this sale fit into the overall goal of you both organizations? Is this a one-off purchase by a team without any broader organizational support? or are there opportunities for growth for both parties?

Project management in itself is a fairly straightforward undertaking. Your job as project manager is to deliver on the project goals. As the saying goes, “the devil is in the details.” You need to quickly assess the lay of the project land. Who are the key players involved in the project? Who are the key players not involved directly in the project? What are the potential pitfalls or landmines you need keep on your radar (not necessarily on your horizon as you should be working to mitigate these as much as possible)?

Mislaid project intentions

If you managed a few projects, you eventually come upon one with mislaid intentions of some sort. I’m specifically using that word because it comes bearing a sense of temporary-ness, and lacks a sense of malice. Both of which I think are what’s at play in these situations.

misplaced-meme

Sourced https://memegenerator.net/instance/66917865

What do I mean by “mislaid intentions?” For me it’s those situations where things just don’t seem to add up. The actions of the stakeholders or members of the project team don’t align to the published project goals. It might be the subtle (or not so subtle) withholding of information or the constant flux of sidebar conversations or even the lack of follow through.

So, what do you do? Do you put your tail between your legs and run away? Do you whine to the powers that be? I rarely shy away from a chance to show my scrappiness and use this as an opportunity to insert myself into the process. I’m not too concerned about what others think of me. My goal is to execute on a project so I need to use all the resources I have at my disposal and pursue those goals (sometimes quite aggressively, if that’s required).

But, what’s the point? To me this is actually the more interesting question. If we are all working towards the same goal of delivering on the project goals, what’s the point in mislaying intentions? This is where the organizational and personal dynamics come in. Usually the reason for this behavior has nothing to do with you at all. It usually has to do lack of knowledge or understanding (of your role, value, or even the mechanics of the project); or it could relate to broader project issues that originated before you arrives; or it could have to do with personal insecurities.

It’s really not necessary for you to spend too much time speculating on why this is occurring. Remember these are “mislaid” intentions with implications of benevolence and a lack of permanence. Your job is to figure out how introduce your role, and work you way into the dynamics of the project often changing it as you march towards your goal of execution. Don’t stop fighting the good fight.

 

Do Project Managers still deliver value in 2017?

“Between agile and automation, project management is going away. There may be jobs with that title but the work will be very different.” — Kevin Brennan

I saw the above quote today on Twitter. Just like a couple of weeks ago, I was totally taken aback. Agile and automation doesn’t take away what a really good project manager can do. These are methodologies and tools that a project manager can use to deliver projects better. When I asked my husband, a software engineer, what he thought of the quote, he suggested that maybe these would drive the non-technical project managers into extinction.

I guess it all really begs the question of what does or what should a good project manager do? I’ve been asked to help train someone on how I run implementation projects, so I guess I should start putting to paper the criteria around what I do and why it allows me to deliver on implementation projects. I will start by saying that all project managers are not equal. This is a big part of the reason that many technical resources are so critical of the PMO and project managers. They don’t see the value and often feel that the project manager just adds work to the technical resources.

Above anything else, a good project manager should remove obstacles from the team and the project. This might be resource alignment, or a dependency from another department, or almost anything. Status meetings, project documentation and stakeholder management are merely manifestations of this work. The catch here is that the project manager needs to be technical enough to fully understand the nature of technical issues, and work with resources on getting them what they need to resolve them.

Second, a good project manager has the analytics wherewithal to assist business and technical resources. On the business side, the project manager can help bridge that gap between that user story or business requirement to the details of how functionality works, to ultimately helping coordinate the validation efforts further offloading work from the technical project team. On the technical side, the project manager with strong analytic foundations can step in at any point from requirement interpretation to design to validation/QA.

natural curiosity can also differentiate a good project manager. The ability to ask questions and drill into the details yields a great project management dividends. It shows your stakeholders and project team that your interested in what they have to say, and is instrumental in the trust building required to successfully deliver. Very few projects run without hitches. The desire to ask why can broaden the range of solutions, ultimately resulting in a successful implementation despite the twists and turns.

A good project manager will balance tenacity with adaptation. Too much happens too quickly these days for project managers to stagnate within in a set methodology, toolset or process. We too often see project managers so set in their ways, unfortunately often following the PMI rulebook to its smallest minutia. The moment the project offsets the delicate balance (of the PM), the delivery becomes jeopardized. Come to the table with your preferred methodology and toolkit, but be willing to be flexible during the project implementation. Ultimately, the project manager will be more successful.

At the end of the day, I don’t think being a good project manager is really difficult. I think a shift in mindset and the ability to constantly learn can make you successful. I’ll continue to do what I do and deliver projects. In the meantime, I’ll leave you with this description of a project manager, sent to me by a former coworker. He hadn’t been a fan of project managers until he had the opportunity to work with me on a project. In addition to the several job referrals, he sends me funny project management memes.

pm-meme

 

Whose job is QA?

not-my-problem-meme

Tribute to Gene Wilder as Willy Wonka – it’s not my problem meme

developer.com defines the QA (quality assurance) role as “the role responsible for guaranteeing a level of quality for the end client. It’s about contributing to the quality of the final product.” I really like this definition as it does 3 critical things. First, it highlights the importance of the client. A product that works as designs, but doesn’t solve the customer problem fails to address the crux of software development, giving people an application they need or want. Second, it directly states that the QA role contributes to the quality of the final product. Just as developers contribute to the building of the product, and project managers contribute to getting the project done. Last, this definition removes the perception that QA is the responsibility of a single person. And this, my friends, is the topic of today’s post.

Our job as the project team is to build a solution that solves a customer problem or need. I agree that sometimes you are building a solution that customers don’t know they need yet, but unless that need or problem exists, there’s no point in building it. From the very beginning of development, we should all be working with this goal in mind. And if everyone is focused on the same goal, are we then inherently focused on QA? I think so.

My role as project manager puts me directly in front of the customer. This means that I need to be familiar with the solution, in order to speak intelligibly to customers. I tend to do the “final test” of replicating the steps provided by the customer and using the output as proof that the issue is resolved. Unfortunately, there have been too many times where I’m delivered a solution that doesn’t solve the problem or clearly doesn’t yield the “correct” results. Or, if I report a more general issue about performance, I get very tactical response, rather than considering the customer experience.

So what happens? Why does the solution I’m provided not solve the customer problem? Is it because the developer didn’t understand? didn’t care? More likely, it is the developer did some initial investigation and solved what they thought was the problem but didn’t walk through the steps to see it from the customer perspective and therefore missed a critical step.

I’m not advocating for or implying that I wouldn’t or shouldn’t still have the final sign off not the solution, before delivering it to the customer. I’m suggesting that each person who has touched the solution before getting to me should understand the problem we are trying to solve, and be focused on delivering a quality solution. Each developer should be incorporating regular quality checks into their own development. I never want to hear that “my team doesn’t have a QA person” or “it passed my acceptance test.” If the team members understand the goal, and view QA as a part of their job, the customer solution is bound to be better.

 

Whose side am I on?

http://www.kappit.com/img/122260/whooo-what-a-week-im-so-glad-its-tgif/

http://www.kappit.com/img/122260/whooo-what-a-week-im-so-glad-its-tgif/

This has been a tough week. Not only was it busy, it felt like I was spending a lot of time chasing my tail. Unfortunately, it wasn’t isolated to a single client or project. It seemed across the board, I struggled to keep a handle on what was going on. The one consistent point is that neither the client nor the internal project team felt “I was on there side.”

A project manager or customer success manager for technical products are usually smack in the middle between the demanding customer and the product or project team. So, why then did this week bother me so much? I think it was because I am seemingly able to do a better job balancing everyone’s interests. I’m using today’s post to try and figure out what happened and what I can do better next time.

  • Don’t take it personal – First, I really do need to remind myself not to take it personal. As I tell my kids, “I am only responsible for my own behavior.” On the side of the customer, I am the representative of the company. It is my job to hear their issues and feel their pain. Sometimes that escalates if resolutions aren’t found quickly enough for their liking. On the side of the company, it’s my job to be the advocate for the customer. As a company, we need to realize that it’s not personal. We are each doing our job.
  • It’s all about the communication – This leads me to the second critical point. Everybody needs to communicate. The adage “no news is good news” doesn’t apply in project management. No news usually means that nothing has been done. As the advocate for the customer, it’s my job to follow up and get resolutions. At a minimum, at least tell when I can expect a response. This gives me something to tell the customer.
  • We are all on the same team – Lastly, we all need to realize we are on the same team. No matter how well a company “eats their own dog food”, the customers will always be the experts of the products. Just because they are using the system in a way that we didn’t anticipate doesn’t make what they are doing wrong. They are giving us feedback and making it better. Every time they uncover an issue or ask for something, they are driving us forward. Let’s embrace that. Let’s not assume that the customer is doing something wrong. The onus is on us to understand the use case and solve the customer problem.

I think this week’s lesson is pretty clear. I’m glad it’s friday as I need to regroup this weekend to tackle the open issues head on next week. Hopefully I will be able align everyone towards solving the problems. But as for the question I posed, we are all on the same team: product, services, and customers.