Tag Archives: project management

Whose side am I on?

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

Do your project managers focus on process or delivery?

by

I’ve struggled in the past with using the term “project manager” to describe what I do. It almost immediately triggers the question of whether I am PMP certified, and focuses less on my experience delivering projects. Additionally, I think there are quite a few employment roles today that include some project management responsibility. Doing basic project management tasks like scheduling meetings, doing status reports and checking the schedule does not automatically mean that you are able to deliver a project to its completion.

images

Rudy Gottschalk wrote a two-part series on shifting from “project management” to “delivery management.” He challenged all of us to look for a different approach, shifting the focus from project artifacts to project delivery.

“Too often project managers follow the rigors of a project management structure, but seem to have no sense of urgency in delivery or at times feel helpless to take control of the project delivery schedule.  They dutifully note progress, document issues and risks, and send minutes with the next meeting invitation. Since these activities fulfill the checklist of project management deliverables required by the organization, they usually give the illusion of progress, although little progress is actually occurring.”

I see this all too often in organizations. One manifestation is very large organizations, where a Project Manager from the PMO (project management office) AND a IT PM (AKA business analyst or delivery manager) get assigned to a project. In this scenario, both resources are expected to coordinate meetings, document decisions and communicate to stakeholders. The real distinction comes in their focus. The project manager tends to focus on following best practices and making sure every box is checked. Often, they are super cautious and tend to be more worried about creating the timelines, rather than the fluidity of project delivery. The delivery manager is primarily responsible for moving the project forward – removing obstacles, managing work assignments and facilitating ownership, driving towards a finish line. By not looking towards the endpoint, you sometimes end up in situations where there are incomplete lists of activities identified for project completion, incorrect timelines or lack of ownership and accountability.

Another manifestation of this problem can be seen in those roles with project management responsibilities. Often times, the immediacy of support tickets, status calls, status reports and the mechanics of the project “workflow” take precedence over delivering towards the end goal. Unfortunately, this can result in delays in getting to the value proposition. Ultimately, it also minimizes the importance of the critical analysis and seeing the overall picture.

If it is not obvious, I strong believe that project managers or those with any project management responsibilities need to be focused on delivery. This means focus on whatever the end result is, be it business value or a specific ROI. Without that target, it is easy to get lost in the logistics and workflow of managing a project, while not actually driving it towards a completion.

A Framework & Critical Decisions for Implementing a Data Integration Project

by

I have managed quite a few data integration projects. These are projects defined by the development of software and business projects that help organizations move data between systems and better understand the data they have. While each one is different in data sources, and project owners, overall my approach remains the same. I adapt the tools, timelines, and specific tasks depending on the organization and systems involved. Today, I’m reviewing the framework and critical decisions I rely on.

At it’s most basic level, data implementation projects have 4 core phases: Discovery & Requirements, Consensus/Sign Off, Development & Handoff.

  1. Discovery & Requirements – This first phase is most critical. It is at this point that you truly determine all that you need to know to design a solution.
    1. What business problem are you trying to solve? This lays the groundwork for everything else. Without knowing this information, it would be difficult to solve the right problem, or determine the right metrics by which to measure your success.
    2. Where is the data to solve the business problem? Now that you know what problem you are trying to solve, you need to understand where the data resides. This might be 1 source system or integrating 5 source systems. Are the systems internal or external to the organization? Does it only reside in someone’s head? Make sure to document the owners, stakeholders & gatekeepers. Your design could vary significantly based on what you find.
    3. What is the data format? This information and subsequent conversation should drive additional requirements around software, security, encryption and data transformations (AKA business rules).
    4. How is the data accessed? This should actually help you answer how should the data be accessed. Choose the best tool for the job based on the requirements documented in the prior conversations.
    5. What needs to happen to the data? Sometimes a project is as simple as making data sourced from one system available in part, or in entirety to another system. Often times, it doesn’t align exactly and business rules must be applied before it can be leveraged by other systems.
    6. How often is the data needed? And what triggers the transfer? Does one system push the data? Does the other system pull it? Is this an infrequent process? Or something needed real-time? or is there a triggering event?
    7. Which software is best? It’s finally time to start thinking about the tools, languages, & frameworks, etc. Also, make sure to include where the code resides & how security policies impact integration.
    8. How does feedback work? At a minimum, you need to consider how errors & exceptions are handled. In more complex implementations, data will flow both ways.
  2. Consensus/Sign Off – Document everything you learned and decided in the Discovery & Requirements phase. Everything from the high level problem to the detailed technical decisions that were made. Please, please get sign off from all the relevant stakeholders.
  3. Development – Development & validation go hand in hand.
    1. How will your results be measured? Write your test plans before you begin development. These are based on all the decisions & requirements documented in phase 1. You also want to do periodic data quality checks with the business stakeholders throughout the development process. There are ALWAYS things you find while engaging the business stakeholders, using real data, that you would not find on your own.
  4. Handoff – This is not simply a matter of flipping a switch and transferring ownership. This phase includes documentation, knowledge transfer during transition of ownership, and end-user training (if applicable). If not already, make sure the project artifacts are complete, compiled and made available to the organization. Often times, data integration projects require a period of hypercare where developers work closely with support people, and both the project implementation team and the support team work closely with the end-users, to make sure there are no gaps in knowledge.

Ultimately, the goal of data integration projects is information. There is some set of data in one system that could be made more useful or help derive better insights if connected with data from other systems.

Let me know if you think I’m missing any critical decisions in the process.

A infographic of this methodology is available in the case studies section of the Digital Ambit site.

5 Ways Managing Projects is like Creating the Family Meal Plan

by

I am a very food focused individual. I am a pretty good cook and I love to eat. In order to facilitate our weekly family meals, I do a large grocery shopping trip to stock the freezer and pantry with staples. I also visit the grocery store several times a week, if not every day, to pick up any additional items I need once I have been inspired to cook specific things. While I was dwelling on what we had already eaten this week, and what we had already in the fridge, freezer and pantry, I had the thought that this planning was really no different than the project management I do on a daily basis.

http://worldartsme.com/images/balanced-plate-clipart-1.jpg

I’m blending interests to and telling you about the five characteristics I look to create in both.

  1. Inventory – Before you go grocery shopping, you need to determine what ingredients you need. When you first get involved with a project, you need to do an inventory as well. In this case, the inventory allows you to assess what you have and what you need in order to make the project successful. At a minimum, your project inventory should include answering the following questions:
    1. What is the business goal?
    2. What product or solution was sold to the customer?
    3. Does an existing solution meet the need?
    4. What was the committed timeframe?
    5. Who is on the project team?
    6. What tools do you have? need?
    7. What is the budget?
    8. What are the risks?
    9. What are the success criteria?
  2. Variety – I believe in variety in food. This week alone we’ve eaten meals inspired by Italy, Latin America and the United States. In the project context, variety comes most often in the form of the project team. Ideally, my project team is very well rounded. It should include customer stakeholders who understand the business, as well as customer stakeholders than have the technical expertise to help validate and work through technical issues. Additionally, my project implementation team has a variety of skills, whether it be backend and fronted developers, or a data integration/developer and analytics resource. It also helps to have someone to bridge the gap between the technical solutions we are implementing and the customer’s business. Hopefully this me, but sometimes I have to leverage the subject matter experts.
  3. Balance – I’m a bit of stickler for offering a balance dinner plate. I try to always have at least one protein, starch and vegetable option at dinner. Sometimes, I succeed in getting more, and others it doesn’t happen at all. It’s important to create balance in your projects. Most often this refers to the balance established between the budget, scope and schedule. It’s the job of the project manager to set expectations and deliver a solution that meets the business goals.
  4. Budget – This one is probably the most obvious. It is a really good idea both in meal planning and in project management to know your budget. Sometimes, it’s small so you have take shortcuts and make different choices than you would if your budget was large. In the end, it really doesn’t matter what the number is. You need to make sure you know what it is, and drive the conversation around making the choices needed to stay within it (or increase it if you are so lucky.)
  5. Value – It makes me happy when my family and friends enjoy the meals I cook. Every new recipe gets evaluated based on a simple scale of 1) do again, 2) never do again or 3) make some changes and we’ll try it again, but reserve the right to scratch it off the list. A project must have a mechanism for determining completion and value. If there is no defined finish, you risk the never-ending project. And if the project never ends, how do you know if it has created value for the customer. Make sure you have established the success criteria you need to delivery the value you promised.

I hope you enjoyed my blending of my interests. It’s time now to go manage some client projects before heading into the kitchen to cook dinner.

Walking a fine a line

by

ayn-rand-quoteI write a fair amount about communication being critical in effective project management, but it is equally (if not more) important to be credible and confident. Being credible and confident allows you to more easily deliver hard news while still retaining the trust from the project stakeholders.

Given my track record of execution, I will often be brought into projects to implement a software solution but then hand off to a long-term customer relationship manager (or whatever you choose to call that role). Often times these long-term customer managers are not as technical as I am. As a result, it is much more difficult to be credible and confident in communication. I’ve been in numerous conversations where the less technical customer manager delivers information to the customer and it is not received well. Some of this occurs because the customer starts asking questions and the customer manager doesn’t have the knowledge, skill or confidence to answer. When I step in and deliver the same message or information, the customer reaction is much more amenable. This occurs because the customer trusts what I say (credibility) and believes that I have the knowledge and expertise to know what I’m talking about (confidence).

Credibility and confidence become even more important if you are pushing back on the customer. Without the effective delivery that credibility and confidence allows you, push back or hard news can be very difficult for a customer to absorb. The end result tends to be a battle of wills that takes you further from a resolution.

An example of this might be when the customer is reporting a series of issues, and voices concern about the overall adoption and effectiveness of the implementation. In reviewing the issues, you find that several of them are training issues that had been covered during the formal training sessions, but seemed to have been forgotten now.

  • One method of communication might be to address each issue separately, answering the symptoms but not the broader issues.
  • Another method is to clearly state that the issue is a training issue and users need to be reminded of x, y and z.

I do lean towards a very direct form of communication, that isn’t everyone’s preference, but it does lead to customers who truly trust me and believe that I’m working on their behalf. In the scenario above, I am more likely to tell the client that we need some refresher trainings since some of the critical basics seem to have been forgotten. Ultimately though I have built the relationship so that this is taken for what it is…a direct approach to delivering based on all my experience. If I fail to establish this relationship and still choose the very direct communication method, I risk alienating the customer.

Communication and relationships are complicated in managing projects. I find that project managers need to walk fine line between being direct and navigating the personalities, needs, and desired outcomes of the project. Establishing the credibility and confidence for whatever system or software your delivering will make your customer interactions easier and will smooth away some of the inherent caution associated with new projects, vendors, systems, etc. 

No one way…balancing “being different” with best practices

by

At some point while managing every project, I end up having a conversation with the customer about how different they are from their competitors. Each organization can list a dozen reasons about why and how they are different. This is often used as an excuse for why something can’t or shouldn’t be done a certain way. The reality of it is that organizations within the same industry are more alike than they are different. Yes, there are nuances and competitive advantages that allows them all to exist in the industry, but core business challenges and opportunities are similiar.

I recently had a couple of conversations that were the epitome of this situation. On one hand, we were talking about extensive, semi-permanent changes that were required in order for the system to be “fully accepted and utilized by the stakeholders.” I approached these conversations from the standpoint of acknowledging we would probably move ahead with doing the changes but wanted to ensure that those making the decision understood what purposes those elements served and what potential opportunities were being lost by moving forward. Inevitably, we got to the end of the conversations and I was asked how other organizations had handled this same problem. In all cases, I had to explain that the majority of our customers took the exact opposite approach.

The large-scale data integration projects I manage come with a significant amount of organizational change required to make them truly successful. As a result, the project manager sits at the heart of the internal conflict of the organization between “the way it has always been done” and “industry best practices and opportunity for the future.” The role of the project manager is to educate and recommend, but ultimately, execute. Sometimes that means implementing in the best way for the organization with the understanding that as the system becomes embedded in organizational culture, some of the initial implementation will need to be unraveled.

 

Rewarding Ingenuity Part 2

by

Back in March 2014, I wrote this post raising the question of whether we should reward ingenuity or punish bad behavior. We recently had another incident with the same daughter that had us thinking about this question again. This time, our daughter had her electronics taken away for bad behavior, specifically being rude and disrespectful. We had given her a specific timeframe for which she would have to suffer these indignities. After the first day or two, we found her watching Netflix on the family television in the basement. When we questioned her about it, she quickly pointed out that we had “taken her electronics”, but made no mention of her interaction with other electronics.

In a broader context, we often look at these types of situations and argue the gray line. We say that the offender “should have known better” or “should have known what I meant.” I think we walk a very difficult line with this argument, especially given the diversity of our workforces. Every day we interact with people who have had very different personal, work, education, etc. experiences from ourselves. There is a real possibility that they understand something differently (not necessarily better or worse).

Software projects are infamous for being over budget and delayed with the resulting solution not ever meeting the business objectives. In the traditional waterfall approach to software development, requirements are gathered upfront, and then interpreted by developers during implementation with a final delivery of a solution that hopefully meets the  customer goals. Agile methodologies address this by taking a very iterative approach to development, where constant feedback is given. This allows all stakeholders to see the execution (AKA interpretation) of the requirement and determine whether it meets the business objective.

As a project manager, I have to balance between breaking everything down to the simplest form as a means to eliminate misinterpretation and being vague enough to solicit questions, ideas and foster serendipitous moments. A team member that does only what is asked of them is good, but the team member that analyzes and challenges for the greater good of the project can be a rockstar.

In the end, is this really any different than my daughter interpreting her punishment differently?  On one hand, you want them to do their chores and listen to their parents, but on the other you want them to grow up to be critical thinkers and challenge the status quo to make the world better. This is a very hard lesson when you are 13. I’m not sure whether it gets easier to understand as we get older.

P.S. Just to close out the story, we allowed our daughter to use the family TV to watch Netflix because she very delivered her very logical explanation in a calm and peaceful manner.

Kids, Project Management & the Serenity Prayer

by
Serenity-Prayer

Source: https://www.goodnightjournal.com/wp-content/uploads/2014/02/serenity-prayer005.jpg

I’m not religious by any stretch of the imagination, but I do believe in the Serenity Prayer. It’s something I have to remind myself of often as I interact with both my kids and my projects. It provides a level of grounding. What’s the point of getting frustrated if it’s outside my control?

The nature of my personality requires that I be hands on. I want to be involved. I want to help control the outcome. But the nature of many of my projects results in things outside my control. These projects are big and complex integration projects that involve technical resources both within my organization and often within the client; and business users. Often the decision to move forward with this implementation was handled by resources higher up the corporate food chain. This means there are questions, considerations and discovery that need to take place at the beginning. The inner workings of corporate culture and the organizational power hierarchy become evident here. It is usually at this time when a decision is made that is totally outside your control, but has major impact on the project. It may be a decision to user an external intermediary for some piece, or the implementation of a business process that impacts overall timelines.

My initial inclination is to get frustrated. It’s that overwhelming feeling of wondering how you are going to accomplish what you set out to do if you don’t control all the pieces. After a little while, I remind myself that I can’t worry about things outside of my control. These are things that I can’t change. So what can I do?

  • Accept the things I can not change – Most importantly, I can recognize and remind myself that there a components of the project that I do not control, and can not change. This allows me to keep my sanity during the project implementation.
  • Establish Trust – I can establish trust with whomever is involved in the project and do my best to work together towards the overall success of the project.
  • Communicate  – I can engage fully with the entire project team and make sure everyone knows the status. There is some trial and error that needs to happen to determine the appropriate level of communication.
  • Raise Concerns & Questions – I can monitor the project situation and raise concerns & questions to the appropriate team members.
  • Focus on what I can control – It’s my job to be looking at the entire picture. What can I contribute? What ideas or actions can I bring to the table to facilitate project implementation success?

This approach is one I need to do a better job of also applying to my children. In some ways it easier to apply this to a project and people you are professionally affiliated with rather than your kids. I think the principles are the same. Yes, your kids belong to you. However, they have their own personalities and natural characteristics which combine with their unique nurtured experiences that we need to consider. I need to keep reminding myself of this as I work to establish & maintain trust, openly communicate, raise concerns & questions and focus on what I can control while encouraging them to do the same.

Balancing Agility with Process is Really Hard!

by

Most of my professional experience has been in small, fast-paced organizations. I had one fairly short stint in a larger public company. During all these experiences, I’ve seen the constant struggle between agility and process. There are numerous studies that prove that companies need to react very quickly in today’s market in order to be competitive. Unfortunately, growth companies tend to pursue agility with pure disregard for process. McKinsey has done a few studies on this, here and here, that speak to the importance of agility but argue that the only way to achieve true agility is to have a strong backbone of structure and governance.

In my experience, the balance between agility and process (AKA structure) is very difficult to attain. When you are a company of 1 or 2, you do what works best for you. Hopefully there is some basic process around prioritization and execution, otherwise there might be a real struggle for viability. As you add additional resources it becomes more important to add some process. Resources need to understand the organization purpose (mission, vision, key performance indicators, etc) or everyone will be doing something different, making the whole very unstable.

Strong sales & organization leaders can overcome this, but they often do it at the expense of their own sanity. If a core group of people exert all their energy in developing sales and onboarding customers, they can compensate for the resources that are adding limited value. It’s at this point in the growth model where organizations struggle. It becomes apparent that some resources are severely underutilized while others are severely over-utilized. The focus of the conversation swings between the expense of training the under utilized resources or releasing the under utilized resources from the organization. In both these cases, the root cause has more to do with the process of onboarding resources. Does the organization invest the time to train the resources they have already or spend the time to find & train new resources? That depends on the resources and how they align to the organization. Some resources will be redeemable, while others are not.

Alternatively, there are many organizations that are so process oriented that they lose sight of agility. The focus becomes on making sure the process is followed, and the appropriate approvals are obtained. This is done at the expense of moving quickly.

Scale comes with being able to consistently deliver your product offering to your customers and add value in your area of expertise. If you have not designed a process around delivery or fully understand your product offering from your customer’s perspective (specifically how they derive value from your offering), you are likely to spend a significant portion of your time in fire fighting mode. Consequently, spending all your time fire fighting results in less time spent helping customers with the value initiatives.

I believe that there should be a balance between agility and process. Define a core set of processes that are critical to your product offering, set the groundwork for resources about why the organization exists (back to mission, vision & goals), but give them the space to make decisions and pivot as required.

 

 

3 Tips to Make Your Project Transitions Occur Smoothly

by

At some point during the course of a project, a transition must occur. Ideally this doesn’t occur until the end of the project when you are transitioning from the implementation phase to the support phase. Unfortunately there are times when transitions need to occur during the implementation phase. Regardless of the scenario, I have found that there are a few things the Project Manager/Organization can do to make this transition go more smoothly.

  1. Establish a process for project artifacts (specific documents and central storage) – While each project may have slight variances to a set process, the more aligned the project documentation is, the easier it will be for a new team member to come up to speed. At a minimum I think this should include standard templates for project status including decisions, action items, upcoming goals and most immediately resolved items; project plans; statement of work & change orders; and support documentation that provides the technical details as well as business rules that impact the implementation (what will the support team need to know to manage the day to day operations of the implementation?).  The central repository for project documentation makes it easy for anyone to step in. They know exactly what has been transmitted and can see the progression of the project over time. Without these, time is wasted on finding the components rather than really digging in figuring out the state.
  2. Establish a process for team hand off – Once the new team has had a chance to review the project artifacts, it is important to bring all technical resources together. When you work on a long term project and try to document all the nuts and bolts of what you did to implement, sometimes there are intuitive pieces you fail to document. These are components that are so obvious to you that they have become insignificant. However, new resources won’t know and won’t necessarily know to ask, unless they have faced that situation before. In the process of talking through the implementation to educate the new team, these details surface and can be captured.
  3. Communicate! – The need to communicate only becomes larger during times of transition. The project manager needs to be fully engaged with all team members and stakeholders. Being open and honest about the transition state yields a bit of flexibility among the project team and stakeholders. Make sure to leverage this time to ask the basic questions you don’t know the answer to you and level set expectations.

Project transitions are inevitable, but don’t have to be a horrible experience. Having the proper project documentation, a central project document repository, team hand-offs and very open communication will significantly reduce the risk and improve the success.