December 19, 2016
This is part two of a multi-part series on how teams are organized and how they work together within a set of conventions and constraints. This post describes an organization that creates products and offerings with members that work simultaneously on multiple projects. A well-defined process, not very different from a traditional systems development life cycle (SDLC), guides this federated team.
About the Team
It’s useful to call the team a federation because each member works for a different department and are placed together, in a virtual team, to make a unit for the life of the IT project. The people on the virtual team aren’t dedicated to the effort and split their time over multiple projects and other activities.
The team has members from finance, contracts, legal, marketing, delivery and architecture led by offering management with the help of a project manager. The purpose of the team was to take a previously identified product or service through the steps necessary to further define and design it and take it through to launch into the marketplace. Each team member has a specialization (e.g., the finance team member is responsible to lead the creation of a business case and the contracts team member is responsible for the statement of work).
Management is involved in voting to continue or stop the project as it completes each phase of the SDLC.
What Worked Well
Having team members with specialized skills is definitely useful because some domains like legal and contracts are often too complex for the non-specialist. These team members typically create tools in the form of templates and forms that transferred the necessary information to the team leader while providing a way to gather the necessary project data.
When projects went well and products were successful, team members would have a chance to meet each other at recognition events or annual kickoff meetings for the new year. This was a chance to celebrate as well as to bond with team members and create relationships that serve the company well in future projects.
What Didn’t Work So Well
Virtual teams get the job done but possibly never meeting the people you work with can create a challenge in building a well functioning team. Virtual teams communicate through email and conference calls and, unless the calls are well managed, there can be some participants who are multi-tasking and not fully participating. Recent innovations make it possible to see and hear participants and this has improved team involvement during the calls.
Since team member are working on multiple projects, finding time to perform project work (versus reporting status) can be a challenge for some members. For this reason, many status calls are dominated by project work and not status, which may not be the best use of time for many people on a status call.
It was cost effective to create virtual teams. The teams were strong due to the specific expertise of the specialized team members. When the project leadership made firm rules and worked behind the scenes to facilitate the necessary project work, projects moved along at a good pace.
When the project leadership strove to innovate and take risks, management often responded with encouragement and on occasion, some projects became enormously successful. The successful projects were a combination of effective people working out a good idea at the right time. An example of this is managed hosting when many companies were using suppliers to host and run their websites. Cloud computing is another example of a service that has been brought into the market with great success by a number of project teams.
In the next post, I will describe a team that creates software with members that work on multiple line items on the same projects within a fixed time period. I call this a group in a box unified by a schedule.
Posted December 19, 2016 | Permalink