Tag Archives: project delivery

Mislaid project intentions

by

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?

by

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

A 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?

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

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. 

How do you Counter the “Hurry Up and Wait” Game?

by

You can get so confused

that you start in to race

down long wiggled roads at a break-necking pace

and grind on for miles across weirdish wild space,

headed, I fear toward a most useless place.

The Waiting Place…

-Dr. Seuss “Oh, the Places You’ll Go“

As a project manager who works on complex implementation projects, I find that I spend a lot of time waiting…

  • waiting for developers to finish their work
  • waiting for approval or feedback
  • waiting for resource availability
  • etc

It isn’t the inherent waiting associated with regular project management that’s frustrating, it’s the “hurry up and wait” syndrome that bogs me down.  These are scenarios where you have completed some component of work, are have been waiting for some time for feedback. When the feedback is finally provided, the expectation is that you will turn around a response or resolution immediately. If not managed correctly, this becomes an ugly cycle.

I have to remind myself that this isn’t happening to make my life difficult. There are underlying motivations that I don’t necessarily understand. Ron Ashkenas’s 2014 article in the Harvard Business Review “Two Ways to Reduce “Hurry Up and Wait” Syndrome” suggests that this is a byproduct of the “dramatic acceleration of today’s business culture.” Mr. Ashkenas provides two suggestions for how to minimize the impact by 1) putting a premium on removing low value work so there is more bandwidth for handling urgent issues and 2) do a better job prioritizing new requests as they come in, specifically making decisions on urgency.

I’m a huge supporter of both of these suggestions, but I think the minimize the partnership aspect of working with clients. As a value added partner you should remember these 3 things when faced with the “hurry up and wait” syndrome:

  1. You don’t know what the other person is going through – Yes, you are feeling the stress of the other person’s action, but who knows what they are going through. Maybe this is worse for them.
  2. It is critical you communicate – You need to be able to have a conversation. Tell your customer when you are going to deliver (within reason of course) and deliver. This may not be the requested tomorrow or noon today deadline, but people will generally be reasonable if you set and meet expectations.
  3. Don’t let yourself fall into the “hurry up and wait” syndrome – If you aren’t careful you can find yourself in a situation where you are constantly fighting fires and always reacting to situations. You need to be able to look at all you have to do, across all clients and make legitimate decisions about priority and urgency. By introducing process, you can bring peace to the chaos. It’s this step of building system and process that will allow you to grow and develop smarter as an organization.

 

 

 

 

 

 

 

 

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.

Striving for perfection in project implementations

by

One of Merriam-Webster definitions for perfection is “something that cannot be improved.” For me, project management, software development and data analytics are always evolving. Every new project I take on is balanced on the learnings of all the prior projects I managed. This is true for software projects, and is true in data analytics. For every  question I answer, I can think of several more that I’d like to tackle.

the Idea of perfection is so imperfect.

Source: http://www.thefeelgoodlifestyle.com/wp-content/uploads/2013/04/Perfection-is-imperfect.jpg

Nevertheless, it is not uncommon for project stakeholders to say that you can’t roll something out, or even go into a pilot phase until everything is perfect. It is at these times, that project managers need to take a step back and analyze the project from the people and motivations perspective. The project stakeholders are saying that they are uncomfortable with where the project is and are not willing to put themselves on the line just yet.

How did you get here? 

This problem generally arises when expectations are not aligned. If each side hasn’t clearly documented and shared what they were working towards, there is no guarantee of all sides working towards the same end goal. It is not enough to have documented requirements, or use cases. You also need to agree on the measurement or evaluation criteria.

How then do you move forward? 

  • First, both sides need to communicate.
  • Second, both sides need to jointly agree on a core set of success criteria for each milestone and phase.
  • Third, both sides need to remind themselves that everyone is working towards the same goal.

There will always be requirements that continue to evolve for every software or data integration project. It is making sure the project implementation team is working towards the same success criteria at the same time as the project stakeholders.

 

4 Considerations When Choosing Project Management Tools

by

Project Managers tend to be very opinionated on the “right” PM tools to use. This discussion, and interview question has always frustrated me. I strongly believe that it doesn’t matter what tool you as the Project Manager prefers, you should be able to adapt to whatever tools work best for the organization and your customer. If you Google “recommended project management tools” or “the best project management tools” you can between 34 million and 125 million results. In my experience, there are four key considerations I use for the basis of deciding which tools will work best.

Which-direction-Fotolia_50558549_XS-300x221KISS

Keep it Simple! The least common denominator is usually the best option. Tons of fancy features aren’t generally very helpful. Often times you pay for the luxury of having those available. Apply the 80/20 rule to your evaluation process – 80% of of your needs will be fulfilled by 20% of the features & functionality in most project management tools.

Audience

Who is your audience? The tools you leverage with your project team or for your own planning will probably be different than those you use with broader stakeholders. I have found that simple tools are often best. While I can develop a complex gantt chart, and will sometimes do so for my own planning, I find basic word-processing & spreadsheet applications are easier for less technical (or PM focused) audiences.

Proximity

Is your audience within or external to your organization or team? Often times you need to deliver project status and meeting notes to an audience with internal and external participants. These are more static update tools, rather than interactive. These tend to capture status, action items, changes, decisions, etc. This is the right tool for conveying priority or tasks to another team within your organization where you may share resources. Additionally, you will want to figure out how to make project artifacts easily accessible. This may be through an intranet for internal access only, or a collaborative/extranet solution.

If your audience is located in your same office, I would highly recommend using tools like white boarding and sticky notes to brainstorm and organize. Recent studies (here’s Inc’s write-up) have shown that leveraging less technical tools improves creativity and brain power.

Feasibility

This consideration encompasses cost and availability. Sometimes your decision is just made for you. If you are running your project budget or organization very lean, you’ll want to leverage open source or free software. Alternatively, if your organization has negotiated a software licensing deal that gives you access to specific tools, it may make the most sense just to use what’s available.

At the end of the day, don’t overthink your tool selection. Decide what your critical goals are, and find the tools that meet them. There are significant advances in project management tools that provide plenty of options. Not all of them are right for all projects, teams or organizations. Sometimes it best to get everyone in the room, using the most basic tools of all.

The Myth of the Project Plan

by

 

The Project Management Institute Project Management Book of Knowledge defines a “project plan as a formal, approved document used to guide project execution and project control.” It further specifies that “it should be used to document approved scope, cost, and schedule baselines.” In my experience, a project plan is treated heavy on the “formal” and “approved” and light on the “baseline.” I think the process of approval gives the perception of longevity on the life of the plan. This minimizes the impact of the project plan as a baseline. Unfortunately this misunderstanding causes many complaints about project delays and delivery.

I was struck by this Computer Weekly quote when I conducted a google search for “project plan”: “[It] is one of the most misunderstood terms in project management. It is a set of living documents that can be expected to change over the life of the project.” This is polar opposite to how I have seen the project plan treated. The project plan is usually created at the beginning of the project, based on a statement of work, with fairly limited information. Even in cases where all stakeholders understand that the project scope is fluid, the project plan is expected at the beginning of the project and is used for making time-specific business decisions (training, user acceptance testing, etc).

Historically this has resulted in project managers padding their project plans with additional time so that the project is guaranteed to come in on time. Alternatively, the project plan isn’t padded, but issues of either scope creep, or scope reduction occur. In all cases, decisions are being made to meet a deadline, often selected artificially, which only aligns to the information available at the beginning of the project. There is no consideration to the fluidity of project implementation and information availability.

It would alleviate quite a few problems in project delivery & success if we chose to leverage the project plan as a living, breathing document. As time progresses, and additional details are obtained, the project plan should be updated. As a project team, we would be in a much better position to make decisions, and set more realistic deadlines as we get into the details and work through the development. Furthermore, sharing regular status and having constructive conversations about the state of a project and the next steps result in a more successful deployment.