Teams within an IT department
8th Jul. 2003
Whenever I finish a project (certainly large ones) I usually spend some time analysing my own failures and successes, and any problems I may have encountered within the team I might be working with. In the past we would take this personal analysis and share it within the team in the hope that the next project could improve upon the last.
Having just finished a rather long agonizing project I have been going through this same process, albeit unfortunately alone.
One of the things I have been doing is reviewing some basic literature about IT teams. They don't directly relate to the type of people I work with on a day to day basis but they provide some interesting fundamental lessons.
"The team needs a dedicated project room to conduct all meetings and display all project artifacts. The room should have several large whiteboards and be equipped with a high quality conference phone. It must be dedicated for the duration of the project, including its retrospective. The room should openly display any artifact that is needed by the team. Over the years I’ve worked in project rooms that displayed such things as: project plans, system/architectural diagrams, risk lists, questions that are as yet unanswered by the dedicated customer, vacation schedules, storyboards of the user interface, database schemas"
This is one idea that seems so important to me on many levels. If nothing else it is an excellent method of allowing people outside of the team to quickly see the progress and scope of the project. Hiding progress behind a screen is not conductive to keeping seniour management abreast of the amount of work you have completed. So much work is kept hidden from the people who help allocate project budgets, that it is hard to adocate richer budgets and rewards (if their are such things as rewards).
"Why Teams Fail
Does getting to your objective necessarily mean that you have an effective team? Not necessarily.
A failed team may well have completed its deliverables and met its schedule, but the organization may fail to make meaningful use of its contributions. Poor management support and weak leadership are the most frequent drivers of team failure. Other reasons teams fail include limiting the focus to tasks while ignoring the interpersonal relationships, team members who do not take responsibility for themselves, inadequate resources to get the job done and an inadequate reward system.
How Do You Know You’ve Got a Team?
Building a well-functioning team can be a lot of work. What are the payoffs, and how do you know you’ve gotten there? When teams can work out conflict among themselves, when the team members understand their roles and shift responsibilities as needed, when team goals are just as important as individual goals—that’s the payoff."
Link: Managing Small Team Web Development
Link: Building an Effective IT Team Step-by-Step
Categorized: Work and Working , Teams
Search
Recent entries
- Explaining Information Architecture
- Prototyping the Julian Scarf
- Making of the Computer Graphics for Star Wars (Episode IV)
- Experibass
- Reac Table
- John Cage about silence
- The Fragmented Orchestra
- Voltage
Old articles
- Escaping Flatland: Towards Better Documentation for Information Architects (Eng./Chinese)
- Audio Interfaces for Online Environments
- Mental Models for Producers
- User Experience for Producers
- Information Design: An Introduction
- Visual Design for the Web
- Creating the User Experience
- Digital Story Telling
- Introduction to UX: Foundations, Navigation& Information Design, Information & Visual Design
