Comment:     by Andrew Emison 10/12/2004 Another way of avoiding the "95% complete" dodge is to ask the question "How much longer will it take to complete the task" instead. This avoids variables such as a project team tackling the easiest components first and encourages a forward view on the remaining task, including module integration.
	Comment:     by Vishal Mahajan 9/23/2004 I have seen the chicken games start when: 1. Messenger coming with bad news gets killed. First time this happens, it discourages the subsequent ones. 2. There are egos at play in the teams or some people are more favored than the others by the managers / managements. 3. You have estimated a deadline (which gets agreed) and are subsequently asked to trim it.
	Comment:     by Hemant Joshi 9/22/2004 I have observed that if boss is gaining respect by the employees just becoz he has appraisal in his hands and not becoz of his knowledge and excellent management skills, then it is very obvious that this Chicken Game takes place. If the boss is easily approacheable to its dept. colleagues then no wrong is hidden and this chicken game doesnt take place.
	Comment:     by Anko Tijman 9/22/2004 Recently my PM asked me what the progress on the testing side was. I started singing "It's sad, so sad, it's a sad sad situation. And it's getting more and more absurd" from Elton John's "Sorry seems to be the hardest word". And that is exactly what this article is about! I've always been straightforward to my PM - he has to decide what action to take or what (political) message to tell. Only once a PM thought I was playing a game and cut my budget with 15%. I told him that if he wants me NOT to be straightforward, he can get what he wants and I will play the game along by raising every budget with 20-25%. So that he couldn't fool me again.Read On
	Comment:     by John Daughety 9/21/2004 My success in larger companies was determined in large part to my ability to "manage the chicken game." Actually this was true in all departments, as I recall - many times I would be given a deadline that I knew was impossible, but I would agree and move on, knowing that another part of the process would implode before my deadline came. In 12 years with large companies, I can safely say that I never delivered anything late - wait, did I ever deliver anything?
	Comment:     by Darryl Hurmi 9/21/2004 I have worked on all kinds of projects with a wide variety of team compositions, but what is most obvious is the ones that succeeded were the ones were the deveopment team was a TEAM. If people are playing the blame game they are not a team but just a collection of individuals on the same project. A good team has the goal in mind and if they see a problem that might cause problems for another of the team members they communicate that early to the effected person and that person recieves that information with gratitude that the problem was identified early. If a team member has a problem other members of the team who are ahead of schedule...Read On Author's Response: 9/21/2004     I can't agree more that egos can often get in the way of finding a common solution to a problem. The solution is "gentle pressure, relentlessly applied". Every time one of the egos gets out of line, it is the responsibility of the team leader to point out to the offender how they have strayed and what the impact is to the project and the company. It is also crucial that any malefactor be made to correct any problems of their own devising. Eventually, you wear them down and that start doing things the right way...
	Comment:     by Mark Chweh 9/21/2004 Something relevent to this is the lack of realistic estimates in the planning process. This can be cultural ("It has to be done FAST!") or because of skill defecits in technical estimators("I dunno how long.. maybe a couple of days?"). In either case, careful examination of estimates and their adjustment to "real timeframes" should be done with both Management AND Technical contributors DURING planning. If you don't teach the stake holders and the producers how to do it right, you just get more of the same! Author's Response: 9/21/2004     I agree that poor budget and schedule estimation is the original sin of most projects. When the team realizes that they have insufficient budget or insufficient calendar to complete implementation, it is their responsibility to inform management. Benchmark data from similar projects can be very useful in convincing others that you have a problem. It is important that you come to them with an alternative ("I can take longer and give you everything you want; I can take as long as you want and deliver less functionality") rather than just passing along the bad news. If you just give bad news, management will likely feel that you are just a bunch of whiners who won't take ownership of your project. Management needs to understand that when the budget and schedule are both insufficient and fixed, the most likely result is poor quality software.
	Comment:     by Gene Fellner 9/20/2004 One of the many things I like about my current (and hopefully final) employer is the long-running and largely successful effort to drive the Schedule Chicken to extinction. Our CIO has a rule that he enforces rigorously: I will never punish you for giving me bad news, but I will unfailingly punish you for NOT giving me bad news. The rule works because he enforces it on himself and is true to his word. The buck has to START somewhere! Author's Response: 9/21/2004     The SNAFU Principle - communication degrades the more levels it goes in a hierarchy. News is like a fine wine - it doesn't travel very well. This is why it is important to talk directly to the people on the sharp end as often as possible, particularly if you are managing a portfolio of projects. It is too easy for a "nuanced" project status report to obscure what is really going on. However, when a manager talks to a worker, they MUST be sensitive to the worker's feeling of safety. People will "shade" their reports in direct proportion to the amount that they will feel blamed for the bad news. A short story - HBO did a series on the Apollo project. In it, they tell the story of the creation of the lunar module. During a test, the landing gear collapsed. One of the engineers went to the project director and told him that he had reviewed his calculations, and found a mistake that resulted in the problem. The director told the worker to go home - to get some sleep. He told the worker that he didn't hide the problem and that he brought it to the director's attention as soon as he found it. He finished by saying something to the effect that the only way they were going to get to the moon is if everybody told the truth about what was going on. If there was one story I would tell to every new manager, it would be this one...

Back to Top