Core Team/Extended Team Approach to Projects
The management at my company is taking a Core Team approach to project planning. Essentially, a core team is identified for each "commissioned" project. Usually composed of a Project Sponsor, Project Lead, Technical Lead, QA Lead and Support/Operations Lead. Regular core team meetings are held and it's the core team member's responsibility to communicate project status updates to the Extended Team members (developers, qa engineers, support engineers, etc.).
Just curious if there are any negatives to this approach? Seems to work fairly well, as long as the Core Team does maintain communication with the Extended Team members.
Any recommendations on a better approach?
By "commissioned" project, I mean a project with is large enough to require a specific budget, MRD, Functional Spec, Technical Spec, etc....
Re: Core Team/Extended Team Approach to Projects
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by stevew:
Just curious if there are any negatives to this approach? Seems to work fairly well, as long as the Core Team does maintain communication with the Extended Team members.<HR></BLOCKQUOTE>
Interestingly, part of my "TechQA" approach is a CORE method. CORE is Configuration and Operations Release Environment. (Sometimes I replace "Release" with "Reliability" depending upon the focus I am aiming for.) I have found this to work exceptionally well. And, yes, as you mention, the communication (i.e., interfaces) with the other teams has to be in place. Those interfaces, however, are defined as part of the "core" processes. It is also, of course, very important that this group does not come to be seen as dictatorial or withholding a great deal of relevant information. I usually have a CORE Web page on a company Intranet as well.
I have used this approach on small projects and on large projects, with equal amounts of success. Of course, the various processes within the CORE methodology change a little based on the project but the overall concepts are the same.
The reasons I find this works well is because it can, if done right, promote a general quality methodology in the business and technology areas. It can also help develop the training of quality practices at all levels of the organization. It provides a great deal of responsibility to various parties (thus giving equal participation) but also having accountability as well since everyone knows who is communicating with whom. Finally, it also gives a great deal of visibility into the entire process of quality itself.
So, are there better approaches? Possibly. However, I have found that a "core"-like approach can work very well as long as it is taken into account some of the cultural factors that go into establishing a sort of centralized effort like this.