Creating Working Groups: planning and structure?

Can one identify the need for various working groups within a development environment and organize them prior to needing a solution?

It would be nice to create a large-scale IS development team and anticipate and create the working groups in advance and build them into the process. Is the very nature of working groups an ad hoc response to an unanticipated problem and meant to have a limited lifespan?

What are some working groups that you have participated in?

Ideally, I would like to post a framework of general review boards and working groups that are needed within an engineering effort.

One driver to set up this structure in advance is to ensure a successful network of coordinated standards and engineering throughout the projects within a large Program Executive Office (PEO). The article from the Software Technology Support Center journal CrossTalk describes the desire to have a well-coordinated development team and the challenge of synchronizing such inputs and resolutions when it is impossible to have everyone in every meeting.

I was fortunate to experience an efficient development effort. Using an IPPD (Integrated Product and Process Development) and IPT (Integrated Product Teams), a representative attended the daily readiness meeting from each discipline. Rules were presented in advance and posted at the meeting location and included the following:

• meeting will start at 3:05 sharp daily



• we will stand up (thinking on our feet seems to speed up the meeting and keep it moving forward)



• the meeting will end promptly at 3:20



• communication will be hub and spoke



• spokes will take notes and communicate minutes to their respective disciplines



• be direct (not vague, there is no time for ambiguous statements)

This meeting was an efficient status of daily activities and a defined communication network to prevent redundancy or lacking coordination. The early afternoon 'huddle' was quick and sharp and everyone came with a pen and paper. Problems were redirected to a team that usually had the remainder of the evening to resolve the issue.

As it turns out, our meeting was using the efficient team size and the concept of nodes (Role Managers) to create a successful communication network as described by Dr. Nichols.

The DAU says that IPPDs are recognized as the "best practice" by the DoD and IPTs are a key component. Management of any project can be improved when people communicate
effectively, identify problems early and work as a team. A recognized industry
technique for facilitating such results is called IPPD.

The ground rules for implementing IPTs are:
􀁺 Open discussion with no secrets
􀁺 Qualified, empowered team members
􀁺 Consistent, success-oriented, proactive participation
􀁺 Continuous "up-the-line" communication
􀁺 Reasoned disagreement
􀁺 Issues raised and resolved early

A team of 8 will establish 28 communication channels: [= [N x (N-1)] /2]