Thursday, June 26, 2014
Blame Game
April Jefferson worked with me and the DMS team today in a team session on dealing with blame cultures and behaviors. It was a swift and fun approach while being informational and engaging. I thought I would cross post her blog here on the subject and encourage you to check it out.
http://curiousagility.blogspot.com/2014/05/its-your-fault.html
April is working with DMS and the Solutions Center as an agilist for the next 6 months. Stop by and visit in B200 if you have a chance.
The Results of Lean Thinking Applied to Schedulon and A/V
-- Tony Markel
A little over a year ago, we were failing to meet customer expectations when it came to A/V service. In a three month period we received over 50 complaints through Zendesk, from our leadership, and from our customers. Customers could ask for, or change service for their events at any point in the process. In a few cases, astute observation by the A/V team averted disaster when customers assumed service would be provided. Reservations passed through many hands, increasing the chance for error. The processes and systems required many time consuming steps. All of this added up to a lot of missed expectations, and a fantastic opportunity to improve.
Jack Kufahl suggested we try a Lean A3, and that we use a Lean coaching process described in this presentation. Internally, we called it "The Three Little PIGs", as an offshoot of our Process Improvement Group. This post doesn't get into the details of the A3 process, but focuses on the results of the technique.
Our First Problem: Customers aren't getting the services they've requested.
We addressed this by making a single entry point for service requests, placing the Service Desk up front in the process, using our Service Delivery Model. This meant that customers were able to request services in a consistent way, and it improved our first time quality on service requests from 3% to 34%.
With the new process, the Service Desk asked customers what they wanted for their event. This was a new skill we were trying to develop, and a kaizen burst of training and documentation seemed to be all we needed. While it did help, there were a couple of problems with this approach. First, the amount of time required to gather the information from a customer was longer than we anticipated. This caused us to hold onto service requests until just before the event was scheduled. This increased wait time (and anxiety) experienced by the customer. Second, the A/V technicians were re-confirming all the details with the customer. Thus causing some rework. Customers were confused as to why they had to tell us twice, or why someone who wasn't working the event was trying to ask all the event-related questions.
Meanwhile, the amount of space visible in Schedulon had been growing. The Schedulon interface, especially the menu hierarchy, became more confusing. It became a mixture of purpose (a meeting) and location (that building over there), that made it hard to find what was needed.
Our Second Problem: Customers have trouble telling us what they want.
The countermeasure for this problem is to schedule service providers through the Service Desk, and empower the A/V team to discover the customer's needs by connecting the customer earlier in the process. The Service Desk remains the first point of contact for the request, and the central scheduling resource.
As for finding space, a 5S technique was used to clean up the menus in order to help customers find what they need.
It's really amazing to be able to see the results of applying Lean structured problem solving techniques to pernicious service problems. Twice now, we've used this methodology to help improve the value of the A/V service MSIS provides to it's customers. If you'd like a copy of the A3's we prepared, just ask. You can see the customer facing bits of the changes below.
Making A/V Requests (see screen shot below)
The form you use to make A/V requests is now simpler and easier to use. The previous form had five different options, some of which were overlapping, and many of which were confusing. Now we ask for someone to contact on the day of the event, when and for how long you expect us to be there, and if you need service. Please note that A/V services are fee-based. A full fee schedule is available in Schedulon and our Knowledge Base.
Fulfilling your A/V requests
We listened to your feedback. We understand that having to convey event details up front to our Service Desk and again to our A/V Team was redundant and tedious. We’ve simplified that too. Future requests will still pass through the service desk, so that we can handle urgent requests, but an A/V technician will confirm the event details with you. This will reduce the amount of rework being done today, and increase the accuracy of your order.
Finding Space
The menu hierarchy in Schedulon is a bit confusing. As we’ve grown, we’ve noticed that we need to re-organize the structure. Based on input from schedulers and administrators, we’ve decided that space in Schedulon will be divided into three categories:
Meeting Space
- These are conference rooms, enclaves, and offices. Typically these are used for administrative purposes. Meetings are booked either into spaces which are free and open (like NCRC) or controlled (like most of the Medical Campus).
Event Space
- These are Auditoriums, Venues, and Atriums which are typically used for larger gatherings, or events which require professional services. All are controlled spaces, so that service teams can be scheduled to provide for the events as they are scheduled.
Classrooms
- These are tightly controlled spaces where classes are held. During the term, free time can be used for meetings, although student use is given highest priority.
Getting Resources
- Service and resource related items will go under a separate menu called Get Resources.
Thank You
Greyson LaHousse - Problem Owner & Service Desk Agent
Dave Cuevas - Problem Owner & Service Desk Agent
Tony Markel - Reviewer & Service Manager
Monica Webster - Observer & Process Manager
Marilyn Mason - Stakeholder & A/V Technician
Caleb Newman - Stakeholder & A/V Supervisor
Rob Levitt - Stakeholder & Service Manager
Steve Lambert - Product Manager
Steve Sarrica - Product Management Supervisor
Joyce Kiger - Customer
Renee Hafner - Customer
Tammy LaPrell - Customer
Joyce Kiger - Customer
Renee Hafner - Customer
Tammy LaPrell - Customer
Wednesday, June 25, 2014
View from the Trenches
Like many people, I started life at the bottom of the business food chain. My first job was as a dish washer. I subsequently worked as a stock boy, janitor, shoe salesman, and even a Pinkerton security guard. Eventually, I went to college and got a degree. This allowed me to get more illustrious jobs like computer salesman and systems engineer.
All these jobs have one thing in common -- the view to the top is hazy at best. In the trenches, we usually receive our marching orders and we carry them out. In the modern professional environment, we are expected to use our heads to creatively carry them out, but carry them out we must. How many times have I said "what idiot came up with this plan?" Far too many. I'd often wonder what it took to become a leader because it didn't seem to have anything to do with brains.
Then, one day I became the leader. "I" was the idiot making the stupid decisions. Here's the thing: the view from the top is always different. At first, this troubled me. I decided I'd try to fix the problem. So, I called all my employees into a room and proceeded to tell them everything they didn't know. I took them through financial statements. I explained about supplier negotiations. I shared my vision for how the company needed to transform because of our changing market.
All this "stuff" that was clear and obvious to me was mostly lost on them. Don't get me wrong. They really appreciated that I'd shared all the details with them. I believe it built a lot of trust and maybe my idiot index dropped a few notches. Ultimately, only a few people cared enough about the things I needed to deal with to expend the effort to integrate the information I shared into their thinking about their own job. Frankly, I did a lousy job of making the connections for them.
Now for the really strange bit. I always assumed that when I went back into the trenches, it would be different. Having been to command central before, I would have a new appreciation for all the "stuff" that leaders need to deal with that the rest of us don't. I thought that somehow, I would be able to magically see through the fog and understand my place in the organization so much better. HA!
The reality is much the same. The reason is much the same. Even if the leadership decided they wanted to spend the time and energy to share everything that makes up their perspective with us, we are too busy doing our job here in the trenches to take it all in. They spend all their hours every day immersed in things that are at best tangentially relevant to our jobs. These "things" shape their view of the world. It is a different view than the one we have in the trenches.
What I learned during my time at the top is that the best you can hope for is trust. If you work openly and honestly with people and take every opportunity to demonstrate that you really care about them, they will eventually learn to trust you. They may still think you're an idiot sometimes, but they'll know you're an idiot they can depend on. For those of us in the trenches, remember not to just peer longingly into the haze. We are fortunate to have a leadership team willing and happy to explain what they know. Just ask.
All these jobs have one thing in common -- the view to the top is hazy at best. In the trenches, we usually receive our marching orders and we carry them out. In the modern professional environment, we are expected to use our heads to creatively carry them out, but carry them out we must. How many times have I said "what idiot came up with this plan?" Far too many. I'd often wonder what it took to become a leader because it didn't seem to have anything to do with brains.
Then, one day I became the leader. "I" was the idiot making the stupid decisions. Here's the thing: the view from the top is always different. At first, this troubled me. I decided I'd try to fix the problem. So, I called all my employees into a room and proceeded to tell them everything they didn't know. I took them through financial statements. I explained about supplier negotiations. I shared my vision for how the company needed to transform because of our changing market.
All this "stuff" that was clear and obvious to me was mostly lost on them. Don't get me wrong. They really appreciated that I'd shared all the details with them. I believe it built a lot of trust and maybe my idiot index dropped a few notches. Ultimately, only a few people cared enough about the things I needed to deal with to expend the effort to integrate the information I shared into their thinking about their own job. Frankly, I did a lousy job of making the connections for them.
Now for the really strange bit. I always assumed that when I went back into the trenches, it would be different. Having been to command central before, I would have a new appreciation for all the "stuff" that leaders need to deal with that the rest of us don't. I thought that somehow, I would be able to magically see through the fog and understand my place in the organization so much better. HA!
The reality is much the same. The reason is much the same. Even if the leadership decided they wanted to spend the time and energy to share everything that makes up their perspective with us, we are too busy doing our job here in the trenches to take it all in. They spend all their hours every day immersed in things that are at best tangentially relevant to our jobs. These "things" shape their view of the world. It is a different view than the one we have in the trenches.
What I learned during my time at the top is that the best you can hope for is trust. If you work openly and honestly with people and take every opportunity to demonstrate that you really care about them, they will eventually learn to trust you. They may still think you're an idiot sometimes, but they'll know you're an idiot they can depend on. For those of us in the trenches, remember not to just peer longingly into the haze. We are fortunate to have a leadership team willing and happy to explain what they know. Just ask.
Tuesday, June 24, 2014
Not all those who wander are lost.
-- Erik Zempel (with Tony Markel)
Sometimes you go looking for one thing and find another. ZenDesk has been a great tool for us, but it costs a little more than we’d like to be spending on a ticketing system. So we set off to find a replacement that included the things we liked about ZenDesk, but costs less to operate. Initially, we set our sights on ServiceNow. ServiceNow is an ITSM tool currently used by ITS and under investigation by MCIT. There were all kinds of good, collaborative reasons to look at it.
On paper, ServiceNow had all the features (and then some) that we were looking for. And others in the “U” were looking at it as well. Seems like an easy choice, right? Unfortunately, even under a shared service model, ServiceNow wouldn’t give us the cost-savings we were after. We’d be paying for features we’re not currently using. What’s lean about that?
So we looked into other solutions and arrived at Atlassian Service Desk. Service Desk is a younger product without all the bells and whistles of a full ITSM suite, but does almost everything we need it to. Almost. It was sorely lacking a customer satisfaction survey. Fortunately, Atlassian is very customizable and we were able to prototype a survey solution leveraging Qualtrics as the survey engine.
Is Atlassian Service Desk the final word in ticketing systems for MSIS? No, definitely not. But it’s given us a little breathing room in the budget while maintaining the capabilities we have today. And the act of evaluating our ticketing system has given us a better understanding of what’s really important to us.
Wednesday, June 18, 2014
VM's For Sale, Cheap!
Imagine a world where research, software development, and online learning rule. Imagine independently owned, yet centrally supported virtual machines taking on Amazon, Dell, HP, Newegg, and Best Buy . . . and winning. Imagine all this in an affordable package that makes it easy to get the resources you need, when you need them.
It’s been more than five years since MSIS started providing virtual servers for the institution, and the goal is still the same — to reduce the risk of buying your own equipment and jamming overpriced hardware in the eye with the stick of safe, affordable, computing.
These servers are cheap!
| Processor | Memory (RAM) | Hard Drive | Network Data Storage |
| FREE | $34.20/GB/year | $1.80/GB/year | $0.32/GB/year |
| FREE | $2.85/GB/Month | $0.15/GB/month | $0.03/GB/month |
Cheaper than a fancy steak dinner!
| Configuration | MSIS | Amazon EC2 | Physical Server Hardware |
| Small (1 Processor/2GB RAM/50GB HD/No Storage) |
$158.40/Year |
$392.52/Year |
$575.00* |
| Medium (2 Processors/4GB RAM/50GB HD/100 GB Storage) |
$258.80/Year |
$922.32/Year |
$1105.00* |
| Large (4 Processors/16GB RAM/50GB HD/1TB Storage) |
$964.88/Year |
$1844.64/Year |
$4949.00* |
Safe as Houses!
Nobody wants to lose their research and important data. We make sure to back their stuff up every day. Each byte of data is lovingly copied and transferred to a safe location. We house it and keep it warm for two whole weeks. Restores happen in a day from when unexpected happens.Did I Mention Cheap?
Still not convinced? Still need more evidence? Here's how much backup and restore for virtual servers costs:Zero. Zilch. Bupkis. Nada. Zip. Nuthin.
But wait, there's more!
Think about the hidden costs and risks. Flood! Fire! Theft! Tired graduate students tripping over power cords! If you're buying physical hardware, you've got to worry about, power, cooling, backup, and people to run the equipment. How much more productive would our researchers and faculty be if they didn't have to worry about RAID cache backup and sudden power loss?Help us my fellow MSIS-ers! Broadcast the propaganda in our Knowledge Base and use the tools to talk to our customers throughout this amazing institution. Together, we can wipe out the disasters of running your own equipment, and launch a movement that builds a new world out of the detritus of the old!!
* Based on HP catalog orders for the University of Michigan. Does not include backup, power, and cooling costs.
Friday, June 13, 2014
Stewardship
I was reading through the One MSIS guiding principles this morning and I came across a word I hadn't seen in awhile -- stewardship. I was reminded of a book I read by Peter Block by the same name. Peter started his career as an expert in consulting. Born out of his work in that area was a realization that stewardship is a concept lost on far too many people these days.
What is stewardship? I could give you the dictionary definition, but you could look that up for yourself. In practice (where it really matters), stewardship is about taking ownership of something and placing sufficient value on it to commit the effort to care for it the way you would a prized possession.
Peter Block is now primarily a government consultant. He switched gears when he had the realization that citizens no longer seem to understand their role as stewards of their government. They feel more like customers. They pay taxes and expect services. The problem is, they don't really want to pay for all the services they want. This is bad stewardship. Block teaches (mostly local) government officials how to engage citizens in taking ownership of their government and actually engaging in activities that solve problems.
When One MSIS calls upon us to be stewards of the UMMS technological infrastructure, what does that mean to you? What do you own? What can you do to make it better? I see many examples of good stewardship around here. I suspect most, if not all of us have an intrinsic understanding of the concept of stewardship, even if we haven't put a name to it. Working in an organization full of good stewards is not just rewarding to the people we serve, it is also rewarding to each other and ourselves.
What is stewardship? I could give you the dictionary definition, but you could look that up for yourself. In practice (where it really matters), stewardship is about taking ownership of something and placing sufficient value on it to commit the effort to care for it the way you would a prized possession.
Peter Block is now primarily a government consultant. He switched gears when he had the realization that citizens no longer seem to understand their role as stewards of their government. They feel more like customers. They pay taxes and expect services. The problem is, they don't really want to pay for all the services they want. This is bad stewardship. Block teaches (mostly local) government officials how to engage citizens in taking ownership of their government and actually engaging in activities that solve problems.
When One MSIS calls upon us to be stewards of the UMMS technological infrastructure, what does that mean to you? What do you own? What can you do to make it better? I see many examples of good stewardship around here. I suspect most, if not all of us have an intrinsic understanding of the concept of stewardship, even if we haven't put a name to it. Working in an organization full of good stewards is not just rewarding to the people we serve, it is also rewarding to each other and ourselves.
Monday, June 9, 2014
Knowing You Know or Just Thinking You Know
On at least two occasions in my life, someone insisted on wagering on a fact. Both times, I won the bet. There were other times in which the situation was similar, but I opted not to bet. The difference? Knowing I know and thinking I know. I refuse to bet on facts when I only think I know. The key is understanding your source and whether or not "the truth" is fluid.
If we lived in a black and white world in which everything was either true or false, life would be simple. Unfortunately (or fortunately, depending on your perspective) we live in a world of infinite variation in which most of what we know either was wrong at one point or will be wrong someday. Once upon a time, you would be burned at the stake as a heretic for suggesting that the Earth was not flat. Thankfully, the Earth is no longer flat. The facts have changed.
Facts change all the time. And, we're talking about "facts" here. You know, those immutable truths that are black and white? Now, think about all the stuff we "know" that is not based on hard facts, but rather a series of opinions and empirical evidence.
Have you ever gotten into a debate with someone about what is "the best <your thing here>?" Being the best requires being better than competing options in at least most if not all variables by which it could be compared. What are those variables? Are some more important than others? How should each variable be evaluated? It's tricky...and subjective. It's no wonder that people debate.
Debate is good and healthy, if you approach it with an open mind. In other words, it's okay to "think" you know, but be very selective about the things you "know" you know. Would you be willing to bet everything you own on it? If the answer is "yes," then chances are you really do know you know (or you have a serious gambling problem). Understanding the difference can open your mind up for new learning opportunities that you may have missed before.
It might just cause you to ask some questions rather than blindly defend your existing knowledge. Questions like "where did you learn about that" can be extremely valuable. Lot's of people use "I read it on the Internet" as their source for knowledge these days. To this, I simply refer you to this website: The Flat Earth Society. The source of knowledge is often more important than the knowledge itself.
Don't just ask other people to question the sources for their knowledge -- question your own. When I can't remember how I know something, I am a lot more suspect than when I know my sources are good. We work in an academic community in which the rigor of the scientific method is paramount. Yet, even within the scientific community statistical validity does not create a black and white set of truths.
It's complicated. Just keep that in mind next time you find yourself disagreeing with someone.
If we lived in a black and white world in which everything was either true or false, life would be simple. Unfortunately (or fortunately, depending on your perspective) we live in a world of infinite variation in which most of what we know either was wrong at one point or will be wrong someday. Once upon a time, you would be burned at the stake as a heretic for suggesting that the Earth was not flat. Thankfully, the Earth is no longer flat. The facts have changed.
Facts change all the time. And, we're talking about "facts" here. You know, those immutable truths that are black and white? Now, think about all the stuff we "know" that is not based on hard facts, but rather a series of opinions and empirical evidence.
Have you ever gotten into a debate with someone about what is "the best <your thing here>?" Being the best requires being better than competing options in at least most if not all variables by which it could be compared. What are those variables? Are some more important than others? How should each variable be evaluated? It's tricky...and subjective. It's no wonder that people debate.
Debate is good and healthy, if you approach it with an open mind. In other words, it's okay to "think" you know, but be very selective about the things you "know" you know. Would you be willing to bet everything you own on it? If the answer is "yes," then chances are you really do know you know (or you have a serious gambling problem). Understanding the difference can open your mind up for new learning opportunities that you may have missed before.
It might just cause you to ask some questions rather than blindly defend your existing knowledge. Questions like "where did you learn about that" can be extremely valuable. Lot's of people use "I read it on the Internet" as their source for knowledge these days. To this, I simply refer you to this website: The Flat Earth Society. The source of knowledge is often more important than the knowledge itself.
Don't just ask other people to question the sources for their knowledge -- question your own. When I can't remember how I know something, I am a lot more suspect than when I know my sources are good. We work in an academic community in which the rigor of the scientific method is paramount. Yet, even within the scientific community statistical validity does not create a black and white set of truths.
It's complicated. Just keep that in mind next time you find yourself disagreeing with someone.
Friday, June 6, 2014
Feeling Burned Out and Overwhelmed - Five Coping Strategies
This is a personal account of how I regain my productivity when I've dug myself into a productivity hole at work. Hopefully some of what I do works for you. Some of the remedies are taken straight out of the pages of Lean and Agile.
Occasionally, I look at my inbox, my ticket queue, my project backlog, and I say to myself:
Occasionally, I look at my inbox, my ticket queue, my project backlog, and I say to myself:
I have so much, so much to do, I don't even know where to start.This is the point where I sometimes just give up and react to whatever gets in my face. It usually doesn't end well for me or the people I'm trying to help. A different approach is needed.
Strategy One: Give yourself permission to relax and get some space to think.
Get a cup of coffee and go somewhere quiet, lock yourself in an enclave, take a walk. Get away and collect your thoughts. Staring at the endless stream of IM's, Emails, Stories, and Tickets isn't going to help. In fact, if you're feeling overwhelmed right now, go ahead, take a walk, sit outside and admire the flora and fauna, it's okay, I'll be here when you get back. Sometimes that's all I need to get back into it.Strategy Two: Eliminate distractions by any means necessary
Find a quiet space, use a quiet room, ensconce yourself in an enclave, put on headphones, turn distractions like Email, Instant Messaging and Skype pop-ups. Just make sure your team knows where you and what you're doing. "I need some space to work on this, I'll be here, and I'll be back in a bit." If you're staying visible, it's okay to tell someone politely to leave you alone. "I understand you need to talk to me. I need to work on this now, can you try me later? Thanks!" Conversely, if someone is deferring you from talking to them, don't take it as a slight.Strategy Three: Find one thing you can accomplish and get it done.
It can be a story, a ticket, cleaning out the holiday cookie tins from your desk drawer, or finally responding to that email from your manager about that thing you forgot to do. You'll feel better, and you'll free that mental backlog for other tasks.Strategy Four: Break big things up into smaller chunks that can be accomplished.
I recently agreed to clean out the basement while my spouse washed and folded the laundry. Which one clearly identifies what a finished task looks like? What does cleaning out a basement even mean? If you saw my basement (which some of you will soon), you'd realize that Sisyphus had it easier. Instead of vague, unmanageable phrases like clean out the basement, I organized and put away my tools, and disposed of old paint.
Strategy Five: Make three lists. Things I can do, Things to defer, Things that need help.
The act of organizing your tasks into categories, eliminates a lot of mental noise. I try (and fail mostly) to start with the things I defer. Usually these are requests that I really shouldn't engage with, because there are better resources to solve those problems. Next, the things that need help are things I can't do without someone to clarify or do something for me. I make sure (most of the time) to engage the resources I need, and move on the things I can do. It's usually a short list at this point.
Now, you should be have a clear picture of what you need to do, and some mental clarity to accomplish what needs to be done.
Some tools and techniques that may help you:
- Good ToDo
- Pomodoro Technique
- Bit Literacy
Iron Shrimp is Dead...Long Live Iron Shrimp!
In a dynamic organization, reorganizations are inevitable. As people come and go and leadership strives to optimize the value of existing resources, change is inevitable. So, when the team on which I began my career here at MSIS, Iron Shrimp, was disbanded, I went with the flow. However, the products we supported live on. One of those products is the Psychiatric Inpatient Application or PIA.
PIA was an experiment in doing agile development right. We took on the project for UMHS because they didn't have the bandwidth to do it for their client. It gave us an opportunity to allow the team to pick the development platform and use test driven development. By all accounts, the effort was a whopping success.
Through three different project managers, the team managed to develop a product that the product owner finds to be spot on! He has told me on several occasions that he plans to talk about how this application has changed his world at various symposia throughout the country. Before they had PIA, which runs on an iPad, caregivers would check critical patients every 30 minutes unless there was a specific reason to monitor them more closely. This was the best they could do with their paper system.
By reorganizing the data on each patient on a single screen, we have enabled them to check EVERY patient at 15 minute intervals 24/7/365. They simply cannot do this without PIA. Data for the application is collected from CareLink. However, today we will be switching it to pull data from the new MiChart (Epic) system. It also pushes data back into the patient's MiChart medical record. This is also something that was not done prior to PIA.
Although Iron Shrimp no longer exists as a team; Ed, Bennett, Dan and I remain deFacto members. Oh, and as for the development of the application: the users have been relying on it for over five months now. Number of support requests? One...and it was a user training issue. Long live Iron Shrimp! Three cheers for test driven iterative development with full product owner participation.
PIA was an experiment in doing agile development right. We took on the project for UMHS because they didn't have the bandwidth to do it for their client. It gave us an opportunity to allow the team to pick the development platform and use test driven development. By all accounts, the effort was a whopping success.
Through three different project managers, the team managed to develop a product that the product owner finds to be spot on! He has told me on several occasions that he plans to talk about how this application has changed his world at various symposia throughout the country. Before they had PIA, which runs on an iPad, caregivers would check critical patients every 30 minutes unless there was a specific reason to monitor them more closely. This was the best they could do with their paper system.
By reorganizing the data on each patient on a single screen, we have enabled them to check EVERY patient at 15 minute intervals 24/7/365. They simply cannot do this without PIA. Data for the application is collected from CareLink. However, today we will be switching it to pull data from the new MiChart (Epic) system. It also pushes data back into the patient's MiChart medical record. This is also something that was not done prior to PIA.
Although Iron Shrimp no longer exists as a team; Ed, Bennett, Dan and I remain deFacto members. Oh, and as for the development of the application: the users have been relying on it for over five months now. Number of support requests? One...and it was a user training issue. Long live Iron Shrimp! Three cheers for test driven iterative development with full product owner participation.
Monday, June 2, 2014
ABCs For Meetings
ABCs For Meetings
Drew Montag
I’m currently reading
a military thriller (think Tom Clancy) by Richard Herman Jr., “Iron Gate”. In it, there’s a description of the daily
briefings held by the commanding general, kind of like our morning standups. Everyone who gives a report is very aware of
the “ABCs” for a meeting with the general:
- A – Accurate
- B – Brief
- C – Complete
They seem like good guidelines for our standups.















