Embracing Change: Thriving in a Dynamic Business Environment

Change is constant and inevitable. In business, embracing change is essential for survival and growth. Change leadership is more about mindset than job titles. Here’s how to thrive amidst change:

Understand Change

• Constant: Businesses that don’t adapt risk obsolescence.
• Multidimensional: Impacts all levels—organizational, team, individual.
• Driven by Multiple Factors: External (market trends, tech) and internal (culture, leadership).

Strategies for Success

1. Foster Continuous Learning: Promote upskilling and reskilling. Encourage lifelong learning.
2. Embrace Technology: Use digital tools to enhance productivity and customer experience.
3. Promote Agility: Adopt flexible methodologies. Respond quickly to changes.
4. Empower Leadership: Encourage initiative at all levels. Foster a culture of ownership.
5. Communicate Effectively: Maintain transparency. Address concerns promptly.

Conclusion

Change brings opportunities for growth and innovation. By understanding and embracing it, businesses can not only survive but thrive. Prepare, adapt, and leverage change for success.

Entrepreneurship - Problem Statement

A problem is a bad thing, right? Not necessarily. If you're trying to get hired to do a project for someone or start up your own business to provide various products and services to people, you have a clear problem you are trying to address.

The biggest issue I see with problem statements is that they generally come across as solutions or tritely state that the lack of this specific solution is a problem. In theory, it is great to be positive and go right to what you recommend in order to make your communications as clear as possible, but if there's no established problem, then no one will be listening, no matter how polished the sales pitch.

You have to bring attention to the imbalance, tension, or pain that exists in order to be able to show that your recommended solution will counteract it.

The following is a list of questions to ask to help define the problem. Without knowing the answers to these questions, the attempted start-up business is doomed to fail.

• Context - when does the problem occur?
• Customers - who has the problem most often?
• Problem - what is the root cause of the problem?
• Emotional impact - how does the customer feel?
• Quantifiable impact - what is the measurable impact (units)?
• Alternatives - what do customers do now to fix the problem?
• Alternative shortcomings - what are the disadvantages of the alternatives?

Look at each question and answer them honestly. Hopefully, an entrepreneur has a passion for their business, but sometimes that passion can create a blind spot, where it's difficult to be honest with how good the proposed new product/service is. Include some other people in the process who are willing to be honest in answering the above questions.

If you don't know when the problem occurs or who it occurs to, stop right there. Your target customer needs to be clear since they are the ones you hope will pay you to solve their problems. Knowing that there is a problem is one thing, but knowing what is causing it is something else. A more elegant solution will be to address the root of an issue rather than just the symptoms.

People are emotional. They're also logical. Sometimes one side of the psyche wins out. Sometimes the other one does. How much better is it if you can make both emotional and logical pleas?

If you see a problem, chances are someone else does, too. Sometimes problems are small enough that the big players in the market don't find it worth their time to address the niche. As you look at the current alternatives to solve people's problems, consider what both works well and poorly about those current solutions. You need to be able to find something you can do that they can't (or won't).

There are various ways of implementing a competitive solution to a problem. Sometimes the first person to think of an idea becomes known, and the first-mover advantage is enough to carry them in front of others who come later. But more importantly, it is important to implement a solution that is difficult for others to copy. Creating the solution is a topic for another day, but it does start with understanding other current solutions clearly in order to figure out what they are doing wrong so that you can suggest a better way.

Pomodoro

A pomodoro is a tomato in Italian. It's also a system for time management and maintaining focus in order to get work done, invented by Francesco Cirillo. The name refers to a tomato-shaped timer he used to keep himself on track.

The basic idea is that you can do just anything for a short period of time, even if it is difficult or unpleasant or if there is something that causes you to lose focus. You also want to make sure you don't get too deep into something that will suck you in all day and keep you from getting to other tasks that need to be done. In the agile project management world, we use a concept called timeboxing, which is where you set a certain amount of time for a meeting or a task, and you have to fill the box but not overflow the box. When the time is up, the meeting is over, and you all move onto the next meeting or task, rather than letting it bleed into the next hour and make everything else start late, cascading through your day's calendar to where you end up staying late or pushing it to tomorrow to get things done.

To put it another way, considering the traditional triple constraints in project management, of scope, time, and cost, we more or less ignore the cost factor a bit and really look at things as a tradeoff between scope and time. Either you work until a task is completed, no matter how much time it takes, or else you work for a certain amount of time no matter how much work was completed.

In the system, a pomodoro is a 25 minute block of time in which to complete work. You want to break up the work into chunks that you think can be reasonably done in that time. The longer you use the system, especially if you track what you get done, the better you get at estimating what you can do in that amount of time. If you get to the end of the 25 minute timer, and you're not done, that's okay. You stop anyway. Take a 5 minute break to go to the bathroom, listen to a song, do some jumping jacks, eat a sandwich, or whatever will allow you a little bit of release without getting sucked into something else time consuming. If you get done early, you keep working anyway until the full 25 minutes are up. It could be reporting on the work you completed, getting a head start on the next task, planning out your next day, or anything else that keeps you productive.

You repeat 4 pomodoros, at 25 minutes each, with 5 minute breaks in between them. After the fourth pomodoro, you take a half hour break. After that half hour, you do another block of 4 pomodoros. A pomodoro could be working on a report or spreadsheet, a meeting with a client or coworker, checking and responding to emails, doing professional development, or if a student doing something like reading a chapter, working through homework problems, watching some class lecture videos, taking a quiz, practicing an instrument, etc.

The key is to not break up the 25 minute pomodoro into anything smaller. If you get a call or text or someone popping into your office or anything else that seems urgent, push it back to your break if possible. If not possible, then the interrupted pomodoro doesn't count, and you reset the timer to 25 minutes when you are ready to start up again. Turn off notifications on your phone and close your email client to ensure you're only checking messages when the planned pomodoro calls for it or during a break.

By keeping focus in short bursts, they will add up to you getting more work done than if you let a constant stream of distractions get you off your groove, while still knowing you won't get burnt out since you do have a break coming up in just a few minutes.

Triple Constraints

Seth Godin got in on the action a bit, in making fun of Elon Musk's fancy new truck.

Regardless of what his choice to throw a ball at a window of his brand new truck says about his showmanship skills, the big technology development of the future is related to transportation. As well as mass transit works in places with high population density and a large number of tourists such as New York and San Francisco, most places don't have enough of either of those two items to make mass transit really work. This means self-driving cars will be the real growth area.

I was reading the following article...

https://www.technologyreview.com/s/613399/the-three-challenges-keeping-cars-from-being-fully-autonomous/

...and realized not too far into it that we were just talking about the triple constraints. The three big challenges are that they must be safe, usable, and affordable. They go on to discuss that you could make a vehicle so safe that it would be unusable, since it wouldn't drive very fast or be fuel efficient. This is similar to how the most secure computer is one that is not connected to the internet and with no keyboard or monitor.

But for a vehicle to be useful/usable, some safety constraints have to give way. If we push on both the usability and safety levers at the same time, the cost will be through the roof. Cheap and usable? Not safe. Cheap and safe? Not usable. Safe and usable? Not cheap.

Dual Specialties

Or is it duelling specialties?

Growth is good. Being stretched and challenged is good. But sometimes we can be pushed into something that is actually more of a shift than growth.

If someone is an excellent server at a restaurant - they make good money from tips, their customers are happy and ask for them by name, and the restaurant makes more money due to their upselling skills. So what's the best course of action? Promote them to managing the servers or to managing the entire restaurant? When do those skills translate to management and when are we taking someone out of a win-win-win situation and changing it to one where everyone loses?

If someone is a good programmer, does that automatically mean we should promote them to be a project manager or product manager as a reward? What if they don't like the new job, or worse yet, what if they are bad at it?

Is the best cellist in the orchestra a perfect fit to replace the conductor when they retire? Or did we just lose the best cellist in the orchestra and gain a mediocre conductor?

Is a faculty member who is a good researcher by default also a good teacher? Should we promote the best teacher to department head or dean in the name of personal growth?

Managing people, operations, and projects well is a skill. It is its own specialty. You don't have to be a good programmer to specialize in managing programmers or a good cellist to be able to conduct cellists. A project manager may focus on a certain industry, but at the end of the day a good PM should be able to manage any project.

The biggest issue it seems with most "good" managers is that when they see people under them who are good at what they do, they want to promote them to be a manager just like them. It's time to flip the conventional wisdom on its head and start rewarding people for being good at what they do and helping them achieve true growth in their lane rather than convincing them that it is a reward to shift into a completely different lane.

Know what you're talking about

It's kind of amazing how we have so much information at our fingertips, yet rarely take advantage of that information. Due to systems that fix spelling errors pretty well, we often type something in sort of like what we wanted and assume it will be fixed.

I like to know what acronyms stand for and what technical terms mean before I use them. For example, I work with Gantt charts regularly. I am amazed how often people who should know better use all sorts of alternate names for the chart.

I hear Gnatt regularly. Like the insect. I see it written as GANTT, as if it were an acronym. There are a lot of acronyms in project management (PERT, RACI, PMI, BCWP, WBS), but it isn't Graphical Analysis of Numerical Task Timelines. It also isn't gantt. It's a last name. The chart was invented by Henry Gantt (or least that's who got credit for it).

You get into sketchy territory with some names, such as the Apgar test used to check newborn health and improvement within the first few minutes of birth. It is a 10 point scale, with 5 characteristics, which can be given a 0, 1, or 2. It was created by Virginia Apgar, a doctor in the 1950s. She came up with the 5 items, which were later given the eponymous backronym of Appearance, Pulse, Grimace, Activity, and Respiration (APGAR). How awesome is it that it is her name but also a mnemonic to help remember the points? Isn't it good to take a few minutes and learn where it came from before you use it? I was working with a group of nurses on a curriculum development project several years ago, and we were all surprised by the origin of the acronym. I feel like the nurses shouldn't have been.

I think Henry Gantt would agree.

First Meeting for the First Lego League

About two months ago, my kids' elementary school was holding a meeting for parents interested in help out with Science, Technology, Engineering, and Math (STEM) initiatives at the school. The principal's vision is to earn a STEM designation for the school, which opens up opportunities for a variety of grants and programs. I couldn't make it to the meeting but told them I was willing to help however I could.

About a month ago, I had a meeting with the principal, where we talked about some of the things they need help with, such as the science fair, Odyssey of the Mind, a STEM night for families and students at the school, and a STEM committee that would be in charge of paperwork regarding the STEM designation. Some of those things needed more help than others, but the one we ended up really chasing down was the idea of a First Lego League robotics team. The school also has some VEX robots from a robotics club that was running a couple years ago, but we decided to start with Lego.

This seemed like a great idea, so the principal sent out a request to see what students would be interested in participating, as well as if there were other parents who would be willing to help coach. There was enough interest to create three teams! Another dad and I are two of the coaches, plus they made a team of students in the After School Club (ASC), which is run by college students, so one of those students will be their coach.

We had a parents night last week, where we talked about the program, answered questions, and I did a quick demo of a robot I built to show the kinds of things they can do. The principal split up the team assignments, and we are ready to go.

So yesterday after school was our first session. I brought my robot that I built, which at some point will be disassembled, because the kids have to do all the work, plus I don't know what our robot will need to look like yet to perform the various tasks in the challenge. But it's good to have something basic to show off how it works. The ASC team is assembling the challenge kit, since they're there every day anyway. The other teams are only there once a week.

I figured we would start with a little Forming, so prepared a few activities designed to get to know everyone - start learning names and personalities. I brought the robot but didn't do much more than show the basic demo of it driving and moving a block around ... and put it away several times as every time I turned around, someone would get it out again. They're excited, which is good.

The first thing I had them do was write their names on the white board and draw a picture of something that represented them, then get up and explain to us what they drew and why. One kid would only write his name really small down in the corner and another wouldn't draw a picture for some reason, but overall that worked well. I drew a mountain bike for my picture.

Then we tried doing the human knot. Did I mention these are nine and ten year old boys? Let's just say it didn't work. There was pushing and pulling and trampling and crying. You know the drill. So we sat back at our conference table and started talking about rules. I had three that I had come up with and asked for their feedback on mine and if they had some they wanted to add:

• Be positive
• Everything is a learning experience
• Everyone has something to offer

They came up with a variety of rules, such as no throwing people out the window and no creating a robot atomic bomb. I pointed out that those probably fit within the existing rules, since if someone was tossed out the window, they wouldn't be able to share what they had to offer, and an atomic bomb isn't positive. We talked a little about what we could learn from the failed human knot. The boys came up with an additional rule that seemed simple but will take some work:

• Focus

 I'll try to refine those a little more so there's a short/catchy version of each rule with maybe an interesting acronym (better than BEEF), plus a more full, descriptive version of each. But I want to keep it simple.

The last thing we did was an activity to start thinking about programming logic. I put some chairs in one corner of the room, making a basket to try to drop a basketball into. One of the boys was the robot, blindfolded at the opposite corner of the room, with several table and chairs to work around. Three of the boys were designated as the programmers, who were to give instructions to the robot. Three of the boys were designated as programmer judges. Their job was to rate how good of a job the programmers did at giving clear directions. The other three were designated as robot judges. Their job was to rate how well the robot did at following directions.

There was a clear lane around the outside of the room, but the programmers decided to send him through the minefield in the middle of the room, including having him climb over a table at one point. When it was time to put the ball in the basket, rather than having him place or drop it in, they had him throw it. The robot missed.

We talked about some situations where they gave unclear or incorrect directions, like telling the robot to turn 15 degrees, without saying in which direction and which should have actually been 90 degrees. They told him to walk forward a certain number of steps instead of just saying to walk forward until he bumped into something. When the programmers told him to climb over the table, he was blindfolded so didn't know where the table was. It took three minutes, and the ball didn't go where it was supposed to. But we learned some things.

We wrapped up talking about how it was probably difficult to remember everything they observed while the activity was happening in order to talk about it later, so they needed notebooks to write down what was happening along the way. Their homework is to get a notebook to bring next time so they can keep notes on what they do and how well it works. The other assignment is to bring a couple of ideas for a team name. I told them that while they got to make the suggestions and vote on what they liked, I reserved the right to veto any name I didn't like, so it needed to be an awesome name. "Wait, so we can't name ourselves Team Underpants?" If you have to ask, it's probably not going to happen.

Simplified, but not too simple

In a couple of classes, we teach a basic project management concept - the Work Breakdown Structure. It's an outline of the tasks that need to be performed, with related tasks grouped into phases. It can get complicated, depending on how many levels deep you want to create your outline, but once you can go two levels deep, you can go further if you choose.

A student was for some reason offended that as part of the discussion of the WBS, my colleague used a simple example of making a peanut butter sandwich. For the case study the students complete as part of the course, it's much more complex than that, obviously. But before being able to apply the concept of the WBS to an advanced situation, you start with applying it to a basic situation. It's a common technique that many of us use. You take a very simple task that many of us do all the time, such as making a sandwich and break it down so that you can focus attention on what matters - in this case, the WBS. I will sometimes do an example with cooking a steak and making a salad. Nothing big and fancy, but people understand the basics of cooking and realize that you want to time things right so that both parts of the meal are ready at the same time. Even people who can't cook understand the annoyance when the waiter at a restaurant brings some people their food but some of the plates aren't ready yet. I usually let the students choose what example they want to use.

Instead of splitting their attention between two topics - the WBS and programming an ERP system (or doing construction on a skyscraper or whatever other more complex example you might want to come up with), you just focus on the WBS. If someone doesn't know what an ERP system is, you wouldn't want to spend a lot of time dealing with that when you should be focusing on the topic at hand.

The funny thing about making a sandwich is that it's simple on purpose, but when you're done with breaking it down, you realize it's not as simple as it seems (although maybe this student didn't catch this point). The idea is you take something everyone knows and you help them break it down to a level of detail that goes a little beyond what they normally would write in order to establish what assumptions they may be making without realizing it. This transfers to other more complex projects very well.

Get out a piece of bread, but what if you're out of bread? Are you baking your own bread, too? You have to start with a build vs. buy analysis first to compare the quality of and time to bake the homemade bread to your options to get to the store and buy some.

Is the bread already sliced? How thick?

Put the end of the knife in the jar of peanut butter, oh, but did you open the jar first?

Are the stakeholders expecting bananas, sprinkles, toasted bread, seedless jam? Anyone who has made a sandwich for a toddler knows the struggle.

If you have an example that is too complicated, then the students can get distracted by something that is too hard and they don't understand the example well enough to be able to challenge assumptions and pick out what might be missing. Using a simple example lets them focus on the concepts being taught and how to break down the work instead of on trying to figure out the example itself.

Career Day at the Middle School

My sixth grader, Landon, had a career day in one of his classes recently. He could either interview someone about their job and write up a report about it or a certain number of people could invite someone to discuss their career in the classroom. He opted for inviting me to talk instead of him having to write a report. Smart. The following are my notes that I prepared. The asterisks are where I was asking a question and would throw out a piece of candy to anyone who would answer. Two or three kids raised their hand for my first question. As soon as they saw the candy flying across the room, 90% of the kids raised their hand for every question.

How many of you know what you want to be doing 20 years from now? What? *

How many don't know?

That's okay. About 20 years ago, I remember a professor telling me that many of us would have jobs doing things in 20 years that didn't exist at that time. How awesome is that to know that some of you will be doing things that don't exist today?

20 years ago I did have an email address, but most people I knew who weren't university students didn't. At the time, only a few people had cell phones. If I needed my parents to come pick me up from somewhere, how do you think I let them know? * I'd use a payphone, and if you didn't have a few coins to put in to make the call you called collect which meant that the person you were calling would agree to pay a ridiculous amount of money to accept your call, and it would record your name, and then ask the person if they were willing to take the call. So if you were a fast talker you could just say something like comegetmefromschool, and then it would call and your mom would hear "Will you accept a collect call from 'comegetmefromschool'" and then she would hang up and come get you. That was the old school method of voice texting. You all think that's so new, but it's been around for a while.

So now I work for WGU. Anyone want to guess what that stands for? * Western Governors University. I teach college courses in business, technology, and project management. The school is completely online, and it did not exist 20 years ago. I have students all over the country and even in some other countries. I work from my office in my basement. Are you guys pretty busy outside of school? Do you ever have things that keep you from getting your homework done or that you'd rather be doing instead of coming to class? What? * WGU was designed to help adults who are working full time to get their bachelor's or master's degrees on their own schedule. So instead of having to come to a class at a certain time, you just slip in your studying wherever you can on your lunch break, on the train, waiting to pick their kids up from soccer practice, or late at night after the kids go to bed.

In order to teach in college, I earned three degrees. If any of you want to follow in those footsteps, you probably have another 15 or 16 years of school ahead of you. I know some people who just did degree after degree straight through, but I stopped and worked for a while in between each, which I liked because it gave me some more real world perspective instead of only knowing what we talked about in the classroom. I worked for a manufacturing company that was spread across three different states, did quality assurance testing at a company that made videoconferencing equipment, managed the database of alumni and donors at USU, and then moved into teaching. One of my favorite jobs was doing quality testing. Why do you think that is? * Because I got to be creative and try to find ways to break things and tell other people to fix what I broke.

What are your favorite classes? Why? * One of the things I like to talk about when I teach is how the things we discuss can be used in real life. A fun thing to do is ask your teacher how you would use what they are teaching you in real life. They really like it.

One of the things I teach is project management. Who knows what project management is? * One concept is the difference between operations and projects. Logan High is a good example - from an operations perspective, they have people who teach classes, play sports, clean the bathrooms, and that kind of thing. Every year, the same thing. But what's been going on at Logan High these past couple years? * Construction. That is a temporary situation, which means it's a project. It has a beginning and end with a transformation taking place in between.

Because projects have limited resources and need to achieve a specific result, a project manager helps define what they call the triple constraints - money, schedule, and scope. If you increase or decrease any of those three, it affects the others. If you try to do something faster, what happens? * It probably costs more money. What if you increase what you are trying to do during the project? * It will probably take more money and time. And if you are running out of money, how do you deal with that? * You have to reduce what you expect to accomplish.

With limited resources, it's important to use those resources efficiently. Landon and I were cooking dinner on Sunday. We made biscuits and gravy. You should have him make some for you sometime. One of the things we made sure to do was manage our critical path. It took about 15 minutes for the meat and gravy to cook. It took about 5 minutes to mix up the biscuits and 20 minutes for them to bake. Overall, how long is that? * 15+5+20 = 40 minutes. Well, instead of doing the gravy first and then having it sit there for 20 minutes and get cold or burn, we made the biscuits first. Why? * So we mixed up the biscuits for 5 minutes and put them in the oven for 20 minutes. During those 20 minutes, we made the meat and gravy. We did the same amount of work, but by managing the schedule efficiently, we got dinner done in 25 minutes instead of 40 and everything was hot at the same time. Now imagine a 3 year project to rebuild Logan High School taking 2 years or 4 years because of good or bad management of the schedule. That's where having a good plan and a good project manager comes in. The PM takes a large project and breaks it up into small pieces, schedules all those pieces at the best possible times, and then helps the team stick to the plan until the project is over.

Parking Lot

I'm not one for having meetings just because there's supposed to be a meeting. There should be a purpose.

Now, that doesn't mean you want to overly plan every meeting. Sometimes you just need to get together as a group to talk, and you may not need an ultra-detailed agenda, because the point is to have some time to just see how everyone is doing.

But there are times where it's important to stick to working through specific problems and close out lingering issues. How do we know what type of meeting we're headed into? Well, we have an agenda.

Ideally, the agenda is sent out in advance, so everyone can prepare for it. This is important for the introverts, so they can think of what to say in advance and for the extroverts to have a chance to get past their knee-jerk reactions and filter themselves a little to what is most relevant to the discussion. Otherwise, the extroverts process out loud, while the introverts process silently, and by the time the introverts have decided what to say, the discussion has already taken place and we're on to the next topic.

In addition to publishing the agenda in advance, an important tool for facilitating discussion is called the parking lot. For those who have coworkers who like to hijack the agenda and take the meeting in a direction other than what we planned, the parking lot allows the meeting facilitator to acknowledge that there is further discussion that may need to happen on a different topic, while still keeping us on the published agenda topic.

The idea is that discussion circles around a given agenda item, and when someone mentions something that is off topic, no matter how important it may or may not be, the facilitator acknowledges the comment, thanks the commenter for it, and then either asks permission to place the comment/topic in the parking lot or just simply states that they are going to put it in the parking lot. Then, the important part, is that with a bit of a flourish, the facilitator writes it down. This can be on a white board up in front of the room or just on a piece of paper on the conference table or even a note window in a virtual meeting.

By acknowledging the off topic comment both verbally and in writing, there are two results. The first is that it is made clear that the agenda will not be hijacked and that particular line of conversation is over for the moment. The second is that it is made clear that you care about everyone's needs. Maybe that item will be on the agenda for next week's meeting. Maybe it will be taken care of in a one on one with just that person later. Maybe there will be a few minutes at the end of the planned discussion to circle back to it. Because it is written down, it won't be forgotten.

Risk TO a Project vs Risk OF a Project

In discussing project risk, particularly the difference between the initial risks that are documented before the project begins and the risks based on events that occur while carrying out the project, an interesting point is often raised. Risks can be anything that have a chance to slow us down, make us spend more money, or cause us to turn out a product that is either poor quality or doesn't do everything it was supposed to do.

The point is a poor one, and it is that as a project manager, it's not my job to muddy the waters with risks OF completing the project in a way that could somehow damage the organization. My job, supposedly, is only to identify things that could keep the project from completing. If I can get done, I've succeeded. If someone else didn't take the time to scope things properly and do their research, then it's not my fault if the project causes the company to lose all their customers and close their doors.

That's great, but if the company has problems due to an ill-advised project that you knew about, should you not have at least mentioned it to someone? As I've said previously, you should be willing to take a stand and cancel a project if it truly will make you better off not to complete it. But it's a different situation if the project itself has just become too expensive compared to its benefits than if the project can finish as you've planned but doing so will cause the organization long term harm.

For example, we are seeing a lot of fast food restaurants, due to minimum wage laws, replacing traditional employee-facing POS machines rotate the screen to create customer-facing order machines. The machines are basically the same, with a few minor changes, just that they are now operated by the customer. Between self-checkout at the grocery store and the Coke machines with the touchscreen for choosing flavors, this has been coming for a long time. But the Coke machine offers a more customized experience since it includes flavor add-ons like cherry and vanilla that some restaurants don't offer. And customers have always had to take their food out of their cart and put it on the conveyor, so it's not much of a stretch to swipe it across the bar code reader instead and bag it how you like things bagged.

That's just an example, but let's say that the switch to a COM (customer ordering machine) instead of a POS (point of sale) machine is in full swing, and the techies that are working on setting things up for the new system hear several people complaining and stating that they won't eat at that restaurant anymore if they have to put in their own order. What do they do? Talk to the customers right then and there? Tell someone higher up that there may be a concern they hadn't recognized? Ignore it and go get a drink out of the fancy Coke machine (extra vanilla, please)?

The thing is, it really isn't their job to deal with the problem directly by confronting those customers right there. But ignoring it completely could mean sales drop and the restaurant folds and the techies lose their jobs along with everyone who works there. The key is to bring it up and add it to the risk register. Let it be passed up the line and assigned to someone to do some additional market research and analysis. Perhaps they continue on as they were planning. Perhaps they modify the system slightly to allow for customers to choose either a real person or to put in their own order on the COM. Or maybe they do something totally different. What they end up deciding to do doesn't really matter, as long as someone looks at the risk and rates it properly and determines the best action to take.

Ignoring it as a not-my-job problem isn't a good way to approach things. There's usually an awkward silence in the discussion when we get to that part of the conversation, and I tell a student that if they ignored something like that as a business problem, not their project problem, and it caused some damage to the company, that I would fire them. Whether or not I actually would doesn't matter, since it's a hypothetical situation anyway, but the point is that if every member of the project team isn't both doing their job on the project itself and also looking at things in the big picture, long term view, then we are going to have a problem.

Fixing the issue or making the decision about what should or shouldn't be done about it may be above project team members' pay grades, but identifying the risk and getting it up in the sight of those who can make those decisions does belong to everyone. It's not just your job as a project team member or manager to identify risks TO the project that could make the project itself fail. It's also your job to identify risks OF the project as currently scoped to the company and that could cause the company to fail. Especially since there's going to be a glut of job seekers on the market soon with all the POS systems replacing people for you to now compete against.

Communication Management

In any project you do, a big piece of the success of the project is communication. As such, a large portion of the role of project manager is, you guessed it, communication. Sometimes people get frustrated by what they see as overcommunication from the PM. Other times people feel a bit like they're floating out there on their own, unsure of how the things they are doing fit in with what everyone else is doing. The PM must find a way to balance these extremes, so everyone gets just what they need (including the project manager).

The key first step is to identify the project stakeholders and perform a stakeholder analysis. Now, the term stakeholder is a bit of a loaded one for many people. For some it is the executive stakeholders who are the customers for whom a system is being built or change is being implemented. Sure, they're stakeholders. But that's a fairly narrow view.

Back it up and think of everyone who has a stake in the successful outcome of a project. Think of anyone who could positively or negatively impact the project. Then think of anyone who could be positively or negatively impacted by the project. Sure, your executive stakeholders or customers are on the list, which probably your project sponsor and/or champion who will probably need more communication than some of the other executives. And, yes, the sponsor/champion needs to be an executive, as they need to have money and political clout to help get past any roadblocks.

This is where the first step of the stakeholder analysis comes in - the power/interest grid. You build a 2x2 matrix with Power on one axis and Interest on another. You could pick different items for your axes, but these two often will get you as far as you need to go. You sponsor should be high and right. Not enough power means they're not going to be able to help when times get tough. Not enough interest means they're not going to want to.

Other stakeholders, such as future users of the system may fit higher or lower on the power and interest, depending on what kind of project you're doing. Something that has a status quo that people want to maintain will result in high interest users trying to shut you down. If they're the users, they have relatively high power, as they can sabotage, refuse to help get the system going, or just not use the system after it goes live, even if they are not actually on the project team.

Still others will include people like the dude you always see in the breakroom and is trying to get into a position in your department and really wants to know what is going on, even though at this point the poor soul has nothing to actually offer you. Then you have managers in other departments that could shut you down if they wanted, but they care little if anything about what is going on in your project, so you try to keep away from those people as much as possible. If one of those high power / low interest executives finds out how much your project is costing and wants some of that funding for something in their department, watch out. So a big piece of what you want to watch for is considering what information is relevant to which people, so you can be sure everyone has everything they need and nothing they don't. Even the lowly users who don't have much say in what is going on may be upset if they knew how much the project is costing, but unless they're writing the check, that's not something you talk to them about.

Once you've thoroughly gone through who the various stakeholders are, what kinds of things they can offer you, how much they care about what is going on, the methods of communication that would be most effective for each, and the specific details each cares about, it's time to actually create the communication plan.

The plan itself will be based on the stakeholder analysis and three major phases - introducing the project, carrying out the project, and closure.

Project introduction will include things like gaining buy-in from everyone. Sometimes it's little more than a courtesy notification that the project is happening, particularly for low power players. You'd be surprised how often people are surprised by projects that have been started and people who thought they were a key stakeholder are completely left out of the loop. Let people know what is going on, how the project will affect them, and what help you will need from them. If they have high power over your project, something deeper like explaining the ROI or strategic purpose behind the project will be necessary.

As the project begins, you need to check in with people every so often. A person who won't see the system for 2 years until it's completely done and ready to launch and isn't working on the project will get annoyed if they are receiving weekly status reports. Don't CC the entire company on things. Don't throw information out to people that they don't need to know. Be thoughtful and consider both their time and the political fallout of making people angry at you.

Do make your plan specific. Lay out what information team leads and other team members need to report back to the project manager and how often. Then lay out what the project manager will collect and analyze and who that aggregated information will be sent out to. What format will it be in? What are they expected to do with it? Just read it if they choose or provide feedback and approvals? What items don't recur regularly but happen on either just a certain date or upon some event occurring. When there are change requests, there should be a plan for getting those communicated to people, even though you don't know when they are going to happen. You just know when they are approved, they need to be communicated quickly so the project team is working on the latest information.

And as the project comes to an end, there is information that needs to be communicated and gathered to close out the project. Often final versions of the recurring communications will be put together. Other information, such as lessons learned and team member performance may not be known until the project actually does end. Whether the project is successful or unsuccessful, there should be closure. In fact, one piece of closure is to communicate about the success (or not) of the project. There can be many lessons learned from a failed project, so don't forget to sit down and talk about how to make sure the same thing doesn't happen again in the future. If you don't document that you were going to compile the approvals of all the project deliverables at the completion of each project phase, you may not be able to go back and collect those all later, due to people either leaving the company, losing interest in the project, forgetting what they agreed to, changing their mind, or otherwise. So know what you'll be communicating at the end so you can be gathering that information throughout.

As you lay out the items you will be communicating to gain buy-in and start the project off on the right foot, the items you will be communicating on a recurring or scheduled basis throughout the project itself, and the items you will gather to provide closure to your stakeholders when the project wraps up, be sure that you refer back regularly to the stakeholder analysis. Don't spend a lot of time on people who have nothing to help you with or who don't care about what you're doing. Be sure you have a sponsor who isn't going to lose interest in you half way through.

Make certain you include everything from the stakeholder analysis in your communication plan; if you know someone cares about the project costs and the communication plan never has you sending them a report on how much is being spent, you're missing something. Possibly even more important, when you're sending information to people, refer to the communication plan and from there back to the stakeholder analysis, and don't send stuff to people they don't care about and don't need, as it will begin to burn any goodwill you have with people and make it politically difficult to work with those people in the future. Yes, this means that you need to check who's on the CC line of an email before you hit reply-all and coordinate most of the communication centrally.

Project Cancellation

I had an interesting discussion with a student recently regarding cancelling projects. In question was whether it is appropriate to cancel a failing project. The student's position was that a project should never be cancelled. The claim was that, at least at the large company where the student works, they could not afford to cancel a project once it started. If it is failing, then one would investigate the cause and make whatever changes are needed to get back on track.

Of course, you want to track things carefully to be sure any project is progressing as it should. If it gets into trouble, you do a risk assessment and change requests and whatever needs to be done to salvage it. But eventually, if it's actually failing, you cancel it. I think the disagreement came down to perhaps a difference in definition of "failing". If you have been through the process of analyzing what is going on and trying to fix it and it is still doomed for failure, then yes, it needs to be cancelled. If a couple things are just not going as planned, that doesn't mean failure; it means job security for good project managers.

There are many projects that are not cancelled even though they should be because of not much more than pride or attempting to save face. One of the most important concepts I learned about in my MBA program is that of sunk costs. That is, if you’ve already spent the money, it’s gone, sunk, finito. You don’t look back. What you already spent in the past is less important than what is going to happen moving forward. You look at how much it will cost to complete the project or change it or whatever moving forward, and the corresponding opportunity cost (which concept I learned about in undergrad economics), which is to look at whether there is something better you could be doing with that money (or time or any other resources involved) instead. This is sometimes referred to as a good-better-best comparison.

This not being willing to cut one's losses is where compulsive gamblers run into a similar issue, where they lose money and the more they lose the more they want to bet to try to win that money back. But it just digs the hole deeper instead of salvaging what remains in order to take the lessons learned and invest more wisely in the future.

Even better than straight up cancelling, however, is to build in several exit gates throughout the project so that upon completion of a phase, a planned review takes place, with the intent of determining whether the project should proceed. This is most common when the first phase is a feasibility study, but it can also be added after a prototype, pilot, or contract negotiation phase. Write up the criteria correctly, and you can find yourself successfully terminating a project by making the determination that a contract is not worth pursuing or that the pilot did not show the expected benefits. Then reallocate resources to something better.

Consistency vs Transformation

A project is a temporary endeavor. Its successful completion results in the creation of a new or improved product, service, process, or other result.

Being temporary means it should have a distinct beginning and end. In some project-based organizations, the temptation may be to drag the project on forever as a form of job security. The best job security, however, is being efficient at finishing projects and knowing your successful performance means you’ll always be reassigned once your current project is over.

Operations and processes just keep going on without a distinct beginning or end. An assembly line may be used to build a car from beginning to end, but as a whole, the assembly line is really a process that continually creates new cars over and over. If an inefficiency in the process is found, a project may be undertaken to overhaul the process, but once the new process is in place, it goes on with no planned end in sight.

Operations are important to the consistent functioning of a business. But don't underestimate the transformational power of a good project.

Managing the Critical Path

When planning a project, the temptation is always there to build in extra time everywhere so that your schedule never slips. Just like if you're putting in tile or carpet, you order 10% more than what you measure that you need in case something gets damaged or if you mis-measured. Time is the biggest resource you have on a project, and the most visible "failure" you can have is missing your launch date. So it makes sense that you would add 10% or some other fudge factor to all your estimates, right? Not so fast. If you have a time-sensitive launch, set the completion date well enough before you really need it, but don't just give everyone extra time to get everything done.

The critical path is the sequence of tasks that need to be completed on time for the project to complete on time. If you have slack built in between tasks early on in your project, then what you've done is made it so those tasks can be delayed without changing the completion date. By definition, if tasks can be delayed and not affect the project completion date, they are not critical. If you do something like this, you'll end up with a very short critical path, with just the last task or two showing in red, meaning the last couple have to be completed on time. That makes sense if you look at it logically. It may be logical and possible, but is it allowed? I'm not sure I can answer that question or even if I can that I want to. The better question than whether it's allowed is whether it's a good idea. And that, I can say emphatically, is not a good idea.

Anyone looking at your Gantt chart or network diagram will expect a critical path. There are many ways you can show that, and there are many possible ways to put together a project. You can have a completely sequential project, in which case only one task is being worked on at a time and everything is on the critical path. It's neither logical nor desired, except in the rarest of circumstances, to have every task be on the critical path. On the opposite side of the pendulum, it is neither logical nor desired to have only a couple tasks or even no tasks on the critical path. At its most basic level, the critical path is really just a calculation. It is what it is. You simply measure the lengths of the various paths and the longest one is critical. At a more strategic level, the critical path is key to your management of the project, as it is the series of tasks that you will be watching most closely for scheduling issues. If everything is critical, or if nothing is, then you have nowhere to focus your attention, and the project just kind of does whatever it wants. You can probably see how that might be a bad thing.

Building in slack between tasks, aka giving people extra time to finish their tasks, is not meaningful or helpful and if anything is damaging, because if you give them extra time, they will take it. If you give someone a 1 week task but give them 2 weeks to do it in, they will wait until the second week to start. The idea is probably so if they end up taking 6 days instead of 5, the schedule doesn't change. That's good in theory, but if they have a 1 week period to do their work and start week 1 and go one day over, they are just one day late. If they have two weeks and start week 2 and go one day over, they are now 6 days late. Even if they have 2 weeks and start at the beginning and finish in 5 days, there is a phantom 5 days that everyone else is going to be sitting around waiting. Why tell the next team they can't start work for 5 days when the previous work is done, just to maintain the schedule? If there are things that have to happen on a certain date, well you hard code those and work around it. But those are pretty rare. If you want to build in some slack, put that at the end. If management wants things done by the end of the year, you plan the project to complete, say, October 31. But the project due date is published as October 31. You don't tell everyone that the goal is Halloween but you don't care if it's not done until Christmas. Stick to Halloween. If it does go over by a week, we'll all survive. But the second you start telling people your "real" go-live date, that's the date everyone will be aiming for and before you know it, New Years' comes and goes and everyone is still trying to wrap up loose ends that should have been done 2 months prior.