Monthly Archives: April 2017

The alignment of my project methodology to the lean process

by

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?

by

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.

3 differences between Customer Success and Project Managers

by

I had a recent conversation where I was challenged in my use of the term “Project Manager” to describe myself versus “Customer Success Manager”, the prevalent description for people doing similar work in their SAAS organization. This week’s blog post will explore the key differences.

I’ll first begin by providing some basic definitions.

Customer Success Managers (CSM) – According to Teresa Becker, CSMs provide “a proactive, real-time sales approach consisting of building relationships with existing customers, understanding in depth their company and product goals, and helping the customer meet those goals through day to day contact. Each customer has different needs and uses for your product, so it’s up to the Customer Success Manager (CSM) to thoroughly understand each customer and to be their champion throughout their entire customer journey. The role of the CSM is a value-add and is usually not a fee-based service.”

zombie-customer-success

Implementation Project Managers (PM) – Webopedia defines an Implementation Manager as “an IT project manager who focuses on implementing information systems into a business environment. The implementation manager oversees the task, ensuring the project adheres to budget and time frame guidelines.”

From my perspective, there are 3 core differences in the two roles:

  • Longevity  – Implementation PMs are generally involved on a short-term basis for the duration of the project, while CSMs are closely tied to the customer for the length of the customer engagement (or pending other customer alignment decisions).
  • Technical Skills – The technical skills required to do a complex integration or implementation are higher than those required to maintain the customer relationship. CSMs do need to understand the product, the implementation and how to apply the product towards achieving customer goals. However, the depth and breadth of technical skills needed to navigate the implementation process is usually much broader in scope.
  • Project Management Skills – Typically CSMs take on basic project management tasks in the process of deriving & delivering value to the customer. Implementation PMs are often required to dive into the more advanced project management tasks (detailed requirements analysis, project plan definitions, risk assessments, etc).

As companies continue to evolve, we’ll continue to see blurred lines between roles,  responsibilities and titles. Both of the roles will continue to exist, but what you call them really is dependent on the organization, the product and the implementation lifecycle.