Support and Project team structures

There are many ways to set up your teams. I would need more information about your situation. In my case I have worked with many different situations.

In one area, we had a business group who handed the project to project management, who handed it to development, who handed it to QA, who handed it to deployment, who handed it to Support. This situation worked extremely well because Project management devised "hand-off" or "transfer" meetings each time the project moved between the groups.

Another environment created project teams consisting of development, business analysts, project managers, deployment specialists, QA analysts, and support. When the project was turned of to post deployment support they already knew what they needed to and only issues that were "bug fixes" were sent back to development.

Your issue is not really teams from what I can see in your posting. It is more about developing an organizational structure. Teaming is not specific to IT. It goes anywhere. What difficulites you may experience comes from determining whether you want silos or cross-functional teams/workgroups. Are you setting up project based where everyone gets moved around depending on the project or does everyone always remain on the same team.

I think you may want to look into organizational theory and then look at teaming in terms of collaboration and putting the right people together.

Let us know how it goes and Good Luck.

I've been on both sides of the fence - I started on the support side and moved to the project management side.

Its important in any project to correctly identify the proper stakeholders, and properly define their role in the project. Support teams should be involved in crafting a support model, monitoring the QA process (they often make good testers), and if there is a field test or pilot, monitoring the result. In my current organization, someone from the support teams is designated as a participant on behalf of the whole team for each project. The management of the support team has a role in defining the requirements for a project. Thos requirements go beyond simple functional requirements into requirements for how the solution will be tested, implemented and supported.

James

Ask yourself what weaknesses exist in your current model. For example, does the project team have enough end-user expertise to anticipate support issues, and address those in the design phase? Do the two teams communicate well, or do they point fingers at each other over "bad design" or "clueless administration"? Are the customers satisfied? You might achieve better results by ensuring that all the necessary viewpoints are represented in the design and support functions, either on the project team (likely) or in the support unit (less lilkely).

If you don't want to have your developers ending up building and hands on supporting the deployment of each and every system, more strata/organization on the development/delivery side is required.

I suggest isolating your developers from delivery so that they can concentrate on building the next release. Differentiating between developers of core technology (that cross deployments), custom functionality (for a specific deployment) is sometimes also required.

Having the delivery function separate also makes sense in that much of that work is integration/configuration and is more geared towards system admins/software integrators. If you can do so, dedicate resources to this building/configuring of systems (especially where server builds are dependent on client standards, security, etc.). There is a lot there to know that is separate from developing code.

One mistake you ARE avoiding is trying to have your O&M folks build and deploy the systems (they're different skill sets), but you do need to make sure the folks on that side have the knowledge/skills to at least diagnose issues through review of logs, messages, performance, etc. We define the roles, responsibilities and required skill sets expected on the team we deliver to, but some of this is just too foreign to folks used to just managing email accounts, so you'll find that a good deal of documentation needs to accompany a code delivery (deployment instructions, admin guides, CONOPS, etc.). In addition, there is the need to establish QA/CM standards and processes/mechanisms that control issue reporting and enhancement requests.

Good luck!

Each IT staff is responsible for their core service level delivery of services and participate as a project leader. A project is defined as "implementation of any new technology at the institution". This not only delivers the mission critical objectives but produces environment of change forcing technical, leadership,communications skills.

As someone posted before, it all comes down to knowledge/skills distribution across your teams. In my experience, one of the best returns is achieved through a good organization of the project team, meaning all relevant skills/knowledge (such as development, planning, support, infrastructure) should be present. This will also generate a higher involvement of the support team (or an increased "ownership" if you want) in the solution, after the deployment phase.

There's no one solution or recipe which fits all kinds of organizations or internal cultures. In my opinion, you should start with the issue statement (what goes wrong today, does the information flow between groups, is the ownership of the project/solution assumed etc.), then cut your way through.

Good luck!

I am currently the project manager for a phased line of business application implementation. My team was organized to facilitate the design and build phases of the project. Now we are doing as much production support as actual project work, and the deficiencies in our structure - skills, roles, and even personalities are very evident.

I'm trying to split the team into 2 functional areas. One dedicated to the project, the other to production support. However this can't be done without increasing the number of people. No one wants to leave the comfort of their assigned role (lead QA, Reports designer, whatever) to step into another functional position which, in my opinion, would greatly improve our team performance.

I have tried to foster a team-of-peers approach, like MSF, but again, people are protective of their turf and mostly unwilling to share.

There are several widely recognized standards that describe how IT processes should work. I've modelled project teams after these standards.
For instance, for software/system development, the Software Engineering Institute's (SEI) Capability Maturity Model Integt=rated (CMMI) is excellent. Team make up an hierarchy mirrors the process functions and lifecycle of the product.
For service oriented activities, the Brittish published a set of guidelines called the Information Technology Information Library (ITIL). There are several dirivatives of this such as HP's Information Technology Service Management and Microsoft's Operations Framework (MOF). ITIL breaks down service (typically referring to support for fielded products) into Service Support and Service Delivery. Again, I structures a help desk/call center using ITIL principles and found it to be effective.
I agree with the prior postings that there is no one structure. But I do recommend understanding the industry standards and mirroring them to make sure that all functions are covered.
Good luck

Whichever way you structure your teams, ensure they are accountable from end to end for a service. Turn things around and look at them from a service perspective. Map out all of the webs and start working with the teams to cut some of the webs. I have never found it worked well to seperate the project teams from the support teams. The trap you tend to get into is throwing the solution over the wall. No one is happy and support\maintenance has limited opportunities to expand their knowledge.

I suggest that you look at the Application Competency Centre models. We adopted this model six years ago which has realised significant benefits to the organisation.

I have worked in telco industry which quite dinamic of both IT environment and user requirement. We organized team by having front line by put BA(Business analysis)& SA tegether to transform business requirement to business process and system development spec at this state EA (Enterprise architect) will involve interm of architecture blue print. After that SA will paticipate with ESA (envirenment SA) who specialize on particular system, then send program spec to developer (which are in the same team with ESA). Deliverable of developer team is quality code and unitest result, this will handover to QA team who do testing. If code contain defect, test team will generate defect list and send back to developer team to fix, but business user can overright to deploy with defect (if acceptable). While testing occuring, Operation team will get involved to handover knowledge from ESA which needed for operation support. The Operation team contain Helpdesk, 2nd line support and Diagnorsetic team who can drill usage log to identify where is problem occured. Helpdesk team will be front line of all user problem and send to 2nd line once cannot solve. There are team who call PMO(Program management office) which be the one who look over whole process, define risk of project, identify launch impact, follow up delay/risk issue which impac to project.

The size of the group (number of resources), the scope of the projects (including interations and typical deadlines), and your budget, can significantly determine how you set up your organization or department.

I've directed extreamly small teams (<4) to large ones (>80). They work better under different structure and management methodologies. This might sound obvious but I'm suprise that most books on the subject dance past this important issue.

Growth of team, history, culture, team dynamic, geography, and remote teams, also change the way a team needs to be formed. There is no absolute method to build the perfect team. It requires understanding the group as well as an ongoing awareness of the individuals and their interactions.

I've also seen issues where initial development was outsourced and an internal team maintained the code base (or projects where only the testing was outsourced).

I've been in corporations that used the "hand-off" method only to cause the worst problems imaginable, and I've seen environments where this worked very well.

I suppose the point I'm trying to make is that project team structure methods are important to understand and should be used as "guildlines" not as absolute structures. Often, it require some tweaking to fit specific organizations.

I have an IT friend in Ireland that sums-up a formal development/support organization with the following quip:

"Developers have the sex and the support organization is left to raise the children."

The skill is to blend the two effectively so that both groups enjoy both the benefits AND the responsibilities.

I've been in IT for 27 years and have seen many different approaches to this issue and as you would suspect, there are plusses and minuses for each. Two classic divisions of this are formal, functional structures, where there are more defined, fixed responsibilities, and dynamic or matrix structures where roles are more flexible and teams are structured based on the needs of the project.

I felt the formal organizational structures tended typically to promote better documentation of the work product, principally due to the requirement that each structure had to successfully hand their product to the next team in the process flow. This cannot be effectively performed without significant documentation (and my theory is that an application's lifespan is directly proportional to the thoroughness of its documentation). On the negative side, human beings tend to become somewhat territorial and these divisions of resources can create "organizational warring" and finger pointing which are inefficient and often counterproductive on many levels.

On the dynamic/matrix side, this organizational structure promotes more of a broader "shared responsibility" of the organization as a whole. Developers cannot simply hand off a questionably functional product just to empty their inbox, but have to participate in owning it throughout its journey into the hands of the user community and for a defined period thereafter. This helps to develop a sense of responsibility for its efficacy.

Oddly enough these are the typical differences found (and marketed!) by large, formal corporations vs. small, flexible, fleet-of-foot businesses. The large corporation is typically less able to adjust their processes on-the-fly, but is very adept and streamlining their processes and honing efficiency to a fine edge. Smaller businesses pride themselves on their ability to adjust their processes on demand and make their work product fit the needs of their customers more effectively.

If your business tends to deal with more repetitive, uniform customer needs, the more formal, functional approach will tend to deliver better results. If you tend to deal with more unique requrements from project to project, the dynamic, matrix approach is better equipped to deliver what you will be dealing with in that environment.

Which structure you choose also depends on the nature of the individuals doing it. If your business requires and employs individuals who tend to shrink from dynamic, flexible job responsibilities, a matrix structure can fail spectacularly due to excessive stress on employees. If your business requires and employs those who are dynamic, outside-the-box, think-on-their-feet individuals, a more rigid, functional organization will stifle their abilities and motivation to perform.