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.



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 would 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.


3 factors that contribute to products not delivering business value

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.


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.

The alignment of my project methodology to the lean process

I’ve written before on the implementation methodology that I tend to follow when managing my integration projects. If you missed it, you can see it here. I’m taking a lean six sigma course from Simplilearn and was pleasantly surprised by how well our methodology aligned to the lean process.

lean-six-sigma-process-flowStep 1: Critical to both processes is identify the value. Why is the customer engaging in
the in this activity? what are they trying to accomplish? how is it measured?

Step 2: In six sigma, the next step is to map the value stream. This step is about getting to the goals & requirements. In our integration methodology, this encompasses steps 2 through 8 and is the core of the nitty gritty details. Since most of my projects relate to data integration, I need to know:

  • where’s the data coming from?
  • what’s the source of record?
  • who owns it?
  • what’s the data format(s)?
  • how is the data accessed?
  • how does the data need to be transformed?
  • what’s the frequency of exchange?
  • what’s the trigger?
  • are there software requirements or limitations?
  • have yo closed the loop? do you need to?

Step 3: The process of defining and discovering the requirements and goals leads naturally into the development of whatever flow(s) you need. This is true from a data, development and dependencies perspective. This process also helps identify gaps, complexities, inefficiencies and bottlenecks.

Step 4: In lean, like in data integration projects, you must discuss and determine push versus pull. Lean is seeking out the most efficient solution, generating the least amount of waste. While that is the ideal in data integration projects as well, you’re often at the whim of the technology, or other decisions.

Step 5: Seek perfection in all things! In lean, this means developing a system without waste. In my data integration projects, this means developing the process that will deliver the cleanest, simplest, consistent, and reliable system. And for that you need to be vigilant in your measurement, and you can’t forget or forgo testing and validation. This is not a one-time endeavor. With data (and more and more processes (if not all) are driven by data these days), things can change. The importance of closed feedback loops, regular use and validation, the process and data become stale.

As the project manager for data integration projects, I believe that that we should all be looking for ways to simplify and streamline what we are doing to reduce errors and ultimately become more efficient. As we all know, there is a lot we can not control in project management (and in life). We need to be constantly re-evaluating our state and making incremental improvements. This is the core to both lean six sigma and my integration methodology.

For more information and case studies on lean six sigma, check out this “Learn Lean Six Sigma Part 1” article by Mohamed Elgendy.



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 to 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)?

The value of user engagement

On-boarding customers to enterprise software can be a fairly long & daunting process. There’s usually a standard implementation process including setup, configuration, validation & training. The implied follow up to this occurs when the trained users start actively engaging with the software and embedding it into their business processes. Without this adoption and engagement, there’s a risk of undervaluing the investment.

http://mattshore.co.uk/wp-content/uploads/2015/09/value.jpgEngagement is not passively granted, but rather actively earned. As part of the project implementation, there needs to be special consideration given to figuring out how to keep users involved & engaged. Here are 3 options for continuing the conversation with the user community:

  1. Develop subject matter experts within each crucial team – Working closely with a few key team members to develop their natural curiosity around your software and empowering them as experts can turn them into subject matter experts and advocates throughout the entire organization. Some ways you can do that is collaborating on a few critical business processes to meet a specific business goal. You should result in showing those users the possibility and delivering them a “aha” moment for them to share with others.
  2. Create opportunities for sharing – This applies to within the organization and with the vendor-organization relationship. Leverage the expertise from your vendor/implementation partner to identify best practices that can be applied to your business. Within the organization, it is rarely enough to wait for serendipitous moments to miraculously occur. Everyone is working towards their own goals, often on their own isolated path. Creating “train the trainer”, subject matter expert question time, or brown bag lunch show & tell opportunities can bridge the gap.
  3. Know your path to success – Hopefully, you defined your project success before the implementation. It usually isn’t instantaneous in nature, making it even more critical that you define your path to success as well. Understand where you started from, and develop a plan for moving towards that success. Measure your progress regularly and adjust the plan as needed. You may find that you’re starting point is different than you thought or it will take longer to fulfill your end goal.

User engagement post software implementation is instrumental in the success of your project. Don’t underestimate the importance or complexity of this step.


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.


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.