Change Board
This is the fourth of a series of posts about tools I've built or used to make life easier. Although I did make a new Excel spreadsheet to keep it all organized, Change Board was more about how I prepared for, ran, and followed up on meetings than the tool itself. I know this because I passed the tool on for others to use and when I was invited to see others using it their meetings didn't feel as crisp. Change Board feels like something that shouldn't be especially difficult, but I've seen lots of programs with nonfunctional Change Boards.
Previous posts in the series:
Increased Scope Means More Change Board
I hosted my first Change Boards when I became a Program Manager. Initially that meant small direct-ship programs (the parts never touched our docks, just shipped directly to the customer) with minimal design changes and stable schedules. I used the format that the previous Program Manager had developed and after a short time Change Board was just an item on our regular weekly "IPT" touch-base (Integrated Product Team) rather than its own meeting.
When I moved into new product development, we needed a more robust process. Initially we were dealing only with Engineering changes: whether we had accepted the latest customer specifications documents or if the longest-lead parts drawings were ready to release. As time went on, we had drawings going to suppliers and parts being machined and we really needed the team aligned on everything going on with the program. Change Board grew from 30 minutes alternating weeks to an hour each week. But in that time we got the latest updates in and decisions made and I was told that my Change Board was one of the very few where participants actually felt like the call was valuable to them.
How It Worked
NOTE: this is how the tool ended up. We iterated through several versions, including one that stored data in our Engineering data system, before we reached this state. I kept minutes in an Excel spreadsheet with a different tab for every change request we had open, plus several summary tabs.
The first tab was attendance: every function invited and the name of the normal representative down the left side and a list of weeks across the top. This made it easy to see if a given function had not attended or sent an alternate for a few weeks and the issue could be addressed.
Second was a summary of the production schedule to put everything in context for the team, and highlighting any schedule changes that people would need to watch out for, especially in the Supply Chain and Operations teams.
Third was a summary of every open item. This included the identification number, title, and whether the change was "hot", in which case we would talk about it first in case we ran out of time in the meeting. We'd walk through each change request, where I'd take notes on the sheet while sharing it on-screen so people could see what I was writing, and always tried to capture the next action or who it was with. A little summary box in the top of the change sheet would include the functions we were waiting on for the change ("approved", "not ready", "waiting"), and the tab at the bottom of the sheet was highlighted red if hot, purple if closed (let's celebrate those!), and yellow if it was "cold": to be discussed last because there was little harm in letting it go stale for a week.
Note-taking + Minutes + Agenda + Follow-up = Magic
The taking notes live was key: it meant that everyone saw the status of the change the same way, and if I had the same "waiting on X" note for several weeks in a row, it could prompt me to redirect the change or escalate the issue through functional management. Taking notes live also meant that sending out minutes was easy: save the file on our SharePoint and then email it to everyone so they had a record of what we discussed. Other programs might not see the previous week's Change Board minutes until right before the next Change Board, if at all.
Two business days before the next Change Board, I would pull the previous file, rename it, and send it out as an agenda after removing any items we'd agreed to close the previous week. As part of this process I flipped through every open change to ensure that we had the "hot" and "cold" changes correctly categorized and often sent individual follow-ups to individuals on Change Board if I hadn't heard of their progress earlier that week. This gave them 1-2 days' time to get a task done before having to admit "no progress" in the next Change Board.
Conclusions
By the time I left the program, we'd gone from pre-proposal concept drawings of the product through Preliminary Design Review, Critical Design Review, flight-test and qualification-test hardware deliveries, and cleared the program for flight. This included a customer-initiated major design change AFTER Critical Design Review where they wanted to change how the landing gear shock absorber behaved. I'm grateful to everyone who worked on the program (you know who you are, you got commemorative "first chips" of the machined parts) and proud of what we accomplished.
If you have any comments, please reach out to me at blog@saprobst.com or this page is cross-posted at LinkedIn and you can leave a comment there.
Comments
Post a Comment