The million-dollar question to every Program Manager comes down to schedule versus (_fill in the blank_). Be the reasonable budget, resource, priority, quality, or relevance, the constant struggle of the PM is keeping a schedule without sacrificing too much from the project itself.
I have seen varied examples in the industry: new product introduction life cycles lasting up to three years (risking the loss of technology advancement in the market) and very aggressive tear-down life cycles that sacrifice quality and accuracy (quite possibly acting as a catalyst to this company's slow demise).
For the purpose of this piece, I want to chat about an experience where I prioritized process over schedule, review some of my reasons behind it and share what I have found.
Projects executed prior to any process improvement, require the process to be revisited but there may not be any tracking information to recreate the process. This becomes an issue for quality assurance and recall purposes. It is also difficult to know at what point of the process the issue occurred. This makes it difficult to immediately implement improvements for current and future projects in the pipeline.
Even the imperial dynasty in China kept records with a type of part number in order to be able to track who owned what part of a weapon or statue. That person faced capital punishment in the case of a defective failure. Quality control and responsibility ensured high-quality work. The same is true in the present, although with a different set of consequences.
Another issue with maintaining the same process time after time or even not having any process at all is the amount of patch-up work required to maintain such a broken system. If I don’t have a streamlined process to release even the most simple document, I place that document at risk of missing a step, missing an approval, or missing an improvement needed to graduate to the next revision. I have experienced a higher than normal yield loss in an engineering build due to the wrong revision of a specification being released to a contract manufacturer. Upon tracking this I ensured there was a dual-approval process moving forward to ensure the release of this specification was not left up to one poor busy electrical engineer but reviewed by a team of qualified contributors.
Where then, does that place us with prioritizing process over schedule and vice versa? Ultimately the purpose of implementing process improvements is to streamline and improve the schedule. Therefore, if implementing improvements is pushing out the schedule it may defeat the purpose. I recommend implementing the improvements in increments similar to Agile methodology in software. Starting with an initial list of improvements and re-evaluating helps to determine the pain points to prioritize.
Some items that are easy wins in implementing from the get-go include: labeling documents and builds labeling revisions, and numerical versions. Other easy wins are adding feature call-outs, versions, and consistent key product indicators.
Periodic team check-ins are also an easy win. These open sessions can be used as an opportunity for the team to share their accomplishments, collaborate on ideas, and utilize as a forum to cultivate solutions for any pain points or issues along the way. The ROI on the check-ins should be very high with minimal time used. Having working groups divided up into sections to address the needs of specific sub-teams or individuals is another efficient way to ensure the best use of time.
In the end, it is possible to implement improvements in increments to support the schedule and the process. This reduces disruption and allows the team to maintain the backing of executive management.
No comments:
Post a Comment