Do you remember playing Hot Potatoes as a kid? The object of the game is not to get caught with the Hot Potato in your hand when the music stops.
Everyone gathers in a circle and a small ball or bean bag is given to one of the kids. This is the Hot Potato.
The music starts and the kids starting tossing the hot potato to each other. They need to get it out of their hands as quickly as possible because they do not want to be caught with the hot potato in their hands when the music stops.
The pace is frantic. They can’t get this hot potato out of their hands fast enough! They barely touch the ball for a microsecond before they pass it on to the next player. The last thing they want to happen to them is to have the music stop and be the one with the ball left in their hand!
Because, if they are caught with the ball in their hand when the music stops…they are out! That’s right. They are unceremoniously kicked out and they have to watch everyone else play for the duration of the game. Good times!
Do you play hot potato in your company? More specifically, does your Development Team play hot potato with the application, report or code they just finished developing?
Here’s the scenario. Most mid-size to large companies are set up with a development team that is responsible for creating the initial application, report or other software. Once it is complete, it is then handed off to another team of people. This group is typically called Production Support. These are the people that are responsible for the care, maintenance, and support of what the development team just completed.
What typically happens is that there is a premature hand-off between Development to Production Support. The bits have barely congealed into bytes and Development is tossing their work over the fence as fast as they can. They can’t wait to get this hot potato out of their hands and into someone else’s.
Nobody wants to get caught with this hot potato in their hands despite what the project scheduling software says.
Why Does Development Play Hot Potato?
There are a couple of things that must be understood as to why some development teams like to play this game. The nature of the two teams is very different. For example:
The Development Team
The development team is tasked with working on all the new, cool, and exciting stuff. This is the team that is involved in the groundbreaking technology and figuring out terribly complex problems. They provide initial input into the project scheduling software for planning purposes and then get on with their work at hand.
There is usually a central core of people on the team that is considered the untouchables. They have been with the company for a long time and know the ins and outs of all the applications in the company. Their expertise is frequently called upon to figure out thorny technical problems that clients may be bringing to the table. They are incredibly busy people that are pulled in multiple directions at the same time.
The Production Support Team
The life of the production support team is not quite as elegant or exciting. They are tasked with support of the old legacy applications of the company. They have been relegated to work on the old, busted, and broken stuff.
They may be an offshoot or extension of the Call Center since their job is to help support the applications that have already moved into Production. They are on the front line when it comes to troubleshooting and fixing problems.
This team is not untouchable. It’s not that they aren’t good at what they do. It’s just that they are probably newer with the company and don’t have the depth of knowledge and understanding of how everything works together, yet. They may fly under the radar for a period of time… and people on the team may not even know what they do.
So, what happens is that the split-second a project is complete in the project scheduling software, it is thrown over from Development to Production Support. Development has other new and exciting things to work on and this particular project is no longer that interesting. They are done with it, despite the fact that there may still be some problems that were not caught in QA. They’re someone else’s problems now! Namely, production support.
The moment the application or report is released to the wild, it has a problem… For example, a customer calls in and says that when this button is pushed, it doesn’t do anything. (Remember, this has only been turned over to production support in the last 5 minutes.).
Production Support tries to get the help of the Development team. They are greeted with…”nope, that’s not our problem anymore!” They’ve already moved onto a new plan in the project scheduling software!
This puts the production support team in a tough spot as they try and figure out what is broken (with code that is brand new to them) while the development team is off on something new.
How to Beat the Game
There are a few things you can do as a project manager with scheduling software to win at the game of hot potato:
- Have a Clear Definition of Complete: A challenge that many IT shops face is an understanding of the word “complete”. Some developers may say something is complete, even though it hasn’t even been tested yet.“Yeah, my part is done”, says the developer.
“Does it work?” asks the project manager.
“Not sure”, replies the developer.
Well, then, according to any project scheduling software out there, this task is not done and can’t be moved over to production support. Make sure everyone understands what “done” or “complete” means in the context of your organization. Until something is truly complete it is still the responsibility of the team that is working on it.
- Address Your Concern Up Front: Address the concern up front with the team about how some in the past have liked to play this game of hot potato and throw something over the fence as quickly as possible.You could phrase it along the lines of “In the past, I’ve worked with teams that like to throw their code over the fence as quickly as possible and then never have anything to do with it again. Now, I’m sure that’s not the way it’s done here, but I just want to remind everyone that you need to make sure everything works prior to moving its production”.
- Lay the Ground Rules: In addition to addressing your concerns up front with the team, you can set certain ground rules around the scheduling software…For example, you could include a window of 30-60 bug-free days on the application before the development team can fully disengage from the current project. This will give them an incentive to do their best work up front and be mindful of where they fit into the project scheduling software plan.
Hot potato was a fun game to play as a kid. It’s not quite as fun to play as a project manager who is tasked with making sure the project in the scheduling software is running smoothly. Work closely with both teams to understand if this is an issue within your company, and then implement the steps above to resolve the issue.