Most project management methodologies start with the formation of the project team and the assignment of roles and responsibilities. Unfortunately, some projects don't start with "step one"; for one reason or another, the team is assembled sporadically during the first few weeks of the project, and the manager doesn't go back to fill in the missing pieces. Short deadlines, slim budgets, and high expectations all contribute to the "roll up your sleeves and get started" approach. I have even seen some projects that were so focused on "delivering something", that they failed to define and communicate the fundamental value propositions!
Using an iterative development methodology can cause additional problems with team formation, as the composition of the team changes periodically. At a minimum, you will likely have a new Project Owner or Executive Sponsor with each iteration.
So, at every step along the way, you should publish a matrix that defines the team, including the roles, responsibilities, and contact information. I've found it very convenient to communicate the roster via the project's web pages, where meeting minutes, status reports, project plans, and critical documents should also be stored. (You do have a project web page, don't you?) Some of the roles that you may want to communicate are Executive Sponsor, Project Manager, Project Owner, Project Champion, Product Manager, User Representative(s), Technical Contributors, and Interested Parties.
One last tip: make sure the people who have the roles can fulfill the responsibilities. An Executive Sponsor with no political clout is worse than none at all, a Project Champion with no enthusiasm will drag down the rest of the team, and a Product Designer without the necessary experience will put the project at technical risk.
Got the team?
For more information, check out searchCRM's Best Web Links on Business Intelligence and Data Analysis.
This was first published in February 2002