True, nonetheless people are put to postion of taking care of the “commanding officer” whom is on his break every and each moment. One must take consiquenses in their hands to keep moving things forward and solving issues, the problem arises when the careless captain cares to share attention to the matters at hand. He does not know where he stands nor where the project goes, but due to keep his authority he makes a choise of action due to keep his authority regardless of any knowledge to one way nor another. Now, with that sort of management we have a shitload of problems, not only that the idiot is not following nor aware of the guidelines but yet stupid enough to make a blind move…because his creative in his own mind and thus ****s up even the last saving plan that was made on his leave for….scrathing his (bottom), I’v seen this happen IRL and it’s truely sad and even moreso hard and difficult for everyone else in the project. Then again It’s the corporate way and if you dare to critisize, you are ’bout to be fired…punk!

I’ll put a cap on mi bottle’o rants, once again :D

Agile methods (like those daily “meetings”) are fine, but not always possible in (virtual) indie teams where timezones might have 8-10 hour differences.

The problem here is that people get easily lost in a monolithic project if they aren’t required to frequently show the progress they’ve made. Usually it’s a case of overwhelming or uncertainty of the priorities. Other times, it’s laziness or the inability for certain individuals to work as a team.

So far, the best method I’ve seen and used is called the “agile” method, which forces progress visibility very frequently in the form of many releaseable milestones (complete with show and tell so the project team can have a feeling of accomplishment) and daily 10-minute dashboard meetings to see what’s being worked on, and what was accomplished up to the point of the meeting. When needed, road blocks are identified, and those that are “struggling” to get their part accomplished will get attention very quickly.

The purpose here is to give the team co-ownership of the project and make them accountable to their other team-mates rather than some authority figure (though that figure is present and does have final say). The frequent milestones also forces the project manager to adjust delivery times (either later or earlier) and have good rationale to do so when inevitably questioned as to why something is running late or will release early.

The problem the author described in this blog is that project managers frequently believe that their sole role is a supervisory one. Defining priorities is the key job of the project manager. They need to manage the project, not the people. In fact, it usually works out the best when the PM is a peer within the group rather than an axe-wielding authority figure. The PM’s responsibility is delivering a product, and supporting or mentoring the team when needed, not babysitting employees.

Threats and nagging do little to motivate anyone, and if anything fuel the disdain and quality of the project will suffer.

However, if team members are held accountable by their peers, they will be far less tempted to get lost in the machine, and those that aren’t team players will quickly find themselves alone. So alone that their termination will do little harm to the morale of the rest of the team.