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!