Pros and cons of support teams doing projects
Published on: Author: Joanna Schrap Category: IT development and operationsI encounter this dilemma at almost all organizations, small and large. The dilemma being a conflict of priorities. So it’s worthwhile exploring what solutions are available in dealing with it.
The conflict:
An operational support teams primary priority and responsibility is to ensure agreed customer service levels are met.
A project’s primary responsibility is to ensure that a project is delivered within a specified time and budget for the customer.
The Pros:
The major benefits of implementing projects by support teams are:
- There is little or no handover required, so in theory, effort related to handover can be eliminated.
- Systems are implemented correctly according to the support team’s standard requirements – thus ensuring quality and continuity of support once a system goes live.
- Ideal for projects that require effort in small increments of time per week with flexible planning – so hiring a dedicated full time project engineer is eliminated.
- The support team members have an opportunity to learn new technologies and/or functionality.
The Cons:
The major cons impact both budget and timelines of the project:
- Project timelines are not kept due to operational support issues always getting priority.
- Incremental work blocks (eg: every Thursday Jack works on project X) result that the effort (hours) is more because, switching “jobs” always results in loss of productivity (think: today I am booked to work only on project X, now let’s review where I was last week on this, what issues did I encounter last time, I forgot I encountered error 201XYZ 4 weeks ago and didn’t resolve it yet so now I have more errors, etc).
- If not disciplined, support teams tend to be slack with regards to dotting the “i’s” on their own deliverables. This results in holes in knowledge transfer over time.
What solutions are there?
…using operational teams:
- From a project management point of view – be prepared to write lots of scope changes due to delays and effort required. Managing and writing scope changes seem to be the number one fear of PM’s – more on this in a future blog.
- If there is spare capacity in the operational support team, remove the engineer from the support team for the duration of the project – physically locate this person in another office. Out of sight, out of mind.
- Use incremental work blocks – but not based on specified time frames, rather, specified on specific deliverables. Think agile!
- Communicate with you customer – identify the use of the operational support team as a real risk for the project effort and timelines.
…using separate project teams:
- Following a major project by a dedicated project engineer, integrate the project engineer into the support team.
- Ensure that the support team provides the project with a specified set of standard deliverables to which the project solution/deployment must conform before a project engineer starts work. This must be done at the architecture design stage when planning the initial scope of the project. Remember – the support team is also an end-customer for the project.
Other interesting reading on this topic:
Comments