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!