Wednesday, June 8, 2016

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.