Once you’ve identified potential pain points with the team that have then been validated through data, you have an opportunity to drive change through process updates. Although developing a new process idea may feel like the final step at evolving the way your teams work, it is often just the beginning. Team members may be resistant to process change due to a fear of the unknown. Sure, they’re aware that the current process is inefficient and/or has risks, but they’re familiar with it. Driving change requires you to overcome this fear of the unfamiliar.

If team members understand why a process needs to evolve, rather than just how to do it, they will be more likely to sustain the new approach long-term. In the early phase of process adoption, introduce the idea to key stakeholders or crafts individually. Be mindful of factors that resonate with distinct stakeholders. Explain how process change will make their lives easier without adversely impacting their success metrics. Each craft or stakeholder will be uniquely affected by change and therefore you likely want to address process change distinctly with each craft. 

What are teams responsible and accountable for? Who do they communicate with when consulting and informing other stakeholders? How are differing project phases affected by process change? How are distinct project types affected? Be prepared to preliminarily discuss how a RACI may be affected by process change. Pragmatically present the realities of the process change so that teams precisely understand how their actions in day-to-day work will be affected. Once you’ve had a chance to walk through changes to stakeholder responsibilities, accountabilities, and communication, open up the meeting to listen to concerns.

Based on the complexity of the organisation, you may first want to engage craft leaders to align on high-level elements related to the process change. If you can’t get leadership buy-in, change won’t be happening. Be mindful that differing stakeholder tiers often have different factors that will resonate with them. Leaders are more likely to align with organisational business needs, while day-to-day team members may be more concerned with pain point changes for work activities. Be ready to discuss how business needs or project activities will be directly impacted by change based on the audience.

Process change may mitigate old risks or drive efficiency, but it will also create the opportunity for new risks. Bring all the key day-to-day stakeholders together to score risks based on severity of outcome and likelihood of risk actualization. Likely and severe risks that crafts uniformly agree on will require an adaptation of the process to mitigate future issues. Although project managers often wear many hats, you may need to rely on subject matter expert team members to adapt the technicalities of their process to the overall approach. Encourage stakeholders to think how they can mitigate their identified risks within their craft. It is essential to think through the nitty gritty element of change so that you don’t discover new risks in the middle of an active project. Reactive risk mitigation will never be as effective as a proactive approach. 

Process change involves balancing the realities of risk with the benefits of new ideas. If your core process change creates too many new and severe risks, you may need to re-visit the overall approach. Compare the risks and benefits associated with the new process versus those observed with the old process. Is it still worth it to move ahead with change? Don’t be afraid to pause the implementation of change or scrap a new process altogether. Over-committing to a bad process may create more problems than it solves. However, if a process change provides an overall benefit, let’s move ahead with execution.

For complex process change, you may want to create a pilot program plan to identify the unknown unknown risks associated with change so that the new approach is implemented only on a small or low risk project. Ensure that issue logs and risk registrars are routinely updated and monitored during periods of change so that any issues are quickly recognized and addressed. Process may not be perfect on the first attempt, but if mindful of the process deficiencies, it can be driven towards a more ideal state.  Create touch points with the team at each milestone to specifically discuss the benefits, risks, or realised problems associated with the updated process. Be prepared and willing to adapt accordingly. A lack of touch points may lead to teams abandoning the process change without your knowledge. Alternatively, failing to touch base with the team to listen to concerns may lead to lingering risks or problems. Teams will naturally gravitate back towards old processes that are more familiar, continued process touchpoints are needed to ensure that change is adopted and sustained in the long-term.

Budgetary Case Study
I’m sure many of us have heard the phrase “correlation does not equal causation”. However, causation can be incredibly difficult to pinpoint in the face of numerous variables. Therefore, if testing a number of categories that drive to the same causation conclusion, it drives our confidence in the root cause of an issue. It’s rare to find a 100% degree of confidence that one factor is directly driving an issue; however, the closer to that number, the more ideal. Considering the complexity of the interaction between people and process, one might find that multiple factors are drivers of project roadblocks. Define the relationships between those multiple factors and the project pain point to understand how to implement solutions.  Let’s delve into how data is leveraged to draw correlations based on our initial hypothesis or pivot to a new hypothesis supported through evidence.

Organisations that have fewer organisational process assets will require project managers to collect their own data to determine trends, which will lead to a lengthier hypothesis pressure testing time period. Pain points derived from a combination of external and internal stakeholders may require a secondary document managed manually by a project manager to determine correlations (e.g. an issue log). The method of hypothesis validation through data is just as important as the hypothesis itself. If you don’t have the correct data, you’re not ready to test. Consider testing multiple hypotheses in parallel if there is alternative data ready to go. Maybe the project sponsor isn’t creating any issues and team members are unaware of internal pain points when work transitions between teams? Reference a timeline and compare it against internal financial data to identify if budgetary inefficiencies correlate with internal project milestones. And now that I’m thinking of an alternative hypothesis, this has also revealed that looking at client project milestones in a timeline against finances could circumvent an immediate need for an issue log. Developing alternative hypotheses drives an ability to develop new ideas as I just did. Although I don’t recommend implementing multiple major process updates at the same time, pressure testing multiple hypotheses in parallel helps to avoid pigeonholing thought processes.

As is frequently the case, sample size is incredibly important. Looking at singular projects to determine trends will be misleading as differing environmental factors are distinct across projects. Therefore, when attempting to define broad correlations, define singular correlations for each project and log those into a data set. Then determine if there is a trend across projects. Since this process can be laborious, be mindful to work smart rather than laboriously. Once you’ve come up with a technique of determining internal vs external stakeholder-driven budget issues, is it possible to automate that or refine the methodology for future evaluations? It ultimately depends on how data is accessed and presented. Large sample sizes produce better conclusions, but if they are laboriously produced, it drains bandwidth. A streamlined approach will often lead to a willingness to drive larger sample sizes to reach more accurate correlations.

As trends are evaluated, there may be outliers in the data. Don’t discard these outliers, they can be incredibly revealing. Instead, dig deeper. Why do you frequently see a trend in one direction but occasionally in the opposite direction? The next key here is considering alternative variables to avoid the risk associated with confounding factors. Confounding factors are unmeasured or unconsidered variables. Many issues are not a result of just two competing variables but are influenced by three or more. If the first round of correlation analysis focused exclusively on comparing internal vs external project milestones to budgetary drives, maybe adding in another variable such as project type could reveal a more complex trend. Could certain types of projects be driven by internal efficiencies, whereas others are propelled via external pivots? Look to the data.

The data analysis test is often determined by how the data has been collected and what types of conclusions we are looking to determine. In this instance, I have suggested creating data categories to understand correlations or trends between the different categories. In this instance, a technique known as correlation analysis is used to inform if two categories are closely related in a data set.  A plethora of closely related, but distinct tests exist for multivariate analysis if there are multiple variables to understand.

If data is collected and organised consistently, use these parameters to determine how the data should be analysed. With information at the touch of our fingertips, delving into the value of differing types of analyses is a few search engine clicks away then an excel formula will do the remaining leg work. Alternatively, if organisational process assets are available to facilitate data analysis, leverage those to drive a work smart over hard approach.

If a hypothesis has been shown to be uncorrelated with a pain point via correlation analysis, it may be time to revisit the data to develop a new hypothesis. Are there correlations elsewhere in the data that align to prior team observations? The collected data is not wasted if unsuspected correlations are revealed. If a strong correlation is identified that aligns with the initial hypothesis, follow that data to the next step: process development and implementation.

Although uncovering a correlation is a significant moment, challenges remain ahead. After all, you still need to develop a process solution that is achievable, implementable, and can be sustained in the long term. Tune in next week to hear my thoughts on process development.

Early Considerations
Generally speaking, it’s more ideal to approach the portfolio/program process issues first. This may end up alleviating project-specific pain points as a result. Level-set the list of process issues based on Process Risk Scores and let’s try to develop some testable hypotheses. Hypotheses should be informed based on observations, but the key element is that they need to be testable. Trial and error is a vital element of troubleshooting, but repeatedly implementing process changes with the team, only to have them consistently fail in practice is going to wear down the team and project sponsor. Rather than play the trial and error game at the level of process implementation, start at pressure testing the early hypotheses. If a hypothesis is proven wrong, you have not failed, you have succeeded in eliminating an incorrect assumption. If there is no data to support a hypothesis, dig deeper or develop alternatives. You’re not ready to implement a change, if there aren’t any data-based justifications to do so. 

Many organisations collect project data that will allow for the evaluation of hypotheses against quantitative data. Watch out for your bias. Don’t fall in love with a hypothesis as you might then ignore data that refutes your initial idea or twist data to support it. Many innovations have been developed by proving that the first dozen hypotheses were incorrect. Although I love to talk up collaboration, I find the hypothesis pressure testing phase is ideal when done in a bit more isolation to allow for heads-down time to evaluate data. Leverage internal teams for supplementary data to further validate, but be mindful that running the team through the full gauntlet of hypothesis pressure testing might cause fatigue. Moreover, draining team bandwidth to focus on hypothetical process investigations may create issues for ongoing projects. Find the balance of bouncing a high-level idea off a team member without fully engaging them to evaluate the data.

A Budgetary Case Study in Hypothesis Development
Let’s think about a case study in budgetary efficiency. Sure, projects are going over-budget, but why is that happening? Individual team inefficiency? Difficulties between teams? Project sponsor pivots? For the initial hypothesis, rely on the early communication with key stakeholders along with process risk scores. If every single person on the team has indicated that the project sponsor pivots are driving budgetary issues, it’s likely a good starting point to investigate. Keep in mind, the point here is to attempt to understand the issue rather than to assign blame. More often than not, if we haven’t defined the problem, the stakeholder driving an adverse issue may not even realise it. Stakeholders, whether external or internally, are not deliberately sabotaging their own project. Be cognizant of Hanlon’s Razor: never attribute to malice that which is adequately explained by other causes.

Use the early stakeholder conversations to guide a hypothesis. The next step will be determining: is there data that will allow for validation? Some organisations log how finances on a project have continuously evolved, others purely focus on the end-state finances. If project sponsor-driven issues are suspected, create an issue log to facilitate trend analysis to determine if client issues do indeed drive budget inefficiencies. If you don’t have the appropriate data to test a hypothesis, do not try to make a square shape fit into a round hole. Take the time to generate supplementary data, when necessary, to understand how project decisions correlate with budgetary change across a project and portfolio.

In the next article, I’ll be continuing to discuss this budgetary case study with a focus on how to leverage data to validate hypotheses. Stay tuned next week!

As a first step in process change, I look to understand key stakeholder needs individually. There are often two high-level groupings to consider: internal and external. Some project managers work hand-in-hand with the clients, others learn of client needs through a specific client services team. Alternatively, projects can have internal sponsors; a company looking to drive an internal deliverable. For the sake of ease, consider the sponsor to be broadly grouped in the “external” category. Whatever the case may be, ensure that the end process goal is in alignment with the needs of the project sponsor. Work directly with a client services team or with the project sponsor to understand their needs. This is the first goal to establish and understand. The client will drive the desired end state because, simply put, they are paying for it. Be mindful of the ideal end state throughout the process optimization journey as it can be easy to let your own biases take you off-track. Many project managers like to keep projects moving with timing efficiency, but if project/product quality is compromised, few project sponsors are going to be satisfied when a poor quality project is delivered early.

You might have received some high-level concerns from the management team regarding a program or portfolio, but targeted solutions require a targeted understanding of the nuances. The day-to-day team members should have the best understanding of pain points. When working with internal team stakeholders, pinpoint colleagues that have the best holistic understanding and seek out their thoughts. Who has been working on this portfolio or program the longest? Who most frequently engages with the work? Who provides the most specific feedback? Who thinks that all is fine and who believes that there are significant issues? Not every team member will provide accurate feedback, but all feedback is essential. At times, understanding why a team member is providing misaligned feedback, may end up revealing a solution. 

Once the desired end-state is understood and key internal stakeholders have been identified, the next consideration will be documenting their observations and log who provides each piece of feedback. This guides my early understanding of the issues. Take the time to understand the issues through the lens of the team. Listening is about integrating information, rather than simply hearing it. With that said, many pain points arrive when differing teams have to work with one another or a misalignment between oversight roles and day-to-day roles within a craft. Therefore, the next step is to bring key stakeholders together from distinct teams and craft tiers to present the documented challenges. I prefer to keep the list of issues anonymous to avoid any biases related to who came up with each observation. Does the full team agree with the observations? Is there debate regarding the severity of issues? Do oversight roles within a craft disagree with the day-to-day team members? 

The use of scoring systems, similar to how we score for risk (severity x likelihood), can add an element of quantification to a subjective conversation. Have team members rank each item of challenges in a list in terms of severity and frequency. Call the scoring system what you’d like, but I’ll go with: Process Risk Scoring. This will allow the team to understand the highest priorities. If the team is consistently ranking certain challenges as very severe and highly frequent, you’ve got a high priority item that is reflective of a holistic process issue (pertaining to a full program or portfolio). If teams are ranking issues as severe, but infrequent, then these may be high priority, yet project-specific roadblocks. Keep the project sponsor needs in mind to further refine the first needs to address. 

Be thoughtful to cater solutions to where they are needed. Unnecessary processes impede innovation and ideation, whereas a lack of process drives inefficiency. Process homeostasis is context specific. When you’re wielding the process hammer, you might see every small issue as a nail to hammer out; be careful to not overdo it.

In the next article, I’ll be discussing how to develop hypotheses to explain the causes behind the identified pain points. Jumping to the process development and implementation steps before validating ideas with evidence can lead to process misalignment with business objectives. Stay tuned next week!

“If a tree falls in a forest and no one is around to hear it, does it make a sound?” Similarly, it’s impossible for information to make an impact, if no one is made aware of it.

Understanding your audience should be the first step to developing oral or written communication content.  I have witnessed numerous presentations that were filled with jargon and failed to to contextualize the importance of their work. The presenter delivery, design of the slides, and data could be fantastic; however, the audience was often left with more questions than answers by the end of it.  Continue reading →