How do you maintain quality standards across programs and projects?

When shipping an initiative for review across teams, I love the Seth Godin prompt, “What do you see that I don’t see?” It invites collaboration across teams so people can openly share their perspectives. It sparks iterative improvement. It aims teams towards creating higher quality together.

Maintaining consistent quality standards across multiple projects can be challenging. One approach is to establish clear quality checkpoints at key project milestones. For instance, conducting regular code reviews and automated testing in a software development scenario can ensure code quality. ???? Also, fostering a collaboration and knowledge-sharing culture can improve quality. Encourage team members to learn from each other's successes and challenges, creating a dynamic environment for continuous improvement. ???? Establishing effective communication channels and project management tools can help track quality metrics and deviations. ???? #QualityAcrossProjects #ProjectExcellence

This thinking should be done up front in a proportionate business case. Quality standards may well be different across different projects. What matters is optimising the net benefits of each project - a school does not have to be architect designed, whereas a concert hall probably does. Projects deliver services - the outputs (e.g. Buildings, IT assets etc) simply need to be fit for purpose to deliver the required service.

In the digital age, data-driven decision-making is paramount. While defining quality criteria is essential, it's equally crucial to ensure that these metrics are adaptable. As the business landscape evolves, so should our understanding of quality. Regularly revisiting and refining these criteria, in light of new data and feedback, ensures that our programs remain relevant and effective.

Final purpose of quality is the contribution to the achievement of the benefits pursued in the program. Let′s always think on that before starting to define multiple metrics that will not provide value and will require effort to measure and report.

Quality assurance and control are not mere checkpoints but are the heartbeats of a project's lifecycle. Embracing a proactive approach rather than a reactive one, can make a significant difference. Leveraging modern tools and technologies, like AI-driven analytics, can provide real-time insights, allowing teams to anticipate potential pitfalls and address them before they escalate.

I agree, however it is essential to plan, but not over-plan. The busy bee-threat is also applicable here: make sure you plan out what is needed to deliver in the shorter term and not in months or years time, as the world, including your quality assurance standards have changed....

Regardless of the purpose, whether it be for code to drive a function or the measurement of functions that collectively represent the operations of a program, I recommend approaching the overall set of deliverables, like a project but replicable and living like a process. Like a project in that, there is a timeline, with defined deliverables, who is on point for what, and when. Like a process in that it is important to define and provide tools and expectations for quality control, quality assurance, and I would advocate for quality improvement as well. Making sure that QA, QC, and QI are embedded into your process provides a proactive approach, ensuring the highest levels of quality, while also leaving room for needed improvements.

QA/QC are essential steps to make sure that quality standards are met. But they are not met, you have to implement the proper corrective steps to get back to compliance.

Too many companies these days implement QA processes and controls late in the development process. It limits QA to a reporting process with little to no affect on the outcome.

Integrating an Operational Quality Framework (OQF) advances the traditional management of quality risks and issues. OQF employs AI-driven predictive analytics merged with Quality Risk Matrices, offering early identification of latent and overt risks. Complement this with a 'Quality-DevOps' strategy that embeds corrective and preventive actions throughout the PDLC. The introduction of a real-time "Quality Scorecard" offers further innovation. Tailored to align with stakeholder KPIs, this dashboard seamlessly amalgamates into existing PMO structures. It morphs quality from a static metric into a dynamic, evolving asset, providing a holistic, data-driven lens for continuous improvement.

If there is one thing that needs clear ownership, it is risks. When risk are actually occurring without a clear ownership, or without a clear mandate or authority to mitigate/manage, decision-making is not happening or surely delayed, causing serious business damage. So, besides, identify, analyse, priotitize risk, make sure you have the mandates and ownerships in place to make decisions quickly. Otherwise the implementation, corrective actions and preventive actions will not happen or will happen too late..

Programs and projects’ quality and risk management are intertwined. Identifying and mitigating risks (e.g., emerging AI harm risks and mitigations) proactively ensures that unforeseen issues do not compromise quality.

Culture is about people, and people need leadership, including leading themselves. Leadership has nothing to do with being directive, and has everything to do with being supportive. Yes, setting the direction and expectations is essential, but leaders should lead from the back once that direction and expectation is set. In my 20 years of military leadership this is the essence of battle-proven leadership. Inspirational Leadership as starting point and Situational Leadership as execution. That will create a learning and high performing team spiritual culture.

Always be good experimentalists. Quality control books can perfectly prescribe how to manufacture 99.99% acceptable PROVEN products, however the final, delivered results could vary significantly for NEW product introduction process. Changes of incoming raw materials, chipsets, team members, product marketing and even customer expectations would impact the next batch. Management should walk the floor, talk to the team, read customer reviews or even buy and sample the product, until the new product achieves the launch target and continue to be valuable to customers.

You have to also allow for feedback from the employees on the process to include what is working and what is not. There could adjustments made that can bring the system into compliance. They could be overlooked if you don’t have the team’s input.

Including QA/Dev from the initial ideas of the project/programs discussions helps, record the technical discussions meetings and share with the entire team members, creating entire team's communication channel, creating test cases before the development, clarifying the requirements, test case review with entire team including stakeholders, providing demo's to stakeholders end of each sprint, ensuring quality control processes like unit testing, code coverage, test by development team, testing by QA team in dev and QA environments, automation testing, bugs reported, Project milestone dates, project roadmap everything available to entire team to track the status of the Quality of the project in any tool like JIRA/Sharepoint locations.

Quality culture is supported by an organization's ability for continuous learning. Creating the shared belief of quality excellence - that's it's everyone's responsibility - provides the best opportunity to capture the other sections of this article: defining metrics, control processes, and risk control and mitigation. The feedback loop necessary to accomplish quality excellence needs to be supported and heard throughout the organization, so all team members will foster quality through continuous learning measures.

Practice the idea of "Quality is Everyone's responsibility not just QA". Lay out a process that measures the Quality of each project deliverable (Requirement, Design, Tech Solution, Test Approach, and right set of tools & and technology) from Ideation to end product delivery.

Every project is a story, filled with challenges, triumphs, and lessons. While methodologies and tools are essential, it's the human element - the passion, dedication, and resilience of teams - that truly drives quality. Let's not forget to celebrate and acknowledge this human aspect, for it's the heartbeat of every successful program.

Having a Robust framework for quality assurance and control is the key for the success of a program. Check points should be there for corrective and preventive quality issues taking into consideration both external and internal factors. This approach helps to reduce the cost of conformance and non-conformance. The people, process and technology aspect need to be brought into a quality management plan which helps to achieve the desired quality outcomes by tailoring the metrics and KPI's. After all people and processes drive the quality wheel so it is akin to fostering the quality culture and having a lot of oversight on the continuous improvements.

I believe the biggest injustice to any set of standards is ACCOUNTABILITY. From a QA perspective, this includes activities being carefully thought out, knowledge sharing, collaboration, etc. You can't achieve those unless you have a group of people willing to take accountability for the pieces they own while also sharing in the accountability of the overall success or failure of any effort. Accountability doesn't need to be a negative word - it's simply an opportunity to expect failures, accept failures, and learn from failures. By doing so, the path towards quality standards, improvements, automation/innovation, and knowledge/education should be easily visible.

With data, analysis, systems, automation, AI, digitalisation we forget an important element: ownership. And all the tech in the world is "just" an enabler for a process to be run more effectively and efficient: it is the outcome of an action/process that delivers the value, not the technology. It should never start with the technical solution, and always start with what you want to do (process) to achieve what (goal/objective). My favourite example: your electric toothbrush doesn't brush your teeth by itself (=tech is an enabler) and it doesn't relief you from your responsibility (=ownership to brug your teeth 2 or 3 times a day (=governance) ...