IT Employment

General discussion


Support and Project team structures

By markflaherty ·
I am looking into the theory of team structures in an IT environment. Specifically I am reviewing the current teams structure, basically broken down along the lines of support teams who are charged with the responsibility of managing end user incident calls and general management of systems and a project team who are charged with the responsibility of developing and delivering the initial solution to the end users (which is then handed over to the support teams to manage).

I am looking for experiences in this area and how others have organised their teams an the pros and cons of any particular structure.

Any comments along these lines are more than welcome.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -


by j.lupo In reply to Support and Project team ...

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.

Collapse -

Integration of the teams

by JamesRL In reply to Support and Project team ...

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.


Collapse -

Fly in the ointment

by twymer In reply to Integration of the teams

And yet another possibility - those teams that are hybrids of the two - the support/project teams. Those teams tasked with upgrading/enhancing the new/old system and in their spare time maintaining the old system.

Collapse -

Communicate - Separate the functions, design processes, share resources

by martin In reply to Integration of the teams

In order to separate the functions you may still use some cross-functional team members.
However, it is designing and overtly stating the processes and procedures that are important.
How quickly will you respond to faults, etc in terms of ? recording them, identifying them, fixing them? And how will you ?manage? with other ?issues? ? you should be able to tell the users all of this (process/policy).

How will faults and incidents be managed ? there should be a transparent process that again you can tell the users/sponsors.

In software, for example, you may decide to live with some ?known faults? until a specific version is created. You can tell users when the next release is to be.

In infrastructure, you may decide to live with limited bandwidth to a given site, so you can tell users that certain functions will be slower because of that decision.

Your sponsors will need to know that they are getting ?value for money? (ANAO) and therefore not ?everything? they ?wish? for will be granted ? again this needs to be a point of agreement between you and your sponsors.

The difficulty that you discuss may arise because often there is no clear distinction between the GO LIVE and the DEBUG. And that DEBUG on LIVE systems runs away with itself.
The best method here is to ensure that there is, in the case of software an appropriate SDLC such as:
1. What is developed was signed off by sponsors. Prototypes were used where issues or risks arose to hit these early. Changes to what is signed off went through change control and affected/extended the budget/duration of the project. These were signed off.
2. The developed system was part of a whole business system which included business processes and procedures ? software just automated some of them ? it did not replace them
3. The whole set of new business processes, including the software are trained with users. Software training does not occur in isolation.
4. Before Go Live there is a User Acceptance Test (and there are unit tests and system tests etc before this so you know the system works).
5. Sponsors sign off on the UAT BEFORE you go live.
6. You track and measure bugs, you have a strategy to roll back if the system has too many, and you live with those rather than build fixes on a live system.
7. You group bug fixes into staged releases, which follow appropriate SDLC as noted above.
8. You gather NEW requirements and you get more funding to design and build them, gain signoff, a new set of dates and an new SDLC plan ? you DON?T just build the wish list onto your new application.
9. etc

Infrastructure (including SOE) rollouts also need appropriate Lifecycle plans, signoff, change control, UAT and handover (GO-LIVE).


Your project team looks after Lifecycle up to handover (after accepted results from UAT and will a golive rollback plan). Version releases are part of this

You support team looks after all services after go live and needs a full set of standard operating procedures and service levels to which they will perform for the rest of the business.

If a team member is doing support, they are not doing project work.
If the support team requires a resource (eg programmer, tester, architect ? perhaps all of these in one person in a very small project), then they call on this resource for ?root cause analysis?
This investigation is part of the resource?s job, but affects the rest of the durations of their work on projects, and your sponsor will need to sign off on this.
This is true of both infrastructure and software development/deployment

Now ? for a full process, standard ops procedures, structure of job roles, signoff sheets etc etc, why not get me in for a short while to design, set up and communicate the rules of play

Martin O?Dea

Collapse -

Support and Project team structures

by jonathank In reply to Support and Project team ...

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).

Collapse -

Depends on whether you mind your developers always in support mode...

by mcmuljo In reply to Support and Project team ...

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!

Collapse -

Static and Dynamic Teams

by annah In reply to Support and Project team ...

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.

Collapse -

Not a "one size fits all" approach!

by Mihnea D. Mironescu In reply to Support and Project team ...

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!

Collapse -

Combine methods

by DeLacyD In reply to Not a "one size fits all" ...

We have a departmental stucture in place that provides high consistency and high quality, however you sacrifice time as each handoff and layer adds to the time frame. For quick turn projects, we instead implement a design cell, teaming up members from each department to a dedicated team. With QA and Production assigned up front, there is no hand off and no delay.

Collapse -

Structure and Team Roles

by dberman In reply to Support and Project team ...

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.

Related Discussions

Related Forums